These days I lean towards the more stable distros, but I’ve been reading the Arch wiki and I have the following question for Arch users:
The arch wiki clearly says that the recommended way to install the nvidia driver is to pacman -S nvidia or nvidia-lts depending on whether you’re using the linux or linux-lts kernel. But if I just do this and nothing else, is there anything to prevent an uncareful pacman -Syu from updating the kernel and not the nvidia driver, thereby breaking the GPU support?
I have basically the same question about ZFS… The openzfs documentation seems to suggest that to use the zfs-linux package, you need to add a bit to your pacman.conf to explicitly ignore kernel updates… Would something like that need to be done in the nvidia case as well? And I guess presumably if you do want to upgrade the kernel you need to manually eyeball the available zfs version for compatibility with the latest kernel?
Would love to hear from anyone with experience running this particular trio of sofware (Arch, ZFS, nvidia driver).
You could install the nvidia-dkms package instead, which will rebuild the kernel module based on the installed kernel version at every update (that’s what I do).
Can’t help you with the ZFS thing as I am not a ZFS user, sorry.
Thanks. I guess I’m asking here because I didn’t find the arch wiki clear enough. It sounds like both of you are saying “use dkms”. But looking at the release change logs for various version of OpenZFS on Linux there are compatible kernel versions listed with each release, leading me to conclude that even with DKMS, something needs to be done to ensure that a kernel update doesn’t happen if there isn’t an available zfs version…
Warning: Unless you use the dkms versions of these packages, the ZFS and SPL kernel modules are tied to a specific kernel version. It would not be possible to apply any kernel updates until updated packages are uploaded to AUR or the archzfs repository.
So I guess the dkms package should take care of that.
Yes, you do a pacman hook which you will find on section 1.3.1.3 of the wiki you mentioned:
To avoid the possibility of forgetting to update initramfs after an NVIDIA driver upgrade, you may want to use a pacman hook:
/etc/pacman.d/hooks/nvidia.hook
[Trigger]
Operation=Install
Operation=Upgrade
Operation=Remove
Type=Package
Target=nvidia
Target=linux
# Change the linux part above and in the Exec line if a different kernel is used
[Action]
Description=Update NVIDIA module in initcpio
Depends=mkinitcpio
When=PostTransaction
NeedsTargets
Exec=/bin/sh -c 'while read -r trg; do case $trg in linux) exit 0; esac; done; /usr/bin/mkinitcpio -P'
That certainly prevents you updating the nvidia driver and not the initramfs, but what about the actual packages in the arch repo being such that when you do an update, you get a new kernel and not a compatible driver? Does that simply not happen in practice (i.e. the Arch people are eyeballing the nvidia driver and holding back kernel releases until there’s at least a compatible module)?
I’ve been using the nvidia-dkms package and (once I also added the hook to update initramfs) I’ve never had an issue with kernel or nvidia updates. Has been smooth sailing for a couple years.
Thanks to you both. The points about using dkms seem to make sense to me. Also welcome to the forum, @Level2497
Perhaps I’m being dim/stubborn at this point, but it seems like the regular nvidia pacakge (or nvidia-lts, as applicable) are recommended by that Arch wiki page, whereas nvidia-dkms is advocated only for custom kernels. Does anyone know why?
It says in the doc that the dkms is required to automate the nvidia kernel module rebuild for custom kernels. Not sure why but I assume it has to do with the fact you need to enable special flags to compile for different parameters so they leave it up to the user to set it up.
There is also a dkms hook they recommend in there.
I don’t mess with custom kernels much anymore so not 100% clear on the why in detail, just figure it’s probably because those compiling their own kernels want options.
That has only happened once with me during that GPL condom drama, took nvidia some weeks to work around that with their kernel module.
Regular nvidia should work fine with the default kernel, but the dkms gets rebuilt at every update, so it’s almost guaranteed that it’ll work (as long as some incompatibility like the GPL condom case doesn’t happen).
Just in case anyone else has the same doubts that I had…
I went ahead and switched to Arch. Though I also have the -lts kernel installed, I’m using the default linux kernel, and zfs-linux/nvidia-linux. I’ve still been careful when eyeballing updates, but today I saw this:
:: Synchronizing package databases...
core 153.3 KiB 1357 KiB/s 00:00 [#####################################] 100%
extra 1772.6 KiB 17.8 MiB/s 00:00 [#####################################] 100%
community 7.3 MiB 15.4 MiB/s 00:00 [#####################################] 100%
archzfs is up to date
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...
error: failed to prepare transaction (could not satisfy dependencies)
:: installing linux (6.2.13.arch1-1) breaks dependency 'linux=6.2.12.arch1-1' required by zfs-linux
:: installing linux-lts (6.1.26-1) breaks dependency 'linux-lts=6.1.25-1' required by zfs-linux-lts
So clearly the archzfs repository sets up its dependencies such that you can’t (famous last words) break your install with just pacman -Syu.