crosvm will not launch because of failure to find Wayland socket
Reported by
dubo...@codeweavers.com,
Jun 23 2018
|
||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36
Platform: 10809.0.2018_06_22_2259 (Developer Build - duboisj) developer-build eve
Steps to reproduce the problem:
1. Build Chrome OS with eve board from source, flash to usb and boot that on eve device
2. from a crosh prompt, type 'vmc start termina'
3. You will get an error message: 'Unable to start VM'
What is the expected behavior?
The VM would start
What went wrong?
It appears that this is because the wayland socket can't be found. After I build an image, I see these permissions:
> ls -l /run | grep chrome
drwx------ 2 chronos chronos 80 Jun 16 20:38 chrome
If I change them to more permissive, such that they are:
> ls -l /run | grep chrome
drwxrwxrwx 2 chronos chronos 80 Jun 16 20:38 chrome
... then I can start the VM just fine.
I wonder whether this happens when the ARC container is not present / running. In platform2/login_manager/chrome_setup.cc, I see:
EnsureDirectoryExists(base::FilePath("/run/chrome"), uid, gid, 0700)
but in platform2/arc/setup/arc_setup.cc, I see:
base::SetPosixFilePermissions(base::FilePath("/run/chrome"), 0755)
It looks like 0755 is what is present on my eve when I boot ChromeOS instead of my developer build.
I have not explored trying to run the arc container on my developer build. (As far as I understand, that would not be very useful because the container image with working Android is not part of the open source project.)
In any case, if it is a dependency on ARC I wonder whether it is unintentional.
I'm not at all certain any of this is what's happening: all I really know is that my local build suffers from this permissions problem and I can fix it by making permissions more lax.
As posted here:
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-dev/DDiaS6NVlD4
... at least one other person has suffered the same problem.
Did this work before? N/A
Chrome version: 69.0.3464.0 Channel: n/a
OS Version: 69.0.3464.0
Flash Version:
,
Jun 23 2018
bouncing to Dylan because b/28988348 tracks this issue if ARC++ wants those perms on /run/chrome, as does crosvm, then we should just change those perms everywhere arc/setup/arc_setup.cc: EXIT_IF(!base::SetPosixFilePermissions(base::FilePath("/run/chrome"), 0755));
,
Jun 25 2018
That's a very useful bug report, thanks! Since we run arc_setup before login, I don't see any benefit in pretending that login_manager's 700 perms will last. I'll set them directly from login_manager so that linux apps can work on builds without ARC, that's a silly dependency.
,
Jun 27 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform2/+/469a69bc3fc539e69b0f3d1e43d1128bab1d082b commit 469a69bc3fc539e69b0f3d1e43d1128bab1d082b Author: Dylan Reid <dgreid@chromium.org> Date: Tue Jun 26 23:59:35 2018 login/arc: Create /run/chrome world readable Because arc_setup runs before the login screen the 700 permissions set by login manager are overwritten before the user logs in. This change sets them to the needed value initially. This removes the dependency of non-android wayland users on arc_setup running, allowing Linux apps to work on boards without android and external builds that don't include android. TEST=boot, start an android and graphical Crostini app. BUG= 855822 Change-Id: I1b7866cef58d2f5f8db975c21320eed306a7129b Signed-off-by: Dylan Reid <dgreid@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1113945 Reviewed-by: Yusuke Sato <yusukes@chromium.org> Reviewed-by: Dan Erat <derat@chromium.org> Reviewed-by: Mike Frysinger <vapier@chromium.org> [modify] https://crrev.com/469a69bc3fc539e69b0f3d1e43d1128bab1d082b/arc/setup/arc_setup.cc [modify] https://crrev.com/469a69bc3fc539e69b0f3d1e43d1128bab1d082b/login_manager/chrome_setup.cc
,
Jun 27 2018
,
Jun 27 2018
Awesome - thanks for the fix!
,
Jun 27 2018
thanks for debugging things to track the issue down |
||||
►
Sign in to add a comment |
||||
Comment 1 by dubo...@codeweavers.com
, Jun 23 2018