EGL-using snaps on impish seem to be broken when using the Nvidia proprietary driver

Great suggestion, I made this available via a branch for testing now:

$ snap refresh --channel=edge/pr11023 snapd
2 Likes

It seems telegram-desktop has been updated since these problems were reported, so Iā€™ve removed mentions of it in the testing instructions.

Itā€™s still good feedback to know that we havenā€™t regressed telegram-desktop as a working snap though. Thanks.

To help narrow down which opengl-using core16 snaps to test, Iā€™ve created some shorter lists of the more active snaps.

Hereā€™s the 20 most recently updated snaps matching that criteria:

plexmediaserver
audovia
starruler2
hw-probe
quelea
kiosceditor
kiosc
adrift
offs
myteam
agent
icq-im
bzflag
bitshares2-light
programmer
flare-rpg
sftpclient
openhantek
xbts-light
sagudev-aranym

And here are the 20 with the highest stable revision numbers:

huggle
hw-probe
lxi-tools
mmex
notepadqq
goxel
quelea
fugio
sagudev-aranym
reicast
qr-code-generator-desktop
plexmediaserver
auryo
panorama
imagecomparer
atomify
git-cola
ags
starruler2
flare-rpg

If you recognise any of these snaps, then it would be useful to get some test feedback.

Ideally weā€™d look at popularity, but I was working with the information available through the public API.

Can confirm that this solves this problem for my core20 snap anki-ppd:

/snap/anki-ppd/3/usr/bin/mpv: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /var/lib/snapd/lib/gl/libEGL.so.1)

Thanks for the list. I tried several of the snaps on a new impish installation, xorg and nvidia and most are working. I did found a few with issues in the list though Imagecompared was failing with a GLX init error and a coredump git-cola was displaying an OpenGL init error and a rendering fallback message anki-ppd was displaying a libEGL GLIBC_2.33 warning

Those issues have been resolved after refreshing the snapd to channel=edge/pr11023 and using snapd-discard-ns

The other snaps still seem to work corectly

Looks like problem is still here for me (Fedora 35):

[r0ck3r@desktop ~]$ snap refresh --channel=edge/pr11023 snapd
[r0ck3r@desktop ~]$ snap run sqlitebrowser
WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement
/snap/sqlitebrowser/3233/bin/sqlitebrowser: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /var/lib/snapd/lib/gl/libGLX.so.0)
/snap/sqlitebrowser/3233/bin/sqlitebrowser: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /var/lib/snapd/lib/gl/libGLdispatch.so.0)

The instructions included:

after refreshing the snapd snap. Did you forget to run that, maybe?

There isnā€™t a quick way to test this on Fedora, as snapd doesnā€™t enable re-exec on that distro.

On distros where we have re-exec enabled (currently just Debian and Ubuntu), when the distro packaged snapd starts, it will check to see if a newer version has been installed as a snap and call exec() on that binary.

That doesnā€™t happen on Fedora, where a new RPM packaged version of snapd would need to be released to see this fix. The cases weā€™re trying to test here mostly revolve around whatā€™s going on within the sandbox though. So Iā€™m reasonably certain that the results we collect on Ubuntu will apply to Fedora too.

Iā€™ve tried

sudo /usr/libexec/snapd/snap-discard-ns sqlitebrowser

but it did not help

Snapd on Fedora does not support reexec. Youā€™ll have to clone the source tree from that branch and build it yourself. FWIW itā€™s enough to build snap-confine which is rather simple, after you get the source tree run cd cmd && ./autogen.sh && make hack.

You may need to get the builds deps before but you can run dnf build-dep snapd -y for this.

In the pull request, @mvo noted a failure in one of the old core16 snaps:

I think what is happening here is that the Ubuntu 16.04 version of libGL tries to fall back to the swrast DRI driver. While that driver doesnā€™t require any special hardware to run, I suspect it relies on the X server running Mesaā€™s GLX code.

One thing that would be useful to try in cases like this would be to run the app with the environment variable LIBGL_ALWAYS_INDIRECT=true set (as documented here: https://docs.mesa3d.org/envvars.html). This should get the Mesa libGL to try indirect rendering (i.e. forward GL calls to the X server via GLX) instead of the swrast driver, which will hopefully avoid the segfault.

It wonā€™t be as fast as direct rendering with the Nvidia binary drivers, but should be faster than software rendering. If this works, perhaps we can inject that environment variable when running these old snaps.

The branch from @jamesh has landed. Has anyone tried using it on Fedora/openSUSE/Debian/Arch maybe?

Have installed snapd-2.53.4-1.fc35.x86_64 from repo and snap version 2.53.4 in snap list

vlc and acestreamplayer started to work, but sqlitebrowser do not start with message:

[r0ck3r@desktop ~]$ snap run sqlitebrowser
/snap/sqlitebrowser/3233/bin/sqlitebrowser: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /var/lib/snapd/lib/gl/libGLX.so.0)
/snap/sqlitebrowser/3233/bin/sqlitebrowser: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /var/lib/snapd/lib/gl/libGLdispatch.so.0)