I gather than the best way to install the nvidia driver on Fedora is via RPM fusion. Do people find it’s common that dnf update will break the nvidia driver, or are special steps required to prevent such breakage?
Thanks
Follow Howto/NVIDIA - RPM Fusion
The driver software is installed via dnf and upgrades are seamless. They have been for many years.
It is stable enough.
My only issue was, during kernel update at boot, oftentimes it takes a long time (10-15 mins) for it to finish in my laptop’s case and when I encountered it for the first time, I thought the updating process crashed and I thought I was stuck in a boot loop.
In the Fedora installer you can just enable Third-Party repos and it’ll enable the RPM Fusion nvidia repository automatically. The repo is shipped with every Fedora install, just not enabled:
z% ls /etc/yum.repos.d | grep nvidia
rpmfusion-nonfree-nvidia-driver.repo
z% dnf provides /etc/yum.repos.d/rpmfusion-nonfree-nvidia-driver.repo
Last metadata expiration check: 17:52:36 ago on Fri 17 Nov 2023 03:21:00 CET.
fedora-workstation-repositories-38-2.fc38.x86_64 : Repository files for searchable repositories
Repo : @System
Matched from:
Filename : /etc/yum.repos.d/rpmfusion-nonfree-nvidia-driver.repo
But presumably the Fedora team will push out kernel updates before RPM fusion has had time to package the corresponding nvidia driver, right? Couldn’t that cause issues?
I’d have to check but I’m pretty sure the nvidia driver package depends on a specific kernel version package so the Kernel wouldn’t upgrade until the nvidia package is updated.
The OpenZFS docs have the following to say, I was imagining that the nvidia driver might be similar:
By default ZFS may be removed by kernel package updates. To lock the kernel version to only ones supported by ZFS to prevent this:
echo 'zfs' > /etc/dnf/protected.d/zfs.conf
Oh also the 510+ nvidia driver is in the Fedora repos so the RPM Fusion repo is only relevant if you need an older version for an older card
That sounds like a badly written package to me 
If your kernel module depends on a specific kernel then you should just specify that specific kernel as a dependency. An update for the kernel would then be denied by default because the dependency of the package wouldn’t be met.
Are you sure? I don’t see it here: nvidia - Fedora Packages
Nor do I see it on dnf search --repo=fedora nvidia on my (Fedora 39) laptop…
I don’t have an nvidia card so no, not entirely, but that is what it says in the RPM Fusion guide and RPM Fusion also doesn’t maintain any packages for 510+ from what I can tell.
Also…
This is a super stupidly written RPM spec…
Their documentation says:
Install kernel headers:
dnf install -y kernel-devel
kernel-develpackage must be installed beforezfspackage.
Why they don’t just specify a dependency on the kernel headers is beyond stupid and the same goes for the kernel version mentioned previously…
Oh, you’re referring to
The 510+ driver is available by default on Fedora 34+ and later and has dropped support for some older Kepler GPU.
I think what they mean is that the “nvidia” packages, that don’t include a specific driver number like “nvidia-410” use 510+ which dropped Kepler support. But those packages are still in RPM fusion.
I can’t comment on the reasons why the zfs package is done that way, I don’t know anything about dnf. I guess my main question is just would I need to do anything special to make sure updates don’t update the kernel and not the nvidia driver (or even remove the nvidia driver or something), or will it all work out correctly by default 
Since i can’t see the package source I don’t know for sure. Normally the Fedora packaging guidelines (which both the official repos and the rpm fusion repo are based on) handle that case by specifying exact dependencies.
But, let’s assume it doesn’t: During any update you always see what is being upgraded, installed as a dependency, or removed because of conflicts, and you need to confirm whether you want to do the transaction or not. So if you see that a current kernel is being removed (which by the way wouldn’t even work because it’s a protected package), you’d get a notice and could just decline.
TLDR: You don’t need to worry about it.
Kernel updates remove older kernels and it looks a little weird in the transaction details, but just pay attention to the version.
2 Likes
This repo is quite limited. I don’t think it even provides the cuda libraries (I might be wrong).
Do yourself a favor and add the proper rpmfusion repos. It allows pulling in a lot of functionality that you want in a daily driver beyond the nvidia driver.
Do a quick read through the list of Howtos.
e.g. I personally want my daily driver to support common multimedia codecs - not just the ones that IBM/RedHat lawyers deem appropriate for distribution.
Oh yeah I’m not saying the rpm fusion repos aren’t valuable, I recommend everyone installing them. I’m just saying it’s not technically necessary if you just want the nvidia driver.
edit, I was curious:
It does:
z% dnf list --repo=rpmfusion-nonfree-nvidia-driver | grep cuda
xorg-x11-drv-nvidia-470xx-cuda.x86_64 3:470.223.02-1.fc38 rpmfusion-nonfree-nvidia-driver
xorg-x11-drv-nvidia-470xx-cuda-libs.i686 3:470.223.02-1.fc38 rpmfusion-nonfree-nvidia-driver
xorg-x11-drv-nvidia-470xx-cuda-libs.x86_64 3:470.223.02-1.fc38 rpmfusion-nonfree-nvidia-driver
xorg-x11-drv-nvidia-cuda.x86_64 3:535.129.03-2.fc38 rpmfusion-nonfree-nvidia-driver
xorg-x11-drv-nvidia-cuda-libs.i686 3:535.129.03-2.fc38 rpmfusion-nonfree-nvidia-driver
xorg-x11-drv-nvidia-cuda-libs.x86_64 3:535.129.03-2.fc38 rpmfusion-nonfree-nvidia-driver
1 Like
To clarify, I wasn’t worried that a kernel would be removed, I was worried that the nvidia driver might be removed by a kernel update, or that the kernel might be updated without a corresponding update to the nvidia driver. It sounds from what you’re saying that this shouldn’t happen due to the policies about how dependencies are specified, but I just wanted to clarify.
OK scratch that I think I misread this.
What they mean by “default” is that you don’t need to specify a version number like the other ones, i.e. it’s the default driver package, not that it’s available by default as in “in a default Fedora installation”.
1 Like
Yes that’s my understanding as well