Secure Boot is blocking your GPU driver module

Linux

Written by Jakub Rusinowski · Last updated September 1, 2026

AI educator & workshop leader on local LLM deployment

The error

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

[  4.512901] Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7
[  4.513002] nvidia: module verification failed: signature and/or required key missing - tainting kernel

Which one is it?

If you see	The cause is	Go to
`modprobe` reports "Key was rejected by service"	The module is unsigned and Secure Boot will not load it	Fix 2: enrol a Machine Owner Key
`mokutil --sb-state` prints "SecureBoot enabled"	Confirms the mechanism — module signing is being enforced	Fix 1: you are in the right place
You enrolled a key and nothing changed after rebooting	The blue MOK Manager screen was missed or timed out at boot	Fix 3: re-import and stay at the machine
`dkms status` shows the module as built and installed	Building is not the problem — loading is	Fix 2, not the kernel-update page
No MOK key was generated during the driver install	The distro did not create one, so nothing exists to enrol	Fix 4: sign the module manually

When you see it

This one is deceptive because every step reports success. The driver package installs cleanly. DKMS builds the module for your kernel and says so. And then the module will not load, with an error about keys that sounds like something is corrupt.

You installed the NVIDIA driver on a machine that shipped with Secure Boot on — most retail laptops and prebuilt desktops.
You enabled Secure Boot yourself to dual-boot Windows 11, and the GPU stopped working on the Linux side.
dkms status shows the module built against your running kernel, yet nvidia-smi fails.
You are on Fedora, where Secure Boot is on by default on most hardware.
You built an out-of-tree amdgpu-dkms module and hit exactly the same wall.

What's actually going on

With UEFI Secure Boot enabled, the kernel refuses to load any module that is not signed by a key the firmware trusts. Modules shipped in the kernel itself are signed by the distribution; a module built on your machine by DKMS is not signed by anyone until you sign it. So the build succeeds — compilation was never the issue — and the load fails. dmesg states it precisely: *module verification failed: signature and/or required key missing*. The mechanism that resolves this is a Machine Owner Key (MOK): you generate a key, enrol it into the firmware's trust store through a one-time confirmation at boot, and the module gets signed with it. This applies equally to AMD's out-of-tree amdgpu-dkms builds, which is why this page is tagged for both vendors.

How to fix it

1. Confirm Secure Boot is what is actually stopping you

Two commands separate this from every other reason a module will not load. mokutil --sb-state reports whether Secure Boot is enabled at all, and dmesg will contain the verification failure if it is the cause. If Secure Boot is disabled, this is the wrong page and the kernel-update page is the right one.

bash

# bash
mokutil --sb-state
dmesg | grep -iE 'lockdown|module verif|key was rejected'
dkms status

Did it work? SecureBoot enabled plus a verification-failure line in dmesg confirms the diagnosis. A module DKMS reports as installed that still will not load is the signature of this problem.

2. Enrol a Machine Owner Key — the fix we recommend

On Ubuntu and Debian the driver install generates a key at /var/lib/shim-signed/mok/MOK.der and offers to enrol it. If you skipped that prompt, import it now. mokutil --import asks you to set a one-time password, which you will be asked for at the next boot — choose something you can type on a US keyboard layout, because the MOK Manager screen does not use your configured layout.

bash

# bash — Ubuntu / Debian
sudo mokutil --import /var/lib/shim-signed/mok/MOK.der
# set a one-time password when prompted, then:
sudo reboot

Did it work? After completing enrolment at boot, the key is listed as enrolled and the module loads.

mokutil --list-enrolled | grep -i -A2 "Subject:"
sudo modprobe nvidia && nvidia-smi

3. Complete the enrolment at boot — the step everyone misses

On the next boot a blue MOK Manager screen appears before the bootloader. Choose Enroll MOK → Continue → Yes, enter the one-time password you set, then Reboot. This screen appears only at boot and it times out, and if you miss it — you walked away, the machine is headless, you assumed it was a normal boot delay — the enrolment is silently discarded and you are back where you started with no error to explain it. If you missed it, simply run mokutil --import again and stay at the machine.

⚠️ A headless or remote machine cannot complete this step: MOK Manager needs a physical console and a keyboard. Plan for a monitor, IPMI, or a KVM before you start on a server.

bash

# bash — after the reboot, did it take?
mokutil --list-enrolled | grep -ci "subject"
sudo modprobe nvidia
nvidia-smi

Did it work? modprobe nvidia returns with no output — silence is success — and nvidia-smi prints the GPU table.

nvidia-smi --query-gpu=name,driver_version --format=csv

4. Sign the module by hand when no MOK was generated

Some distributions and some install routes never create a key. Generate one, enrol it as in fix 2, and sign the built module with the kernel's sign-file helper. You must re-sign after every DKMS rebuild — that is, after every kernel update — unless you configure DKMS to sign automatically, which is the durable version of this fix. On Fedora the concept is identical, using its akmods signing flow with kmodsign.

⚠️ Keep MOK.priv readable only by root. Anyone who can read that private key can sign a kernel module your machine will then trust, which is precisely the property Secure Boot exists to protect.

bash

# bash — generate a key, then sign the built module
sudo openssl req -new -x509 -newkey rsa:2048 -nodes -days 36500 \
  -keyout /root/MOK.priv -outform DER -out /root/MOK.der \
  -subj "/CN=Local module signing/"
sudo chmod 600 /root/MOK.priv
sudo mokutil --import /root/MOK.der   # enrol at next boot, as in fix 2

# After the reboot, sign the module
sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 \
  /root/MOK.priv /root/MOK.der \
  /lib/modules/$(uname -r)/updates/dkms/nvidia.ko

Did it work? The module now carries a signature and loads. modinfo lists a signer.

modinfo nvidia | grep -i sig
sudo modprobe nvidia && nvidia-smi

5. Disabling Secure Boot — the last resort, not the first

You can turn Secure Boot off in your firmware setup and the module will load immediately. Most other pages lead with this, and it is the worst of the options here: Secure Boot is what stops a bootkit persisting across reinstalls, and turning it off to load one driver removes that protection permanently for everything on the machine. It also breaks BitLocker on a dual-boot Windows install, which will demand your recovery key on the next boot. Enrol a key instead — it takes five more minutes, once.

⚠️ This disables boot-chain verification for the whole machine, and on a dual-boot system it will trigger a BitLocker recovery prompt on the Windows side. Have your BitLocker recovery key to hand before you change this setting.

bash

# bash — confirm the state after changing firmware settings
mokutil --sb-state

6. While you sort the signing out, keep working Most common fix

Enrolment needs a reboot and physical access, which you may not have right now. CPU inference still works — the module being unloaded costs you the GPU, not the machine — and a small model at Q4 is genuinely usable for chat and light editing in the meantime. Pick one sized for your CPU rather than retrying the GPU model and concluding everything is broken.

bash

# bash — usable on CPU while the module is unsigned
ollama run gemma3:1b
ollama ps

Check what fits your hardware — find a model that stays usable on CPU until the module loads
Open the VRAM checker →

If none of this worked

If the key is enrolled and the module still refuses, check whether it was actually built for the kernel you are running — a signature problem and a missing-module problem produce different dmesg lines and have different pages. AMD readers hitting this on amdgpu-dkms should follow the same enrolment path, then continue with the ROCm pages.

Include this when you report it

Output of mokutil --sb-state and mokutil --list-enrolled | grep -i subject
The dmesg | grep -iE "lockdown|module verif" lines
dkms status and modinfo nvidia | grep -i sig
Your distribution, and whether the machine dual-boots Windows with BitLocker

A model that fits most setups:

View model & requirements →

Frequently asked questions

Why does the driver build fine but not load?

Because building and loading are different steps with different requirements. DKMS compiles the module successfully; the kernel then refuses to load it because Secure Boot requires a signature from a trusted key, and a locally built module has none until you sign it.

What is a Machine Owner Key?

A signing key you own, enrolled into the firmware's trust store through a one-time confirmation at boot. Once enrolled, modules signed with it load normally under Secure Boot. It is the intended mechanism for locally built drivers and it does not weaken the boot chain.

I enrolled a key and nothing changed. What went wrong?

Almost certainly the blue MOK Manager screen at the next boot was missed or timed out, which discards the enrolment silently. Run mokutil --import again and stay at the machine through the reboot. Note the screen uses a US keyboard layout for the password.

Do I have to re-sign after every kernel update?

If you are signing manually, yes — DKMS rebuilds the module for each new kernel and the rebuilt module is unsigned. Configuring DKMS to sign automatically with your key removes the chore. Distro-generated MOK setups usually handle this for you.

Is it really that bad to just disable Secure Boot?

It is a real reduction in protection: Secure Boot is what prevents a bootkit persisting across reinstalls. On a dual-boot machine it also triggers a BitLocker recovery prompt on the Windows side. Enrolling a key achieves the same result and takes about five minutes more.