nvidia driver integration is incompatible with Debian

Bug #1866855 reported by Maximilian Federle
20
This bug affects 4 people
Affects Status Importance Assigned to Milestone
snapd
Confirmed
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
```

Revision history for this message
Maximilian Federle (ppd) wrote :
Changed in snapd:
importance: Undecided → High
status: New → Triaged
assignee: nobody → Zygmunt Krynicki (zyga)
Zygmunt Krynicki (zyga)
Changed in snapd:
status: Triaged → In Progress
Revision history for this message
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.

Revision history for this message
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?

Revision history for this message
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.

Revision history for this message
Giovanni Panaro (gpanaro) wrote :

Any progress or ideas on this?

Revision history for this message
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
Revision history for this message
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  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.