Apps won't run and crash on gnome/wayland

snapd
1

I can install snapd and apps on my system, but none of my apps will run and/or crash as soon as I try to launch them. I’ve tried multiple apps, but run into similar problems.

snap version
snap 2.45.3.1-1.fc33
snapd 2.45.3.1-1.fc33
series 16
fedora 33
kernel 5.8.12-300.fc33.x86_64

snap list
Name Version Rev Tracking Publisher Notes
chromium 85.0.4183.121 1328 latest/stable canonical✓ -
core 16-2.46.1 9993 latest/stable canonical✓ core
core18 20200724 1885 latest/stable canonical✓ base
core20 20 634 latest/stable canonical✓ base
foliate 2.4.2 1119 latest/stable johnfactotum -
gnome-3-28-1804 3.28.0-17-gde3d74c.de3d74c 128 latest/stable canonical✓ -
gnome-3-34-1804 0+git.3556cb3 60 latest/stable canonical✓ -
gtk-common-themes 0.1-36-gc75f853 1506 latest/stable canonical✓ -
hello-world 6.4 29 latest/stable canonical✓ -
losslesscut 3.22.3 35 latest/stable mifino -
xonotic 0.8.2 53 latest/stable snapcrafters -
yuzu 0-394 104 latest/stable nightmayr -

chromium
WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement
[13347:13347:1001/020349.706270:ERROR:browser_main_loop.cc(1417)] Unable to open X display.

foliate
WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement
Cannot get default EGL display: EGL_BAD_PARAMETER
WaylandCompositor requires eglCreateImage and eglDestroyImage.
Nested Wayland compositor could not initialize EGL

losslesscut
WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement
(losslesscut:13963): Gtk-WARNING **: 02:05:20.967: cannot open display: :0

xonotic
WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement
Game is Xonotic using base gamedir data
gamename for server filtering: Xonotic
Xonotic Linux 22:06:02 Mar 31 2017 - release
Current nice level is below the soft limit - cannot use niceness
Skeletal animation uses SSE code path
DPSOFTRAST available (SSE2 instructions detected)
Quake Error: Failed to init SDL video subsystem: No available video device

yuzu
WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
qt.qpa.xcb: could not connect to display :0
qt.qpa.plugin: Could not load the Qt platform plugin “xcb” in “” even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.
Avbruten (SIGABRT) (minnesutskrift skapad)

echo $XDG_SESSION_TYPE
wayland
echo $WAYLAND_DISPLAY
wayland-0

/usr/bin/gnome-shell --wayland --display-server
*(gnome-shell:25361): mutter-WARNING *: 17:02:27.628: Failed to create backend: Could not take control: GDBus.Error:System.Error.EBUSY: Device or resource busy

lspci -k | grep -A 2 VGA
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev e7)
Subsystem: Micro-Star International Co., Ltd. [MSI] Device 3417
Kernel driver in use: amdgpu

BZ#1883621 https://bugzilla.redhat.com/show_bug.cgi?id=1883621

Another user was able to reproduce my issue and I was suggested to ask here.

2 Likes
2

I just upgraded to Ubuntu 20.10 (I know it is not released yet, but I want to contribute by testing it) and I think I have the same problem.
To add to your list of apps:

spotify
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
Warning: GTK2 does not support Wayland!
Gtk-Message: 17:54:21.525: Failed to load module “gail”
Gtk-Message: 17:54:21.525: Failed to load module “atk-bridge”
Gtk-Message: 17:54:21.525: Failed to load module “appmenu-gtk-module”
Gtk-Message: 17:54:21.526: Failed to load module “appmenu-gtk-module”
Gtk-Message: 17:54:21.526: Failed to load module “appmenu-gtk-module”
Gtk-Message: 17:54:21.526: Failed to load module “appmenu-gtk-module”

(spotify:49189): Gtk-WARNING **: 17:54:21.527: cannot open display: :0

keepassxc
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
qt.qpa.screen: QXcbConnection: Could not connect to display :0
Could not connect to any X display.

These apps were working fine under wayland in Ubuntu 20.04 and work fine under X11 in Ubuntu 20.10.

Any ideas?

3

Have you made any progress @itrymybest80? I am still struggling with this bug…

4

Some apps (such as Chromium) will run if you manually call the binary in /snap directly from instead of running them through snap. I think there should be a bug filed against snap itself but I’m not sure where to do it.

I’m pretty tied to Wayland and I remember a couple Ubuntu releases ago where snaps didn’t work on Wayland for a couple months after a major release and I really hope we don’t see that again :frowning:

2 Likes
5

I do remember that too, and I hope it is not the case now. For now, I have moved to X11, but I would like to be able to use Wayland.

Are you by any chance using zsh instead of bash? I am and it has been a problem in the past for snap and I wonder if it is a fault here too.

6

Default bash here (and even default .bashrc and .bash_profile)

7

Just a few updates based on the discussion in bug 1897224:

GNOME 3.38’s Wayland session included a behaviour change to stop listening on an abstract namespace socket for X11 connections:
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1424

This causes problems because the non-abstract X11 socket is not visible to snaps due to the sandbox’s private /tmp directory. We’re looking into it now, and the fix will either involve reverting the Mutter change (which would have to make it into your distro), or snapd would need to expose the non-abstract socket.

In the short term, the only workaround I can offer is to use the GNOME’s X11 session instead. I know that’s not ideal, but it’s all I’ve got to offer in the short term.

3 Likes
8

Thanks for the info, I’ll keep an eye on the bug there… of course it’s Mutter :stuck_out_tongue:

9

Hey James, while I do agree that Mutter should reintroduce de abstract socket, I also think it’s about time for Snap to be able to use non-abstract socket also. Any movement on this front?

10

We’ll definitely need to address this if distros get released with broken versions of Mutter. But are there reasons aside from this current bug that you want to use non-abstract socket communication?

The abstract namespace socket has been the default method of connecting to a local X server on Linux since 2008. It avoids all the problems surrounding creation and permissions on the /tmp/.X11-unix directory, and was added specifically to allow communication when access to the host system /tmp is not available (as is the case with the snap sandbox).

1 Like
11

I see. To be honest, I was under the impression that non-abstract socket was the de-facto standard for accessing X servers - abstract being a more unusual alternative. The link provided seems to say otherwise. Thanks for explaining.

12

On non-Linux systems where abstract sockets are not available, the non-abstract socket in /tmp/.X11-unix is the default.

For this specific bug, Mutter had been updated so create both listening sockets but was only starting Xwayland on connection to the abstract socket: if X11 apps didn’t pick the abstract socket first, then the bug would have been immediately obvious.

As I understand it, the reason they’re not using the abstract socket for Flatpaks is that they run the app in its own network namespace, which blocks access to abstract namespace sockets. While you can easily use bind mounts to make non-abstract sockets available in the sandbox’s mount namespace, I don’t think there is a way to do the same with abstract namespace sockets.

In contrast, snapd relies on AppArmor to control access to unix domain sockets and network access in general, so does not use network namespaces as part of its sandbox strategy. So providing access to the abstract X11 socket was relatively straight forward.

1 Like
13

As a follow-up, I put together a merge request on the weekend that backs out the removal of the abstract socket and fixes the autostart behaviour for the non-abstract socket:

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1508

I’m hopeful that this will be accepted and included in a 3.38.x maintenance release.

3 Likes
14

The fix is now available in groovy-proposed, and will go to updates once it has passed QA:

The fix has been merged upstream to the gnome-3-38 branch. So it will hopefully make its way to other distros as they update.

Looking forward, snapd is also being patched to give snaps plugging the x11 interface access to the non-abstract sockets:

https://github.com/snapcore/snapd/pull/9530

The GNOME devs have indicated that they would like to remove the abstract socket again in a future release, as it is not possible to selectively make abstract sockets available to sandboxed applications without a kernel level MAC system like AppArmor or SELinux. So this should protect us for when that time comes.

1 Like
15

Thank you for this fix.

I have updated to OS to Ubuntu 20.10 and really nothing works on snaps. I’m happy to see that it will be fixed soon.

Thank you !