Install NVIDIA Drivers on Fedora 45/44 (Secure Boot, Legacy GPUs)

Install the NVIDIA driver on a Secure Boot machine without enrolling a key and the module never loads. The akmod build finishes, nvidia-smi fails, and the kernel log says the key was rejected, with no warning from dnf. On a GTX 900, GTX 10 or Volta card there’s a second trap: the current driver package no longer supports those GPUs, so it builds a module the card can’t use.

Original content from computingforgeeks.com - post 68983

This guide installs NVIDIA drivers on Fedora 45 and Fedora 44 from RPM Fusion, enrolls the akmods key for Secure Boot and covers the akmod-nvidia-580xx legacy branch. In November 2026 we re-ran the install and build on Fedora 45 and 44 VMs, and the signing checks and legacy swap on 45, all with Secure Boot enforcing, against akmod-nvidia 615.78.08 and akmod-nvidia-580xx 580.196.07, so no step asks you to switch Secure Boot off.

NVIDIA has published R620 (620.70.06) upstream, but RPM Fusion’s stable and testing repos still served the 615 branch on 4 November, so dnf installs 615 today.

Which NVIDIA driver package your GPU needs

Pick the package by GPU generation, not by what a forum post installed three years ago. On Fedora 45, RPM Fusion nonfree carries four driver branches, and only one of them fits a given card.

GPU generation	Example cards	Package	Kernel module built
Turing and newer	GTX 16 series, RTX 20 to RTX 50, Tesla T4, A10G, L4	akmod-nvidia	Open
Maxwell, Pascal, Volta	GTX 750 Ti, GTX 900, GTX 10 series, Titan V, Tesla V100, Quadro GV100	akmod-nvidia-580xx	Proprietary on these cards, open on Turing and newer
Kepler	GTX 600, GTX 700 (most)	akmod-nvidia-470xx	Proprietary, Xorg only
Fermi	GTX 400, GTX 500	akmod-nvidia-390xx	Proprietary, Xorg only

The 580xx row is the one that bites people after an upgrade. NVIDIA’s own supported-gpus.json, shipped inside the current driver source, marks 305 entries with "legacybranch": "580.xx" in the 615 source we unpacked in November. The GTX 980, GTX 980 Ti, GTX 1080 (PCI ID 10de:1b80) and Tesla V100 are all in that list, which means the current driver does not support them. Volta belongs in the same row: NVIDIA’s deprecation schedule names 580 as the last branch for Maxwell, Pascal and Volta.

We ran the current and 580xx packages; the 470xx and 390xx rows follow the RPM Fusion NVIDIA howto and were not run on hardware. RPM Fusion supports both only on the current stable Xorg server. Its howto words the 580xx row the same way, and we did not test a Wayland desktop on 580xx. 390xx is end of life at NVIDIA, kept on a best-effort basis that a newer kernel can break. Fedora Workstation’s GNOME session is Wayland only, so treat a Kepler or Fermi desktop on Fedora 45 as unsupported.

The GPU’s PCI ID and the Secure Boot state

Two facts decide everything that follows: which card you have, and whether the firmware enforces module signatures. You need a Fedora 45 or Fedora 44 install with sudo access and a network path to the RPM Fusion mirrors. Install pciutils first, then read the GPU’s PCI ID:

sudo dnf install -y pciutils
lspci -nn | grep -i nvidia

The ID in the last bracket (10de:1eb8 on our October T4 GPU host) is what the driver package matches against:

00:1e.0 3D controller [0302]: NVIDIA Corporation TU104GL [Tesla T4] [10de:1eb8] (rev a1)

Now check whether Secure Boot is on. This single answer decides whether you need the key enrollment section:

mokutil --sb-state

Both November VMs booted OVMF with the Microsoft keys enrolled, and both reported it on:

SecureBoot enabled

Before you go further, these should hold on your machine:

• The PCI ID maps to one row of the table above, and you know which package that row names.
• You know whether mokutil --sb-state said enabled or disabled.
• You can reach the console at boot, because enrolling a key needs one keypress there.

Do not turn Secure Boot off to make the driver load. Enrolling one key costs a single extra reboot, and it keeps shim, GRUB and the kernel verified against tampering before the OS starts, with kernel lockdown on top (/sys/kernel/security/lockdown read [integrity] on our Fedora 45 VM). Be clear about what it doesn’t stop: the akmods private key lives on this disk, so a process that already has root can sign its own module with it. That is why RPM Fusion calls protecting the key a mandatory requirement, and the key section below covers it.

RPM Fusion and a current kernel

The driver lives in RPM Fusion nonfree, which needs the free repo as well. If you already enabled both repos for multimedia codecs on Fedora (dnf repolist | grep rpmfusion lists free and nonfree), skip this command:

sudo dnf install -y https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm

Confirm what the repo will hand you before you install anything. This is the check that tells you whether R620 has landed yet:

dnf list --available akmod-nvidia akmod-nvidia-580xx

Fedora 44 showed the same two versions from rpmfusion-nonfree-updates. On Fedora 45 both the current branch and the legacy branch came from rpmfusion-nonfree:

Then bring the system fully up to date and install the akmods tooling in the same pass. mokutil and openssl are only needed with Secure Boot, but they cost nothing to have. On the minimal Fedora 45 cloud image this pulled 81 packages:

sudo dnf upgrade -y --refresh
sudo dnf install -y akmods mokutil openssl
sudo systemctl reboot

Do not skip this reboot. akmod builds against the newest installed kernel-devel, so a kernel that arrives in the upgrade gets the module and the one you’re running doesn’t. We skipped the reboot on purpose on the Fedora 44 VM: a newer kernel was installed but not booted, the driver install built its module for that kernel, and modinfo found nothing for the running one until the next boot. The reboot also lets the akmods keygen service create the signing key, which happens on the first boot after akmods is installed.

The akmods signing key under Secure Boot

With Secure Boot enforcing, the kernel loads only modules signed by a key it trusts. akmods signs every module it builds with a machine-local key in /etc/pki/akmods/, so that key has to be enrolled in the MOK list once. On the Fedora 45 VM the unit [email protected] created it at boot, named after the host, with a public_key.der symlink pointing at the current certificate. The directory is readable only by root and the akmods group, so list it with sudo:

sudo ls -l /etc/pki/akmods/certs/

You should see one certificate and the symlink to it.

total 8
lrwxrwxrwx. 1 root akmods   55 Nov  4 16:18 public_key.der -> /etc/pki/akmods/certs/rpm-lab01_1793809105_98da2c08.der
-rw-r-----. 1 root akmods 1577 Nov  4 16:18 rpm-lab01_1793809105_98da2c08.der

If that lists nothing, sudo kmodgenca -a generates the key by hand, which is the command the RPM Fusion Secure Boot howto gives. The private key sits next to it in /etc/pki/akmods/private/, so anyone who can read it, root included, can sign modules your firmware will trust. RPM Fusion’s answer is to encrypt the root filesystem, which protects the key while the machine is off, or to keep the key on external storage or a hardware token. Keep the akmods group empty of people either way. Confirm the firmware doesn’t trust the key yet:

sudo mokutil --test-key /etc/pki/akmods/certs/public_key.der

A fresh key reports that it is not enrolled.

/etc/pki/akmods/certs/public_key.der is not enrolled

Queue it for enrollment. mokutil asks for a one-time password twice. You type it again at the firmware screen, where the keyboard is mapped to QWERTY, so keep it short and avoid symbols if your layout is not QWERTY:

sudo mokutil --import /etc/pki/akmods/certs/public_key.der

Check the pending request as root. Without sudo, mokutil --list-new prints nothing and exits 0, which looks exactly like a failed import, and it did the same on the November VM:

sudo mokutil --list-new | grep -E "^\[key|SHA1 Fingerprint|Subject:|Not After"

Note the fingerprint. You compare it against the firmware screen in a minute:

[key 1]
SHA1 Fingerprint: 0c:ca:e0:c2:d8:59:83:d7:a2:f0:68:cc:8f:5e:dd:5d:23:dc:32:96
            Not After : Nov  1 16:18:26 2036 GMT
        Subject: O=rpm-lab01, OU=rpm-lab01/emailAddress=akmods@rpm-lab01, L=None, ST=None, C=US, CN=rpm-lab01_1793809105_98da2c08

Reboot and stay at the console. Shim shows a short “Press any key” countdown before MokManager opens, and missing it is not harmless. When the countdown expired on our November VM, the boot carried on and the request was gone: mokutil --test-key said “not enrolled” again, so the import had to be repeated. The MokManager screens below are from our October Secure Boot VM, where the keypress was made. Work through them in this order:

1. Press a key while the countdown is up, then choose Enroll MOK.
2. Choose View key 0 and check the Fingerprint against the mokutil --list-new output.
3. Press Enter to go back, choose Continue, answer Yes to “Enroll the key(s)?” and type the password.
4. Pick Reboot.

The first screen is the MokManager menu with the pending request waiting behind Enroll MOK:

Do not skip View key 0. It’s the only point where you can check that the key you’re about to trust is the one akmods generated. The Fingerprint block below belongs to the October VM’s key and matched that VM’s own mokutil output; yours must match the value your machine printed, not ours:

Back in Fedora on the October VM, the key was in the MOK list and the kernel loaded it at boot:

That VM has no GPU, so modprobe still fails there, with could not insert 'nvidia': No such device, and dmesg logs NVRM: No NVIDIA GPU found. That pair is the proof the signature passed: the kernel accepted the module and the driver then looked for hardware. RPM Fusion tells you to enroll before installing the kmod, and that’s the order here. We had once built the driver first and enrolled afterwards, and the existing module loaded without a rebuild, because it was already signed with the same key. A firmware update can wipe the MOK list. If the driver stops loading after one, run the same mokutil --import again.

Install the NVIDIA driver and wait for the kmod build

For a Turing or newer GPU, install the akmod and the CUDA user-space libraries. The -cuda package also carries nvidia-smi. GTX 900, GTX 10 and Volta owners: stop here and use the 580xx section further down instead. If you installed the driver as a dependency of something else, run sudo dnf mark user akmod-nvidia afterwards, or a later dnf autoremove can take the akmod and its compiler with it.

sudo dnf install -y akmod-nvidia xorg-x11-drv-nvidia-cuda

How much that pulls depends on what’s already installed. These are the counts from the two November VMs, both minimal cloud images with akmods already in place:

• Fedora 45 installed 244 packages, and dnf finished in 3 minutes 6 seconds.
• Fedora 44 installed 281 packages, and dnf finished in 3 minutes.
• Both pulled the compiler toolchain, kernel-devel and a stack of desktop libraries that a Workstation install already has.

dnf returns before the kernel module exists. The akmod builds it in the background, and if you reboot in the middle of that build the next boot has no module for its kernel. Since nouveau is already blacklisted, the GPU then has no driver at all until a build completes. Wait for it with a loop that checks the newest installed kernel, which also covers the case where the install pulled a new kernel in:

K=$(rpm -q --qf "%{VERSION}-%{RELEASE}.%{ARCH}\n" kernel-core | sort -V | tail -1); until modinfo -k $K nvidia >/dev/null 2>&1; do sleep 5; done; date +%T; echo $K; modinfo -k $K -F version nvidia; modinfo -k $K -F license nvidia; ls /var/cache/akmods/nvidia/

On the 4 vCPU Fedora 45 VM the module existed 76 seconds after dnf returned. The build log and the kmod RPM it produced sit in /var/cache/akmods/nvidia/, and the log already says which kernel module flavor it built. The capture shows the loop as we first ran it, with an echo newest= label and plain modinfo lines; with the newest kernel already running, both forms print the same thing:

RPM Fusion puts a normal build at up to five minutes. If the loop is still waiting well past that, the build failed, and its log is in /var/cache/akmods/. After the install, the boot command line blacklists the in-kernel drivers on both releases: nouveau and nova_core, the newer Rust driver for recent NVIDIA GPUs:

sudo grubby --info=DEFAULT | grep ^args

Both names appear twice, once for the initramfs and once for the running system.

args="ro rootflags=subvol=root no_timer_check console=tty1 console=ttyS0,115200n8 systemd.firstboot=off rootflags=subvol=root rd.driver.blacklist=nouveau,nova_core modprobe.blacklist=nouveau,nova_core"

If the key isn’t enrolled yet, this is the moment it shows. On the November VM, with the import still pending, sudo modprobe nvidia stopped at the signature check with “Key was rejected by service”, which is covered in the errors section at the end.

Proof the driver and CUDA work

Reboot once the module exists, because the running kernel only picks up the new module and the blacklist on the next boot.

sudo systemctl reboot

The November VMs have no GPU, so the output in this section comes from the October run on a Tesla T4 cloud host with the previous 615 build, the same branch RPM Fusion still serves. After the reboot, nvidia, nvidia_modeset, nvidia_drm and nvidia_uvm are loaded, nouveau is not, and nvidia-smi sees the card:

The header changed in the 615 branch. It now reads KMD Version and CUDA UMD Version, where the 580xx driver still prints Driver Version and CUDA Version. Scripts that grep the old labels need updating.

nvidia-smi working does not prove CUDA works. A short Python script that calls the CUDA driver API directly does, without installing the CUDA toolkit. Create it:

vim ~/cuda-check.py

Paste this. It creates a context on each GPU and allocates 256 MiB of device memory:

import ctypes
cuda = ctypes.CDLL("libcuda.so.1")
assert cuda.cuInit(0) == 0
n = ctypes.c_int(); cuda.cuDeviceGetCount(ctypes.byref(n))
v = ctypes.c_int(); cuda.cuDriverGetVersion(ctypes.byref(v))
print(f"CUDA driver API {v.value // 1000}.{(v.value % 1000) // 10}, devices: {n.value}")
for i in range(n.value):
    dev = ctypes.c_int(); cuda.cuDeviceGet(ctypes.byref(dev), i)
    name = ctypes.create_string_buffer(100); cuda.cuDeviceGetName(name, 100, dev)
    mem = ctypes.c_size_t(); cuda.cuDeviceTotalMem_v2(ctypes.byref(mem), dev)
    ma, mi = ctypes.c_int(), ctypes.c_int()
    cuda.cuDeviceGetAttribute(ctypes.byref(ma), 75, dev); cuda.cuDeviceGetAttribute(ctypes.byref(mi), 76, dev)
    ctx = ctypes.c_void_p(); rc = cuda.cuCtxCreate_v2(ctypes.byref(ctx), 0, dev)
    free, total = ctypes.c_size_t(), ctypes.c_size_t(); cuda.cuMemGetInfo_v2(ctypes.byref(free), ctypes.byref(total))
    ptr = ctypes.c_uint64(); arc = cuda.cuMemAlloc_v2(ctypes.byref(ptr), 256 * 1024 * 1024)
    print(f"GPU {i}: {name.value.decode()}, compute {ma.value}.{mi.value}, {mem.value // 2**20} MiB, context rc={rc}, 256 MiB alloc rc={arc}")
    cuda.cuMemFree_v2(ptr); cuda.cuCtxDestroy_v2(ctx)

Run it as your normal user, not root, so a permissions problem on /dev/nvidia* shows up here instead of in your first real job.

python3 ~/cuda-check.py

Both return codes must be 0, because a context and an allocation are the first things any CUDA program does. Anything else means the user-space libraries and the kernel module disagree, so check with rpm -qa "*nvidia*" that the -cuda-libs package and the kmod come from the same branch before you blame the card.

CUDA driver API 13.4, devices: 1
GPU 0: Tesla T4, compute 7.5, 14927 MiB, context rc=0, 256 MiB alloc rc=0

Tools that bundle their own CUDA runtime, such as the PyTorch pip wheels, need only this driver. Compiling CUDA code needs NVIDIA’s toolkit on top, and the CUDA on Ubuntu guide covers that side. For long-running GPU hosts, wire the card into DCGM, Prometheus and Grafana monitoring. nvidia-persistenced is installed but disabled by default, so on headless compute boxes run sudo systemctl enable --now nvidia-persistenced if you want the GPU kept initialized between jobs.

Our GPU host was a headless cloud instance with a datacenter card that has no display outputs, so this lab did not test a GNOME or KDE session on the driver. The kernel module, nvidia-smi and CUDA paths above are what we verified.

Open or proprietary kernel module: what akmod builds

You don’t choose the module flavor at install time. The RPM Fusion kmod spec ships both kernel and kernel-open source trees and runs a detection script during the build. The script reads lspci and compares every NVIDIA PCI ID against a list of GPUs the open module does not support. A match builds the proprietary module, and no match builds the open one. Check your own machine after the build:

grep -E "Runtime detection|matching graphics|Using nvidia-open|Not using" /var/cache/akmods/nvidia/*.log | tail -3

The Fedora 45 VM has no NVIDIA card, so nothing matched and it picked the open module, the same answer the T4 got in October:

2026/11/04 16:23:09 akmodsbuild: Runtime detection of kmod_nvidia_open
2026/11/04 16:23:09 akmodsbuild: No matching graphics card found.
2026/11/04 16:23:09 akmodsbuild: Using nvidia-open

modinfo -F license nvidia gives the same answer at a glance: the open module reports Dual MIT/GPL. One packaging detail changed since October. The current akmod-nvidia used to ship an empty exclusion list; the November build ships 160 PCI IDs (we counted them in its source RPM), byte for byte the same file as akmod-nvidia-580xx, with the GTX 1080’s 10de:1b80 and the Tesla V100’s 10de:1db4 among them. So a GTX 1080 on the current package now gets the proprietary module instead of the open one. That does not rescue the card: the 615 driver still lists it under the 580 legacy branch, so the 580xx package remains the fix. The choice is made once, when the module is built, so after a GPU swap or a move to another machine the old flavor stays until sudo akmods --rebuild runs.

The 580xx legacy driver for GTX 900, GTX 10 and Volta

On a clean system, install the legacy branch directly instead of the current driver:

sudo dnf install -y akmod-nvidia-580xx xorg-x11-drv-nvidia-580xx-cuda

Wait for the build with the same newest-kernel loop. Only the cache directory changes, because the 580xx akmod keeps its logs apart from the current branch.

K=$(rpm -q --qf "%{VERSION}-%{RELEASE}.%{ARCH}\n" kernel-core | sort -V | tail -1); until modinfo -k $K nvidia >/dev/null 2>&1; do sleep 5; done; date +%T; echo $K; modinfo -k $K -F version nvidia; modinfo -k $K -F license nvidia; ls /var/cache/akmods/nvidia-580xx/

On the Fedora 45 VM the install took 224 packages and the loop returned 66 seconds after dnf finished, with the 580xx kmod built for the running kernel:

16:33:34
7.2.15-300.fc45.x86_64
580.196.07
Dual MIT/GPL
580.196.07-1-for-7.2.15-300.fc45.x86_64.log
kmod-nvidia-580xx-7.2.15-300.fc45.x86_64-580.196.07-1.fc45.x86_64.rpm

Reboot once it returns. If the current driver is already installed, which is what happens when a GTX 1080 owner follows an old guide, the swap is now one command. In October, --allowerasing left the other branch’s -libs packages in place and the RPM transaction died on file conflicts. With the November packages it planned 8 installs and 8 removals, removed both -libs packages, and finished with zero conflicts:

sudo dnf install -y --allowerasing akmod-nvidia-580xx xorg-x11-drv-nvidia-580xx-cuda

The same transaction removes the 615 kmod for your running kernel, so wait for the 580xx build with the loop above before you reboot, or the next boot has no NVIDIA module at all. The new module is signed with the same akmods key, so an enrolled machine needs no second trip to MokManager. One package is left behind:

Remove that orphaned source package, since nothing builds from it any more:

sudo dnf remove xorg-x11-drv-nvidia-kmodsrc

After the swap, check these on your machine:

• rpm -q akmod-nvidia reports it is not installed, and only akmod-nvidia-580xx remains.
• modinfo -F signer nvidia prints the same akmods key name as before the swap.
• dnf repoquery --installed --unneeded | grep -i nvidia prints nothing once the old xorg-x11-drv-nvidia-kmodsrc is gone.
• nvidia-modprobe and nvidia-persistenced stay on their 615 builds, which is expected, because the 580xx branch shares them.

If you’d rather start from nothing, the glob RPM Fusion documents still works: sudo dnf remove "xorg-x11-drv-nvidia*" removed 225 packages on the VM (there it took out the 580xx stack after the swap, while akmods and kernel-devel stayed), and the 580xx install then put 224 back. Don’t widen the pattern to "*nvidia*". That glob also matches nvidia-gpu-firmware, the firmware nouveau and nova_core load, which Fedora Workstation installs, and the RPM Fusion howto warns that any other removal command takes packages the free driver still needs.

An earlier run of the swap on a Fedora 44 GPU host taught one more thing. On the T4 the 580xx package built the open module, and CUDA reported driver API 13.0 instead of 13.4. On a real Pascal or Volta card the detection script picks the proprietary module from its exclusion list. We could not run that on hardware in this lab.

What happens on a kernel update

akmods.service is enabled by default and runs on every boot. It checks that a kmod exists for the booted kernel and builds one if it doesn’t. On a boot where nothing changed it finishes in about a second:

sudo journalctl -b -u akmods --no-pager | tail -3

The journal from the Fedora 45 VM after the driver reboot showed the check passing in the same second it started.

Nov 04 16:23:54 rpm-lab01 systemd[1]: Starting akmods.service - Builds and install new kmods from akmod packages...
Nov 04 16:23:54 rpm-lab01 akmods[700]: Checking kmods exist for 7.2.15-300.fc45.x86_64 [  OK  ]
Nov 04 16:23:54 rpm-lab01 systemd[1]: Finished akmods.service - Builds and install new kmods from akmod packages.

An akmod install builds for the newest installed kernel, and a kernel that arrives later gets its kmod from akmods.service on the first boot into it. The risk is a module that built but is broken, or a build that failed. Here --force does not do what most people expect: it retries builds that failed earlier, and on a working system it only prints the “Checking kmods exist” line. To actually recompile for the running kernel, use --rebuild:

time sudo akmods --rebuild --kernels $(uname -r)

It rebuilt and installed the module in 2 minutes 8 seconds on 4 vCPUs:

Checking kmods exist for 7.2.15-300.fc45.x86_64 [  OK  ]
Building and installing nvidia-kmod [  OK  ]

real	2m8.517s
user	5m2.454s
sys	0m54.021s

Keep at least one older kernel installed (Fedora keeps three by default) so a failed build never leaves you without a bootable fallback. A release upgrade replaces the kernel too, so read the Fedora 44 to 45 upgrade guide before you move a GPU workstation across.

Driver errors from the lab, and the fix for each

Each of these came up on the lab machines, except the nouveau fallback message, which we read from its unit file. Match the exact text before you apply a fix.

modprobe: ERROR: could not insert ‘nvidia’: Key was rejected by service

Secure Boot is on and the akmods key is not enrolled. The module is signed, by a key the firmware has never seen, and dmesg adds “Loading of module with unavailable key is rejected”. We reproduced it on the November VM with the import still pending:

The signer field matches the akmods key name, so the build is fine. Finish the enrollment in MokManager and reboot. You don’t need to rebuild the module, because the signature already on it is the one the firmware learns to trust.

modinfo: ERROR: Module nvidia not found

Right after dnf finishes, this just means the akmod build is still running, so wait with the loop. If it persists, compare uname -r with rpm -q kernel-devel. On the Fedora 44 VM a newer kernel was installed but not booted, and the module existed only for that one:

A version string from the newest kernel means the module is waiting for it. Reboot into that kernel and the error is gone, so there’s nothing to rebuild. If the newest kernel prints the same error, the build failed and its log in /var/cache/akmods/nvidia/ says why.

NVIDIA kernel module missing. Falling back to nouveau

That message comes from nvidia-fallback.service, shipped in xorg-x11-drv-nvidia. It runs only when nouveau is blacklisted on the kernel command line and the nvidia module did not load:

systemctl cat nvidia-fallback.service

The unit loads nouveau and prints the message to the boot splash. The output below is trimmed after the unit itself; Fedora’s generic 10-timeout-abort.conf drop-in follows it.

# /usr/lib/systemd/system/nvidia-fallback.service
[Unit]
Description=Fallback to nouveau as nvidia did not load
After=akmods.service
Before=display-manager.service
ConditionKernelCommandLine=rd.driver.blacklist=nouveau,nova_core
ConditionPathExists=!/sys/module/nvidia


[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=-/sbin/modprobe nouveau
ExecStartPost=-/bin/plymouth message --text="NVIDIA kernel module missing. Falling back to nouveau"


[Install]
WantedBy=graphical.target

It is a symptom, not the cause. The three causes we can account for are an unenrolled key (the first error above), a reboot before the build finished, and a GTX 900, GTX 10 or Volta card on the current akmod-nvidia, which needs the 580xx branch. The kernel log tells you which one you have:

sudo dmesg | grep -iE "nvidia|NVRM|rejected"

The unit was disabled on the November VMs and on our GPU hosts before them. So on a stock install, a failed load most likely leaves the GPU without a driver and never shows this message. We read that from the unit and its state; no GPU host in the lab had a failed load.

mokutil –list-new prints nothing after an import

Run it with sudo. As a normal user it prints nothing and exits 0. That made our first import look like a failure when the request was already queued. sudo mokutil --test-key settles it: “already in the enrollment request” means reboot and finish in MokManager, while “not enrolled” after a reboot means the countdown ran out and you need to import again.

If the card is for games, gaming on Fedora picks up from here with Steam, Proton, NTSYNC and MangoHud on this driver, and Fedora vs Bazzite compares how the two ship it. For the rest of a new Workstation build, the things to do after installing Fedora 45 list picks up where the driver leaves off. If an old .run installer is still on the box, clear it out with the manual NVIDIA driver removal steps before you install the RPM Fusion packages.