The OpenSource AMD Graphics drivers via libdrm look for a file called /usr/share/libdrm/amdgpu.ids which is provided by the deb package libdrm-common. By default this path is not readable by snaps and so we get messages about denied attempts to access it both in the application’s output and in the apparmor denials log locations. I’m unsure how important this file is, but it seems to be queried by, and denied for, most snaps that access the graphics subsystem via libdrm or maybe more specifically only via libGL.
1 Like
/usr/share/libdrm is not part of the snap’s runtime environment. The snap can choose to stage it and use a layout to access it. I’m surprised you are seeing apparmor denials since there is nothing to deny…
cc @zyga-snapd
It depends on the base, I think godot runtime puts stuff in /usr/share so that that file can be accessed.
Unfortunately there’s no easy way to redirect the driver to any other location and lack of access results in non-functioning GL stack.
Having said that, @jdstrand is right. @lucyllewy can you explain how you got the denial?
I can’t find where I saw the logs, although I can reproduce applications complaining about it with, e.g. gitter (an electron app), and openra (a mono game), both of which output on STDOUT that they can’t find the file.
Right, this is expected because /usr/share/libdrm from the host isn’t exposed to the runtime environment of the snap (which is different from a security policy violation).
1 Like
So we’re left with the question of “should it be added to snapland?”…
Is there any progress on this? 
I’m unable to start Chromium because of this 
can you be more specific, what do you see when you try to launch chromium and do you see any denials in the system journal ?
dan@dan-desktop:~$ chromium
Gtk-Message: 16:40:17.621: Failed to load module "canberra-gtk-module"
Gtk-Message: 16:40:17.628: Failed to load module "canberra-gtk-module"
Trace/breakpoint trap (core dumped)
dan@dan-desktop:~$ /usr/share/libdrm/amdgpu.ids: No such file or directory
[60559:60559:0100/000000.725430:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process.
It would appear I do see some app armour denials:
[49486.139309] audit: type=1400 audit(1595518953.891:234749): apparmor="DENIED" operation="open" profile="snap.chromium.chromium" name="/snap/core/9665/usr/share/locale/en_GB/LC_MESSAGES/snappy.mo" pid=60705 comm="snap-exec" requested_mask="r" denied_mask="r" fsuid=1001 ouid=0
are you certain that the lack of that file is what is causing the core dump?
Also I would suggest if you have not done so already to file a bug at bugs.launchpad.net/ubuntu/+source/chromium-browser so @oSoMoN can triage and help, as I can’t immediately say that not having the AMD graphics library in the snap’s mount namespace is the cause of your problem.
Hello there,
Is there a way as an end-user to add that file in the snap userland? I’m having the same issue with Authy.
I can run it but the app will fail because it can’t load the following file /usr/share/libdrm/amdgpu.ids.
Below the output of Authy :
TypeError: Cannot read property 'then' of undefined at Function.AutoUpdater.init (/snap/authy/5/resources/app.asar/js/background.js:63422:22) at Object.create (/snap/authy/5/resources/app.asar/js/background.js:56845:34) at App.WindowHelper.create (/snap/authy/5/resources/app.asar/js/background.js:13670:32) at App.emit (events.js:208:15) /usr/share/libdrm/amdgpu.ids: No such file or directory [49918:1007/113451.705215:ERROR:buffer_manager.cc(488)] [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error from previous GL command
My environment:
OS: Fedora 32 (Workstation Edition) x86_64 Host: B45M2 Kernel: 5.8.12-200.fc32.x86_64 Uptime: 2 hours, 35 mins Packages: 2308 (rpm), 6 (flatpak), 7 (snap) Shell: zsh 5.8 Resolution: 1920x1080 WM: sway Theme: Adwaita [GTK2] Icons: Adwaita [GTK2] CPU: AMD Ryzen 5 3500X (6) @ 3.600GHz GPU: AMD ATI Radeon RX 5600 OEM/5600 XT / 5700/5700 XT Memory: 9458MiB / 32054MiB
And if not is there an ETA about a fix for this issue?
As far as I can tell spotify, discord, authy are impacted, I assume any electron app, or any app leveraging on opengl/opencl.
I know this might sound unrelated, but have you tried export DISABLE_WAYLAND=1 in the terminal prior to launching them.
I can’t say with any confidence, but my sneaky intuition is these apps are having problems with you running on Wayland (I assume, given you’re running Fedora on an AMD GPU), and the specific amdgpu.ids file might just be some noise. They should ideally set this themselves if this is the case, but I’m sure some snaps slip through.
Although to answer your question specifically, I think you’d need to ask the maintainers to do it to get a proper fix by adding the file and the layout definition for it, you could technically work around it by unsquashing the snap and doing some manual modifications, but it’s a fairly involved process that would break automatic updates (and it would make more sense if they provide their own snapcraft build files / source to do it there, rather than editing the output by hand)
First of all, thank you for your reply.
I just tried but without any luck. Unfortunately, the maintainer (Twilio) is not really reactive, so I’m okay with breaking auto-updates as long as I can send them the fix.
It’s unfortunate the XWayland fallback didn’t work, but this is how you’d try manually setting up the layout for the .ids file.
You need to extract the contents of the snap you want to edit, you’d do it with a command like this
sudo unsquashfs -d ~/rs-unsquashed /var/lib/snapd/snaps/runescape_28.snap , obviously changing the snap name and revision as relevant. This should put the snaps contents in your home directory all nice and visible like any regular folder.
You’d probably benefit from running sudo snap try ~/rs-unsquashed, again with the relevant name. This will tell snap to actually mount the folder itself rather than a .squashfs file as it would usually. Any change in the folder is now reflected instantly, so you can rapidly iterate on messing around in that folder and just simply run the snap normally, without having to repeatedly run snapcraft or snap install commands.
All the permissions on the files will be owned by root, so you’d want to chown them to your normal user, so you can actually modify them.
sudo chown -R $USER:$USER rs-unsquashed
In the unsquashed folder, you’d find meta/snap.yaml, and you can open and edit this file. Assuming the .ids file already exists in the directory structure, all you need to do is add
layout:
/usr/share/libdrm:
bind: $SNAP/usr/share/libdrm
into the yaml and save it, and hopefully the next run works! This is the same as what the maintainer would need to add into their snapcraft build file.
If the ids isn’t actually in the directory structure, you’d probably have to grab the package from the Ubuntu package repositories manually and place it, but I assume it usually is in snaps by default since it’s part of the mesa packages iirc, so it’s probably just a matter of adding the layout above.
At this point, hopefully it works and you can continue using it from the folder if you’d like. Otherwise I think the snap pack tools can get this back into a .squashfs file for you, but since it’s modified at this point, you need to pass the --dangerous flag if trying to install it since it would now fail signature verification. Either way, automatic updates will now no longer work since you’re running a custom build.
Hopefully this helps!
2 Likes