Did you manage to fix this issue “the right way”?
We have the same issue and probably we could collaborate in some way to solve this together?
It may be unrelated, but during the testing of Mir 1.1 I’ve found an issue with the notification messages Mir generates for outputs. I’ll revisit this issue once I’ve got to the bottom of that.
That problem turned out to be client-side: the Mir server is behaving correctly.
Hi @ilya, sorry for the long delay! Had to attend to more urgent parts of our stack (being the sole developer has downsides … ) and some family time.
I’m just returning to this issue. @alan_g 's clarification (thanks, helped me understand this a lot better!), The XWayland config applied in the chromium-mir-kiosk snap (specifically in xwayland-kiosk-helper) in the snap might be a good starting point to debug, especially if/why $DISPLAY is not set properly. I fiddled around with a modified copy of xwayland-kiosk-helper which prints the Mir port used to set $DISPLAY, and it came up empty. Don’t know if I did that right.
Side note: I discovered the Webkit Platform for Embedded (WPE) project which has native Wayland support and should be less resource-hungry (our project runs on RasPi-like boards). I hope that a native Wayland client browser simply adheres to Mir display commands, so I’m looking into snapping this instead. The build instructions are lacking (and not working on my Ubuntu Desktop installation) at best, but if you’re interested let me know.
Please let us know if this works for you. (Or not.)
@alan_g : I have a snap ready with wpewebkit, its required libs and including the WebKit minibrowser. It has
core18 as base. There’s only one issue remaining, and I think it’s related to the wayland socket. Here’s what I’ve done so far:
- Built libwpe, wpebackend-fdo and wpe-webkit from the latest release tarballs on my Ubuntu 18.04 Desktop (Hint: dependencies cannot be satisfied with package versions from 16.04 repos, even though wpe-webkit‘s github README instructs to build on Xenial). wpe-webkit includes the MiniBrowser.
- Installed miral-kiosk and ran it according to the “make a Wayland-native kiosk“ tutorial.
- Ran the built MiniBrowser binary, showed up successfully in Mir-on-X window
- Recreated the build process as a snap with parts for each component as well as a launcher script
- Built said snap on amd64 with Multipass, installed it on my 18.04 host
Everything works well, except the MiniBrowser fails with “failed to create the WPE view Backend”. The same error occurs if I specify different wayland sockets for miral-kiosk and the hand-compiled MiniBrowser bin, so I guess it’s related to WPE not finding the socket. I followed the kiosk tutorial closely, especially the section about the socket path issue for
$XDG_RUNTIME_DIR. FYI, the symlink command listed there (
ln -s $XDG_RUNTIME_DIR/../wayland-0 $XDG_RUNTIME_DIR/) does not traverse the path up, but created a link to
/run/user/1000/snap.webkit-embedded/../wayland-0, which does not exist. I tried to create a relative link with
ln -sr ../wayland-0 $XDG_RUNTIME_DIR/. This resolves correctly when I follow the link, but I don’t know if that is correct – didn’t resolve the issue anyway.
There are “known problems” with graphics snaps on Ubuntu Classic. In particular, mir-kiosk fails to supply the “wayland” interface. There is a fix “coming soon” that you can get by:
snap refresh --edge core
Does the above fix this?
I confess it’s a while since I looked at the tutorials, so I’m not clear on where in which one you find the above advice. Anyway, looking at one “client” snap I know works: https://github.com/MirServer/mir-kiosk-apps/blob/master/snap/snapcraft.yaml:
environment: XDG_RUNTIME_DIR: /run/user/0
@tobias I sought some clarification and while the extract I posted “works” it isn’t good practice, nor the way things should be.
What should be happening is that snapd should be creating
$XDG_RUNTIME_DIR. But it isn’t.
Unfortunately, the client cannot use
mkdir -p -m 700 $XDG_RUNTIME_DIR to create the directory (
/run/user/0/snap.mir-kiosk-apps in the example I was trying) as there is no
/run/user/0 either. UNLESS there is a server (mir-kiosk) already running (which will have created it).
A second problem is that the link command will fail unless the target exists. That also requires a server to be running.
If (and only if) there’s a server already running this works:
mkdir -p -m 700 $XDG_RUNTIME_DIR ln -sf /run/user/0/wayland-0 $XDG_RUNTIME_DIR/
We are trying to clear this all up and provide a reliable mechanism. So, while the above advice is a pragmatic solution for now, be prepared for changes.
@alan_g Thank you for taking the time to investigate this! I’ve updated my post above with links, in short:
I tested your suggestions, but I think I either missed/misunderstood something or the problem is indeed a missing library in the snap instead of confinement issues.
Question: Should I add either the
environment line in the apps’
snapcraft.yaml section or the
$XDG_RUNTIME_DIR linking on service startup – or both? I understood it as “
environment works, but is not good practice, use the symlinking instead”.
Here’s what I tried:
- Start the
miral-kioskapplication like in the tutorial (runs as user 1000), no other parameters. Creates a
- Switch the snap definition from service to app (i.e. disable service stanzas in snapcraft.yaml) so that if I run the app, it’ll run as user 1000
- Add the symlink workaround from your last post to the launch script, but linking to
/run/user/1000/wayland-0where miral-kiosk is running
… no luck. Still, building and running the MiniBrowser with the exact same steps but on the native host opens the browser window in Mir-on-X without issues.
corefrom edge channel
mir-kioskstarts on VT4
- Switch snap definition back to a service (should run as user 0)
- Revert the symlink to point to
- Make sure mir-kiosk is still running on VT4, SSH from other machine and start the wpe-webkit-mir-kiosk service again
… still the same error: “Failed to create WPE view backend”.
I found a (not very helpful) Github Issue, but it’s in the context of the buildroot overlay which I presume does not have the whole graphics stack provided by Ubuntu Core / mir-kiosk.
Please do correct me, but I presume that if the MiniBrowser runs fine in Mir-on-X from the host 18.04 machine, it should run fine from within a core18-based snap?
One obvious problem is in https://git.launchpad.net/wpe-webkit-snap/tree/src/launch-wpe
export LIBGL_DRIVERS_PATH=$SNAP/usr/lib/<replaced by SNAPCRAFT_ARCH_TRIPLET>/dri
That’s an invalid path. It is better to use the “environment” in the .yaml, There you can use
This is just a placeholder which gets replaced through a
sed command in the
override-pull step for this part, see https://git.launchpad.net/wpe-webkit-snap/tree/snap/snapcraft.yaml#n139.
But I guess it’s cleaner if defined in the environment.
This is the current
$XDG_RUNTIME_DIR situation, running
mir-kiosk and my snap in service mode directly on a 18.04 host with edge
➜ sudo tree /run/user/0 /run/user/0 ├── snap.wpe-webkit-mir-kiosk │ └── wayland-0 -> /run/user/0/wayland-0 ├── wayland-0 └── wayland-0.lock
➜ sudo ls -laR /run/user/0 /run/user/0: total 0 drwxr-xr-x 3 root root 100 Mär 7 16:34 . drwxr-xr-x 5 root root 100 Mär 7 09:47 .. drwx------ 2 root root 60 Mär 7 16:34 snap.wpe-webkit-mir-kiosk srw-rw-rw- 1 root root 0 Mär 7 16:34 wayland-0 -rw-r----- 1 root root 0 Mär 7 16:34 wayland-0.lock /run/user/0/snap.wpe-webkit-mir-kiosk: total 0 drwx------ 2 root root 60 Mär 7 16:34 . drwxr-xr-x 3 root root 100 Mär 7 16:34 .. lrwxrwxrwx 1 root root 21 Mär 7 16:34 wayland-0 -> /run/user/0/wayland-0
user@host:~$ snap version snap 2.38~pre1+git1182.68177c3~ubuntu16.04.1 snapd 2.38~pre1+git1182.68177c3~ubuntu16.04.1 series 16 ubuntu 18.04 kernel 4.15.0-46-generic
And for reference, this is still the only traceable error (highlight by me):
user@host:~$ snap logs wpe-webkit-mir-kiosk 2019-03-07T15:43:59Z systemd: Started Service for snap application wpe-webkit-mir-kiosk.browser. # ----- ⬇︎ 2019-03-07T15:44:00Z -: Failed to create WPE view backend # ----- ⬆︎ 2019-03-07T15:44:00Z systemd: snap.wpe-webkit-mir-kiosk.browser.service: Main process exited, code=exited, status=1/FAILURE 2019-03-07T15:44:00Z systemd: snap.wpe-webkit-mir-kiosk.browser.service: Failed with result 'exit-code'. 2019-03-07T15:44:00Z systemd: snap.wpe-webkit-mir-kiosk.browser.service: Service hold-off time over, scheduling restart. 2019-03-07T15:44:00Z systemd: snap.wpe-webkit-mir-kiosk.browser.service: Scheduled restart job, restart counter is at 5. 2019-03-07T15:44:00Z systemd: Stopped Service for snap application wpe-webkit-mir-kiosk.browser. 2019-03-07T15:44:00Z systemd: snap.wpe-webkit-mir-kiosk.browser.service: Start request repeated too quickly. 2019-03-07T15:44:00Z systemd: snap.wpe-webkit-mir-kiosk.browser.service: Failed with result 'exit-code'. 2019-03-07T15:44:00Z systemd: Failed to start Service for snap application wpe-webkit-mir-kiosk.browser.
Yes, sorry. There’s nothing else leaps out at me: An error from <some app I don’t know> failing to <something else I don’t know> doesn’t give me much to go on.
You really need to debug your snap and see exactly what is going wrong. I’m no expert on the techniques involved.
There’s some guidance in the “common problems” sections of this tutorial: https://tutorials.ubuntu.com/tutorial/wayland-kiosk#0
And there is more material around here: Snapcraft Live 6th Feb 2019
@alan_g I managed to get the snap running properly: on Ubuntu 18.04 LTS desktop both with
mir-kiosk with edge core; on Ubuntu Core using
mir-kiosk with stable core. I’ll outline the main steps below, for fellow snap crafters that may run into similar issues (or have the same lack of experience with graphic stacks as I had). So bear with me – or skip to “Questions”
The main problem were missing/wrong
XDG environment variables inside the snap env. After I adapted them from the
mir-kiosk-apps example you linked, WPE could connect to the Wayland socket and the EGL display. Then some iterative “libxyz is missing”, and it worked on Ubuntu Desktop. I added plugs and the
snapcraft-preload plugin recommended by
snappy-debug, and proceeded to test the ARM build on Core.
I was confused at first why the WebKit process was stuck in a crash loop after I installed the snap on Core running on a RasPi 3B. When I removed
snapcraft-preload from the startup command, it stopped crashing – but loading any trivial website had weird issues that indicated that the browser can’t find libraries despite
LD_LIBRARY_PATH being set. Issues like no images, no SSL/TLS despite
libglib-networking being present etc. Also, this was in
devmode, where WPE Webkit may access
/dev/shm (which I gathered
snapcraft-preload provides a workaround for in strict mode).
The WPE WebKit backend
libwpebackend-fdo relies on the FreeDesktop.org stack, so I added the
gtk3-desktop helper. Now everything works fine, I added two basic configuration options (URL and a toggle for the Remote Web Inspector) as well.
Some links to WPE WebKit in general:
https://wpewebkit.org → main site
https://github.com/WebPlatformForEmbedded → GitHub org
https://github.com/Igalia/cog → Fullscreen browser launcher used in this snap
I added TODO / FIXME to snapcraft.yaml to indicate the work-in-progress parts. Most concern dependencies for building/running WPE Webkit, but I’d be stoked if someone can answer me these questions which I think are more related to snapcraft/Core/mir:
- From experience with other snaps, would a slimmer desktop-helper than gtk3 suffice to provide the “normal” FDO stack required by
libwpebackend-fdo? Including this helper brings the snap from ~75 to ~114MB. (Also asked this the WPE maintainers:
- The browser fails to resolve zeroconf/Bonjour hostnames, though it works fine when building and running
cog+ WPE WebKit natively works fine. I included some avahi-related libs and connected the
avahi-observeinterface, but I guess I’m missing something fundamental here.
I’d like to suggest amending the docs for Debugging building snaps with a workflow that sped up my debugging on-device (ARM snap on a RasPi 3) tremendously:
- Let the ARM build run on Launchpad – takes ~ 3h for the WPE snap instead of forever (or probably failing due to limited CPU/RAM) when building on a RasPi
- Load the snap file from LP to your device, either via
scpfrom your main machine or using @ondra 's great
unsquashfs -d my-dir-name the-snap-file_0.1.0_somearch.snap
- You can now
snap try my-dir-name(optionally with
--devmode) and edit all files in
my-dir-nameto your heart’s content, all instantly reflected inside the snap. Only when editing
my-dir-name/meta/snap.yamlto change app commands/services or add interfaces, you need to remove and re-mount the snap (via
Step 4 (
snap try) is already documented there, but I think fleshing out an extra sentence how that works if you only have a .snap file (LP build or snapcraft 3 with bases) can help expediting dev workflows.
Ping @ogra and @ilya – might be of interest for you (especially @ogra 's MagicMirror snap). In my tests, WPE WebKit adhered to all Wayland commands that
mir-kiosk sent its way, so it’s fullscreen by default and in any rotation that you set in
The snap will be available as
armhf on the beta channel once these builds succeed.
amd64 already available and tested with success
I’m in the middle of releasing Mir 1.1.2 and updating all our server snaps, but I’ll take a closer look at your snap after that.
Once you’re satisfied with “polishing” I think your work deserves a thread in its right - “chromium-mir-kiosk in portrait mode” hardly indicates what you have achived.
I see a “TODO” before your use of “layout:” but this is a perfectly sane use of the feature.
I’ve not done any work on “slimming down” the helper dependencies for snaps. Maybe someone with more experience can help here? @popey?
Sorry, no idea about this.
Let me repeat: Great work! You have reason to be proud.
@tobias I also just wanted to say congrats. I’ve not had much time to fix the chromium-mir snap, so I’m glad you’ve found a solution that works for you. Thanks for sharing what you’ve learned too!
as long as this is not fixed, you can hack around it via a wrapper script like i do in:
This is a great project and as stated should be highlighted more
I have a RPi3 B+ with a fresh install of ubuntu-18.04.2-preinstalled-server-armhf+raspi3
sudo snap install wpe-webkit-mir-kiosk but getting error messages about it being unable to find the wayland-0 compositor - I see in the readme that it’s hardcoded to /run/user/0/wayland-0 but I can’t quite grasp what’s required to get even a symlink in place, any pointers greatly appreciated?
ubuntu@ubuntu:~$ sudo snap logs wpe-webkit-mir-kiosk 2019-05-03T13:36:03Z systemd: Started Service for snap application wpe-webkit-mir-kiosk.browser. 2019-05-03T13:36:03Z wpe-webkit-mir-kiosk.browser: mkdir: cannot create directory ‘/run/user/0’: Permission denied 2019-05-03T13:36:17Z wpe-webkit-mir-kiosk.browser: mkdir: cannot create directory ‘/run/user/0’: Permission denied 2019-05-03T13:36:17Z systemd: snap.wpe-webkit-mir-kiosk.browser.service: Main process exited, code=exited, status=1/FAILURE 2019-05-03T13:36:17Z systemd: snap.wpe-webkit-mir-kiosk.browser.service: Failed with result 'exit-code'. 2019-05-03T13:36:17Z systemd: snap.wpe-webkit-mir-kiosk.browser.service: Service hold-off time over, scheduling restart. 2019-05-03T13:36:17Z systemd: snap.wpe-webkit-mir-kiosk.browser.service: Scheduled restart job, restart counter is at 5. 2019-05-03T13:36:17Z systemd: Stopped Service for snap application wpe-webkit-mir-kiosk.browser. 2019-05-03T13:36:17Z systemd: Started Service for snap application wpe-webkit-mir-kiosk.browser. 2019-05-03T13:36:17Z wpe-webkit-mir-kiosk.browser: mkdir: cannot create directory ‘/run/user/0’: Permission denied
Hi @ndrt, thanks for trying out the snap and for the compliments! My first guess would be that you didn’t install the
mir-kiosk snap first, which provides the Wayland compositor.
Please try this:
- Install mir-kiosk from Canonical:
sudo snap install mir-kiosk
- Restart WPE:
sudo snap restart wpe-webkit-mir-kiosk
- If WPE still fails to start: Try a reboot
Hope that resolves the issue!
I tried that but just got a flashing cursor so presumed was doing something wrong but having dug a little deeper I’ve got issues with mir, namely that it’s failing to start owing to a bug around KMS / DRM. There was a commit to fix: #733 but it seems either that’s incompatible with 18.04 and RPi3 B+ or something else. I’ll keep digging and post on the mir forum.
2019-05-07T11:27:11Z systemd: Started Service for snap application mir-kiosk.mir-kiosk. 2019-05-07T11:27:12Z mir-kiosk.mir-kiosk: mkdir: cannot create directory ‘/run/user/0’: Permission denied 2019-05-07T11:27:12Z mir-kiosk.mir-kiosk: [2019-05-07 11:27:12.270992] mirserver: Starting 2019-05-07T11:27:12Z mir-kiosk.mir-kiosk: [2019-05-07 11:27:12.272760] <DEBUG> mirserver: Using Linux VT subsystem for session management 2019-05-07T11:27:12Z mir-kiosk.mir-kiosk: [2019-05-07 11:27:12.273872] mircommon: Loading modules from: /snap/mir-kiosk/1386/usr/lib/arm-linux-gnueabihf/mir/server-platform 2019-05-07T11:27:12Z mir-kiosk.mir-kiosk: [2019-05-07 11:27:12.274147] mircommon: Loading module: /snap/mir-kiosk/1386/usr/lib/arm-linux-gnueabihf/mir/server-platform/graphics-mesa-kms.so.16 2019-05-07T11:27:12Z mir-kiosk.mir-kiosk: [2019-05-07 11:27:12.274298] mircommon: Loading module: /snap/mir-kiosk/1386/usr/lib/arm-linux-gnueabihf/mir/server-platform/server-mesa-x11.so.16 2019-05-07T11:27:12Z mir-kiosk.mir-kiosk: [2019-05-07 11:27:12.274362] mircommon: Loading module: /snap/mir-kiosk/1386/usr/lib/arm-linux-gnueabihf/mir/server-platform/input-evdev.so.7 2019-05-07T11:27:12Z mir-kiosk.mir-kiosk: [2019-05-07 11:27:12.280834] mesa-kms: Unsupported: No DRM devices detected 2019-05-07T11:27:12Z mir-kiosk.mir-kiosk: [2019-05-07 11:27:12.281029] mirplatform: Found graphics driver: mir:mesa-kms (version 1.1.2) Support priority: 0 2019-05-07T11:27:12Z mir-kiosk.mir-kiosk: [2019-05-07 11:27:12.281128] mirplatform: Found graphics driver: mir:mesa-x11 (version 1.1.2) Support priority: 0 2019-05-07T11:27:12Z mir-kiosk.mir-kiosk: ERROR: /build/mir-eQgTJy/mir-1.1.2/src/server/graphics/default_configuration.cpp(172): Throw in function mir::DefaultServerConfiguration::the_graphics_platform()::<lambda()> 2019-05-07T11:27:12Z mir-kiosk.mir-kiosk: Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> > 2019-05-07T11:27:12Z mir-kiosk.mir-kiosk: std::exception::what: Exception while creating graphics platform 2019-05-07T11:27:12Z mir-kiosk.mir-kiosk: ERROR: /build/mir-eQgTJy/mir-1.1.2/src/platform/graphics/platform_probe.cpp(109): Throw in function std::shared_ptr<mir::SharedLibrary> mir::graphics::module_for_device(const std::vector<std::shared_ptr<mir::SharedLibrary> >&, const mir::options::ProgramOption&, const std::shared_ptr<mir::ConsoleServices>&) 2019-05-07T11:27:12Z mir-kiosk.mir-kiosk: Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> > 2019-05-07T11:27:12Z mir-kiosk.mir-kiosk: std::exception::what: Failed to find platform for current system 2019-05-07T11:27:12Z systemd: snap.mir-kiosk.mir-kiosk.service: Main process exited, code=exited, status=1/FAILURE 2019-05-07T11:27:12Z systemd: snap.mir-kiosk.mir-kiosk.service: Failed with result 'exit-code'. 2019-05-07T11:27:12Z systemd: snap.mir-kiosk.mir-kiosk.service: Service hold-off time over, scheduling restart. 2019-05-07T11:27:12Z systemd: snap.mir-kiosk.mir-kiosk.service: Scheduled restart job, restart counter is at 4. 2019-05-07T11:27:12Z systemd: Stopped Service for snap application mir-kiosk.mir-kiosk. 2019-05-07T11:27:12Z systemd: snap.mir-kiosk.mir-kiosk.service: Start request repeated too quickly. 2019-05-07T11:27:12Z systemd: snap.mir-kiosk.mir-kiosk.service: Failed with result 'exit-code'. 2019-05-07T11:27:12Z systemd: Failed to start Service for snap application mir-kiosk.mir-kiosk.