nvidia driver integration is incompatible with Debian

Bug #1866855 reported by Maximilian Federle on 2020-03-10
20
This bug affects 4 people
Affects Status Importance Assigned to Milestone
snapd
Medium
Unassigned

Bug Description

Original forum thread: https://forum.snapcraft.io/t/no-opengl-on-debian-9-nvidia/15848

## Environment

- Debian 9 or 10
- Proprietary nvidia-driver installed and working, no matter the exact version
- snap 2.43.3
- snapd 2.43.3

## Bug

Apps that use OpenGL contexts (e.g. GtkGlArea) fail with errors like

```
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
```

when run with the proprietary nvidia driver in use.

Examples from the store: solvespace, graphics-debug-tools-bboozzoo.glxinfo

## Investigation

- Apps fail to open libGL.so.1
- The nvidia libraries are set up in a way, so that the final target of the symlink chain is not accessible from within confinement:

```
user@debian:~$ stat /var/lib/snapd/lib/gl/libGL.so.1
  File: /var/lib/snapd/lib/gl/libGL.so.1 -> /var/lib/snapd/hostfs/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu
[...]

user@debian:~$ stat /var/lib/snapd/hostfs/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu
  File: /var/lib/snapd/hostfs/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
[...]

user@debian:~$ stat /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
stat: cannot stat '/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1': No such file or directory
```

Maximilian Federle (ppd) wrote :
Changed in snapd:
importance: Undecided → High
status: New → Triaged
assignee: nobody → Zygmunt Krynicki (zyga)
Zygmunt Krynicki (zyga) on 2020-03-16
Changed in snapd:
status: Triaged → In Progress
Zygmunt Krynicki (zyga) wrote :

I've inspected what's going on on Debian and the long story short is that we do not support the way Nvidia driver is provided there.

We could add a special support for nvidia-on-debian or work towards nvidia-via-snaps where the host distribution packaging decisions don't matter, as long as the kernel side is provided.

I think right now we have no chance to fix it.

Maximilian Federle (ppd) wrote :

I presume nvidia userland has to match the installed kernel module exactly? So there's no working around this by shipping some version of nvidia userland in the snap itself?

Zygmunt Krynicki (zyga) wrote :

That's correct.

There's an elaborate plan for shipping userspace parts as a snap but it was dropped from snapd roadmap for this cycle. It is likely to return in 20.10. Once completed snapd will match the userspace libraries, in a snap, from whatever the host provides.

Giovanni Panaro (gpanaro) wrote :

Any progress or ideas on this?

Zygmunt Krynicki (zyga) wrote :

This is a large chunk of work that we cannot commit to at this time. We will see what feature allocation happens next month. If we get to fix nvidia handling it will be fixed uniformly for everyone.

Changed in snapd:
status: In Progress → Confirmed
Changed in snapd:
assignee: Zygmunt Krynicki (zyga) → nobody
importance: High → Medium
Ionized Girl (ionizedgirl) wrote :

Workaround: before running app (in this case wickrme) but after snapd creates the relevant tmpfs in
the app's fsns /usr/lib/x86_64-linux-gnu, run the following:

sudo snap run --shell wickrme -c 'ln -s /var/lib/snapd/hostfs/usr/lib/x86_64-linux-gnu/nvidia /usr/lib/x86_64-linux-gnu/nvidia'

(replace wickrme with app name as needed)

Surely this could be done automatically in in the gl slot plug thing?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers