Until this morning, I was able to play urban-terror using the snap with confinement and a better frame rate than the native install on my Fedora 32.
I upgraded to fedora 33 and now running urban-terror results in the app complaining about the following:
Can’t load LibGL.so.1 from /etc/ld.so.conf or current dir: no dynamic gl support in current video driver.
I checked and in the snap there is no ld.so.conf in the snap/urban-terror… /etc/ directory.
I would prefer to use this app confined rather than install --classic or install the native version.
I am guessing it may be some sort of snap configuration error with regard to Fedora 33.
I have tried reinstalling snapd and also installing urban-terror from the snap-store, by the command line also, and using the latest candidate install.
Should I get in touch with the author of the snap?
Or perhaps it is a Fedora issue?
MTIA…
@millerthegorilla Which graphics card are you using?
This is a second broken snap after upgrade to F33, are there others?
Hi, thanks for getting back to me.
I am using the intel i915 graphics driver, and this is the only snap that I have a problem with, but is the only snap that I am using. Until I upgraded this afternoon, it was working fine, with better frame rates and ping than the native install (from the urbanterror.info website).
The only problem that I have had recently is that someone hacked into the snap and was able to request a privilege raise through gksu, which I simply cancel, but that shouldn’t affect this issue.
I am going to try and purge snapd from the machine again. Last time I am not sure that I cleaned all of the configuration files before reinstalling.
This is a screenshot of the resulting terminal. I am unable to ctrl-c etc and have to close the terminal to close the process.
I have no real understanding of the system underlying snaps, although I have some developing experience. I don’t know if the rest of this makes sense…
If I examine the mounted directory, there is no /etc/ld.so.conf
from the command ‘mount’
/var/lib/snapd/snaps/urban-terror_25.snap on /var/lib/snapd/snap/urban-terror/25 type squashfs (ro,nodev,relatime,context=system_u:object_r:snappy_snap_t:s0,x-gdu.hide)
… ls -al /var/lib/snapd/snap/urban-terror/25/etc/
total 23
drwxr-xr-x. 6 root root 102 Jun 25 16:23 .
drwxr-xr-x. 9 root root 185 Jun 25 16:23 …
-rw-r–r--. 1 root root 12636 Jun 14 2018 drirc
drwxr-xr-x. 3 root root 29 Jan 14 2019 gss
drwxr-xr-x. 2 root root 32 Jun 25 16:23 ldap
drwxr-xr-x. 2 root root 34 Jun 25 16:23 pulse
-rw-r–r--. 1 root root 10368 Oct 2 2015 sensors3.conf
drwxr-xr-x. 2 root root 35 Jun 25 16:23 sensors.d
Ok, so I made a live usb with persistent storage of fedora 33, installed snap and installed urban-terror and got the same result, so it looks like it is a problem between snaps and fedora 33.
Please share how you did that with download links so I can try debugging this. I never used Fedora and don’t know where to begin.
There are known issues with running X11 snaps on GNOME 3.38’s Wayland session, which is what Fedora 33 defaults to:
This problem is being worked on both at the snapd level and upstream with GNOME, as the above thread details. Unfortunately those solutions are not yet available on Fedora.
I don’t have a Fedora 33 system readily available to check, but you might be able to switch to the legacy Xorg session from the login screen just before entering your password: look for a gear icon or similar that will show a list of available sessions. If the snap works in the Xorg session, then this is likely the root cause of the problem.
The whole reason I use the snap is because wayland makes the quake3 mod less hackable. If I use the x11 window manager then it gets hacked all the time. I shall have to downgrade to continue playing then. I guess the X11 snap that comprises the Urban Terror environment still exposes that anonymous socket, which is how the hackers were able to make a gksu privileges request.
I don’t think that the native app, downloaded from urbanterror.info will work in a wayland environment.
It occurs to me now, though, that I can boot from the usb disk and try an x11 session in that. The performance may be a bit crappy, but then the game is so old that maybe it won’t matter.
To make a live usb with persistent storage, one needs to be running Fedora to begin with, so I don’t think it will work if you aren’t already running Fedora.
https://docs.fedoraproject.org/en-US/Fedora/10/html/Release_Notes/sn-Live_USB_persistence.html
Many thanks.
A snap is readonly, gksu or sudo are non-functional in the snap runtime environment (not even through the X11 socket) and snaps can not execute binaries outside the snap env by default.
Ubuntu supports persistent live media since 2007 (in fact i think that even pre-dates any fedora live media existence) so when wanting to use a persistent live system you are definitely not tied to having to use fedora here …
If the game depends on X11, then it is probably going to run about as securely in a Wayland session as an X11 session.
The abstract namespace socket mentioned in the other thread shouldn’t allow any unexpected privilege escalation: it was there in distros with older GNOME releases (Fedora 33, Ubuntu 20.04, etc).
I always had problems with hacks intercepting keystrokes. I don’t think they could read them, but they could certainly push keystrokes into the stream.
I use Fedora specifically because I prefer the selinux model to be better and more secure than apparmor. Also, ubuntu would always be breaking, and I have never had that problem with fedora. it just works.
The GKSU is actually a dbus call, I think.
I have to say for the record, I don’t really understand why we needed to start using the anonymous socket in the first place, we should have stuck with permission based sockets. X11 was unusable due to security issues within a year of the anonymous socket being introduced.