Fedora 25 Switching Over To Using GLVND For Mesa, Happier NVIDIA Driver Installation

[andrebrait]

All that's lacking for me to switch to Fedora is libinput 1.6 and a proper repository for NVIDIA drivers that won't leave me with a black screen on reboot (RPMFusion) or a sad smiley face on starting X/Wayland.

Both of these should be solved by Fedora 26, so I'll wait until then. Fedora is becoming a very attractive distro, even from my Arch-y POV.

[Guest]

All that's lacking for me to switch to Fedora is libinput 1.6 and a proper repository for NVIDIA drivers that won't leave me with a black screen on reboot (RPMFusion) or a sad smiley face on starting X/Wayland.

Both of these should be solved by Fedora 26, so I'll wait until then. Fedora is becoming a very attractive distro, even from my Arch-y POV.

If you install NVIDIA's driver with DKMS (by-default I think akmods is used on RPM Fusion and mentioned more often on negativo17), I wonder if that will fix black screens on reboot? The black screen on reboot after something like a kernel update on akmods is because of the kernel module not being rebulit until that next reboot. Ubuntu's graphics PPA NV package uses DKMS for comparison.

I'm not entirely sure if akmods can build the module for a kernel not in-use (aka the installed updated kernel), but if it can, then running akmods --force should take care of that (it will either take some time if it needs to build the module, or instantly complete if the module exists).

[pal666]

Come on PRO, you can make it...

they already made it. glvnd is needed to support proprietary shit on dual gpu systems instead of integrating with mesa. amd is integrated with mesa already

[pipe13]

I use Nvidia drivers from the negativo17 fedora-nvidia repo, with dkms. They compile drivers for new kernels as they are installed, just fine, leaving the running kernel alone. But they will remove drivers from non-running kernels in /lib/modules other than the new one, which is... inconvenient.

One thing the combination does *not* do reliably is update the nvidia drivers during a system upgrade. IIRC they did during my 23->24 upgrade, but sure didn't during 24->25. Fortunately, I always have at least one other dual-boot partition, in this case CentOS-7; I booted into that, made a simlink from it's latest 3.10 kernel into the fc25 /lib/modules, added the entry into grub2/grub.conf, booted into fc25 on the CentOS kernel, ran dkms on fedora's kernel, and was set.

I think it was more than necessary: I probably could have run dkms on the fedora kernel directly from CentOS, which have made more sense. But that's not how I did it.

The wise choice would be to have a tested nouveau configuration in grub.cfg, and edit that into the fedora upgrade from CentOS. I thought I had one, but it didn't work.

Either that, or squirrel away the last working fc24 kernel with working drivers someplace dkms can't find them, and restore that to /lib/modules if the upgrade fails to compile new drivers.

Disabling the fedora-nvidia repo before system-upgrade might also be a viable option. I'm just uncertain what dnf will do in that circumstance.

[Ericg]

I use Nvidia drivers from the negativo17 fedora-nvidia repo, with dkms. They compile drivers for new kernels as they are installed, just fine, leaving the running kernel alone. But they will remove drivers from non-running kernels in /lib/modules other than the new one, which is... inconvenient.

One thing the combination does *not* do reliably is update the nvidia drivers during a system upgrade. IIRC they did during my 23->24 upgrade, but sure didn't during 24->25. Fortunately, I always have at least one other dual-boot partition, in this case CentOS-7; I booted into that, made a simlink from it's latest 3.10 kernel into the fc25 /lib/modules, added the entry into grub2/grub.conf, booted into fc25 on the CentOS kernel, ran dkms on fedora's kernel, and was set.

I think it was more than necessary: I probably could have run dkms on the fedora kernel directly from CentOS, which have made more sense. But that's not how I did it.

The wise choice would be to have a tested nouveau configuration in grub.cfg, and edit that into the fedora upgrade from CentOS. I thought I had one, but it didn't work.

Either that, or squirrel away the last working fc24 kernel with working drivers someplace dkms can't find them, and restore that to /lib/modules if the upgrade fails to compile new drivers.

Disabling the fedora-nvidia repo before system-upgrade might also be a viable option. I'm just uncertain what dnf will do in that circumstance.

System upgrades don't work because the package upgrade environment does not reliably run the kernel module compilation. You run into the same issue if you do graphical updates under Gnome with the Nvidia driver. Or at least you did up until a month or so ago, they might have fixed it since then.

[TingPing]

All that's lacking for me to switch to Fedora is libinput 1.6 and a proper repository for NVIDIA drivers that won't leave me with a black screen on reboot (RPMFusion) or a sad smiley face on starting X/Wayland.

Both of these should be solved by Fedora 26, so I'll wait until then. Fedora is becoming a very attractive distro, even from my Arch-y POV.

The negativo repo is generally the recommended nvidia package nowadays and is as close as there is to official. With this libglvnd change it should be a very smooth process in the future and you can already install the driver with one click in gnome-software: http://negativo17.org/nvidia-driver/

[TumultuousUnicorn]

This is great. Wish that happened on archlinux as well.

+1. GLVND should be adopted by AMD before, I think.

[jukk]

+1 for negativo17.

Does the change mean that drivers stop messing around with e.g. symlinks to /lib*/lib*GL*.so.* ? I've had enough broken systems with X failing to start because of messed up library symlinks (before I remember where to look for the problem).

[pipe13]

+1 for negativo17.

Does the change mean that drivers stop messing around with e.g. symlinks to /lib*/lib*GL*.so.* ? I've had enough broken systems with X failing to start because of messed up library symlinks (before I remember where to look for the problem).

$ grep PRETTY_NAME /etc/os-release | cut -d'=' -f2
"Fedora 25 (Workstation Edition)"

$ file /usr/lib64/libGL.so.1.2.0
/usr/lib64/libGL.so.1.2.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=f45c6ea2958c0ce15fb5988e3efa0782bcd5e1b0, stripped

$ file /usr/lib64/glvnd/libGL.so.1.0.0
/usr/lib64/glvnd/libGL.so.1.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=28540030a33a5710975d0724e4eaa6b3e9cdead6, stripped

$ dnf provides /usr/lib64/libGL.so.1.2.0
mesa-libGL-12.0.3-3.fc25.x86_64 : Mesa libGL runtime libraries
Repo : fedora

$ dnf provides /usr/lib64/glvnd/libGL.so.1.0.0
libglvnd-glx-1:0.2.999-5.20161115git522c601.fc25.x86_64 : GLX support for libglvnd
Repo : fedora-nvidia

$ file /usr/lib64/libOpenCL.so.1.0.0
/usr/lib64/libOpenCL.so.1.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=3452f70923327f5df643212b9263096b4b6e8468, stripped

$ dnf provides /usr/lib64/libOpenCL.so.1.0.0
ocl-icd-2.2.9-2.fc25.x86_64 : OpenCL ICD Bindings
Repo : fedora

$ dnf provides /usr/lib64/nvidia/libOpenCL.so.1.0.0
nvidia-driver-cuda-libs-2:375.26-4.fc25.x86_64 : Libraries for nvidia-driver-cuda
Repo : fedora-nvidia

Slaanesh (fedora-nvidia maintainer) did a decent job on this.

[plonoma]

Great improvements, now just AMDGPU-PRO and all important drivers support GLVND.
Looking forward to more stable systems.