So, RHEL has a solution for correctly signed Nvidia drivers that work with Secure Boot.
Why doesn’t Rocky provide such a solution as well? Is it being blocked by technical issues, licensing issues or politics?
NVidia drivers are from rpmfusion or elrepo repositories, so they are nothing to do with Rocky. You say RHEL has a solution, provide the link so that we can see what it is?
Looking at the NVidia official docs for driver installation (Tesla docs, though applies to all) the path to have Secure Boot is to install the MOK keys which it asks for. (if I read it correctly for both DKMS and directly built by NVidia)
The MOK part applies to Rocky Linux 10, but in case of DKMS should theoretically also for 8 and 9.
1 Like
That basically says that some repo has pre-compiled NVidia kernel modules that are signed with same key as rest of RHEL kernel.
The rest of NVidia drivers comes from NVidia’s repo.
If one takes NVidia’s dkms-based kernel module package, then one “builds” and signs the kernel modules self (and has to import the key with mokutil).
NVidia’s repo has had precompiled kernel modules too, signed by NVidia (and one had to import NVidia’s key).
ELRepo has kernel modules signed by ELRepo (and one has to import ELRepo’s key).
AlmaLinux (9 and 10) builds and signs NVidia’s kernel modules, so they work with AlmaLinux without additional import. That is very recent addition. There was already moment, when NVidia had updated their drivers (but had not notified AlmaLinux), so there was (RPM) version mismatch between kernel module package and the rest of the driver.
So it sounds like both RH and Alma are building the modules and signing them (no need for 3rd party key in BIOS)?
Folks, the salient point here is not the fact that the drivers are signed. The point is that they are signed with a key based on a chain of trust that Secure Boot recognizes, without running mokutil.
Anyone that knows how to run gcc and openssl can produce signed drivers. But not everyone can do this signing using keys which directly enable Secure Boot on any modern UEFI BIOS.
If RH can do it and Alma can do it, Rocky can and should do it.
1 Like
If you obtain the commercial offering from CIQ. Since there is Rocky Linux, and Rocky Linux from CIQ which offers commercial support and thus a part of their commercial offerings. Whether that will filter down or not is a different matter at this point.
1 Like
So if RH are signing these drivers, does that mean these drivers are included in the official RH repos?
According to the blog link posted, no, since the drivers are signed by the repository provided by Nvidia. It just happens to be a repo for RHEL9.
therefore Nvidia are still responsible for it, nothing has been done by Red Hat.
Also, for the tech preview bit:
Drivers signed by Nvidia, not Red Hat.
I expect when it goes into production, Nvidia will still be signing them, and the signing key will be imported when the Nvidia repository is being used.
So the same would still apply for Rocky Linux, it would just mean Nvidia doing the same now for Rocky as they did for RHEL. The onus is on Nvidia since the packages are being downloaded from their repos, not from RHEL, not from Rocky.
That said, it could already be done as per the CIQ link. Let’s hope so.
I have a Rocky 10 machine with NVIDIA drivers installed from a .run-file, with DKMS activated.
This is from last night, when a new kernel was installed:
Sign command: /lib/modules/6.12.0-55.30.1.el10_0.x86_64/build/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub
Autoinstall of module nvidia/550.163.01 for kernel 6.12.0-55.30.1.el10_0.x86_64 (x86_64)
Building module(s)......... done.
Signing module /var/lib/dkms/nvidia/550.163.01/build/nvidia.ko
Signing module /var/lib/dkms/nvidia/550.163.01/build/nvidia-uvm.ko
Signing module /var/lib/dkms/nvidia/550.163.01/build/nvidia-modeset.ko
Signing module /var/lib/dkms/nvidia/550.163.01/build/nvidia-drm.ko
Signing module /var/lib/dkms/nvidia/550.163.01/build/nvidia-peermem.ko
Installing /lib/modules/6.12.0-55.30.1.el10_0.x86_64/extra/nvidia.ko.xz
Installing /lib/modules/6.12.0-55.30.1.el10_0.x86_64/extra/nvidia-uvm.ko.xz
Installing /lib/modules/6.12.0-55.30.1.el10_0.x86_64/extra/nvidia-modeset.ko.xz
Installing /lib/modules/6.12.0-55.30.1.el10_0.x86_64/extra/nvidia-drm.ko.xz
Installing /lib/modules/6.12.0-55.30.1.el10_0.x86_64/extra/nvidia-peermem.ko.xz
Adding linked weak modules...
Running depmod... done.
Autoinstall on 6.12.0-55.30.1.el10_0.x86_64 succeeded for module(s) nvidia.
1 Like
INMOPinion (INmop) this is really nvidia’s fault for not testing and developing these methods on multiple operating systems and providing easy gpu installation and upgrade and deprecation controls. If you have two versions of an app installed, or two games per generation, and are on top end gear, the deprecation model for drivers is not adequate for linux users who are far more laterally using sources from many means as necessary. I lock in horizon zero dawn in 550. driver for example on Mint no issues up to 580. then i upgrade the game and the driver for HZD remastered is deprecated due to the new game having 32bit DX11/12.libs that are no longer supported on say a version past 555 on rocky linux 8 /9+. So while Jensen wants libraries, he does not want linux users to own controls of enable/disable any given lib per OS. If I go to rocky 10 I won’t be able to run either game environment variables because of the 32 bit support being left out. The same goes for steamers and the game developers who only want you on their PAID windows experience.
I had to sign up to RHEL developer to get those 575+ and 580+ drivers working on R9.6, and the further up you go the less support there is for existing X11/org datasets.
Are those with the RH-signed kernel modules?
If yes, then which repo and application stream are they from?
(The NVidia blog lists streams that I have not seen on non-RHEL system.)
not sure how to tell… newbie here
dnf list installed \*nvidia\*
dnf module list nvidia-driver
1 Like
stay on 550 driver for as long as possible, that’s what I have found.
I created a somewhat incomplete short list of down grading driver on rocky linux
sudo systemctl isolate multi-user.target
sudo dnf remove -y nvidia-driver nvidia* cuda* kmod-nvidia*
sudo dnf module reset -y nvidia-driver
sudo dnf install -y kernel-headers-$(uname -r) kernel-devel-$(uname -r) dkms gcc make elfutils-libelf-devel libglvnd-devel
sudo dnf config-manager --add-repo https://developer.download.nvidia.com/compute/cuda/repos/rhel9/x86_64/cuda-rhel9.repo
sudo dnf clean all && sudo dnf makecache
sudo dnf module install -y nvidia-driver:550-dkms --allowerasing
echo -e “blacklist nouveau\noptions nouveau modeset=0” | sudo tee /etc/modprobe.d/blacklist-nouveau.conf
sudo grubby --args=“nouveau.modeset=0 rd.driver.blacklist=nouveau” --update-kernel=ALL
sudo dracut --force --regenerate-all
sudo mokutil --import /var/lib/dkms/mok.pub
sudo reboot
nvidia-smi
The goal is to be able to find what Nvidia driver on rollback works normal in both DCCreation as well as steam / game playback without to much wine complexity. Any thoughts on this method or another? I have 3 ver 9.6, 9.5 and 9.3 on grub.