Secure Boot is supposed to keep your system safer. Then you install a driver update, reboot, and suddenly your GPU falls off the planet, Wi‑Fi vanishes, or VirtualBox starts acting like it never met your kernel before. The logs say “verification failed.” The machine says “no.” And your calendar says you have a meeting in six minutes.
This is the reality of Ubuntu 24.04 on modern UEFI systems: Secure Boot + out-of-tree kernel modules (NVIDIA, VirtualBox, ZFS DKMS, vendor Wi‑Fi drivers, EDR agents) is a contract. If you don’t sign, you don’t run. The fix is not “reinstall Ubuntu.” The fix is to diagnose what’s being blocked and either (a) enroll a key and sign the modules, or (b) deliberately disable Secure Boot with eyes open. You can keep your setup intact.
Fast diagnosis playbook
If you need a working system fast, don’t start by reinstalling drivers. Don’t start by rebuilding the kernel. Start by proving what policy you’re under and what exactly is being rejected.
First: confirm Secure Boot state and module enforcement
- Is Secure Boot enabled? If it’s disabled, stop blaming it and look elsewhere.
- Is the kernel enforcing module signatures? Ubuntu can enforce signatures when Secure Boot is on. That flips a lot of “it used to work” into “it’s blocked now.”
- What module is failing to load? You want the module name and the error string.
Second: identify the module source and lifecycle
- Is it a DKMS module? DKMS means “rebuilt on upgrades,” which means “will keep breaking until signing is automated.”
- Is it from Ubuntu packages? If yes, there are official integration points (like MOK prompts during install) you can leverage.
- Is it vendor-provided? If yes, it may ship unsigned binaries or its own signing story.
Third: decide between two sane remediation strategies
- Preferred for managed fleets: keep Secure Boot enabled, enroll a Machine Owner Key (MOK), and sign your out-of-tree modules (preferably automatically).
- Acceptable for single-user workstations with clear risk tolerance: disable Secure Boot in firmware and move on—document the decision so Future You doesn’t spend a night chasing ghosts.
One operational truth: the fastest “fix” is often disabling Secure Boot, and the best fix is almost never that. The difference is whether this machine needs to be defensible under audit and whether you ever want upgrades to stop being an adventure.
What Secure Boot is actually doing on Ubuntu 24.04
Secure Boot is a UEFI feature that verifies the signatures of bootloaders and (on most modern Linux distributions) can extend trust into the kernel’s module-loading path. On Ubuntu, the chain is typically: firmware verifies shim, shim verifies GRUB and the kernel, and then the kernel uses keys (built-in and enrolled) to decide which kernel modules are allowed to load.
Here’s the punchline: if Secure Boot is enabled and your kernel is in signature-enforcing mode, a kernel module without a trusted signature loads like a fake ID at a nightclub—no matter how “legit” it feels to you.
Ubuntu tries to make this tolerable using the Machine Owner Key (MOK) system: you generate or install a signing key, enroll the public part via UEFI MOK Manager at boot, then sign your modules with the private key. Once enrolled, the kernel trusts modules signed by that key.
The part that bites people is timing. You install a driver, DKMS builds a module, and everything looks fine—until the reboot where Secure Boot enforcement makes the kernel reject it. Your driver “installed” and still doesn’t work. Welcome to policy-driven computing.
One paraphrased idea (not verbatim) from James Hamilton (Amazon, reliability): “You get reliability by designing for failure as a normal state, not a surprise event.” Secure Boot module rejection is failure as policy; treat it like an engineered condition, not a weird bug.
Facts and context you’ll wish you knew earlier
- Secure Boot shipped with Windows 8-era hardware requirements (2012ish) and became mainstream because OEMs started enabling it by default.
- Ubuntu uses “shim” specifically to work in the Microsoft UEFI CA ecosystem so systems can boot Linux without every user managing their own platform keys.
- MOK exists because asking every user to replace firmware keys is unrealistic and often impossible on locked-down laptops.
- Kernel module signature enforcement is not universal across all distros; some treat it as optional even with Secure Boot enabled, while Ubuntu tends to enforce for unsigned out-of-tree modules.
- DKMS is a double-edged sword: it rebuilds modules automatically for new kernels, which is great—until you realize unsigned rebuilds are automatically broken under Secure Boot.
- NVIDIA drivers are a recurring pain point because they live outside the kernel tree and many setups rely on DKMS builds for the exact running kernel.
- VirtualBox’s
vboxdrvis a classic example of a module that “works until reboot” when Secure Boot is enforcing signatures. - The kernel has multiple keyrings involved (builtin, secondary, MOK/Platform); debugging is easier once you accept you’re dealing with keyrings, not vibes.
- Some systems silently reset Secure Boot settings during firmware updates, which is how you can “suddenly” start seeing module rejection on a previously stable workstation.
Core diagnosis tasks (commands, outputs, decisions)
These are the tasks I run in production when Secure Boot blocks drivers. Each one includes: command, realistic output, what it means, and what decision to make.
Task 1: Check whether Secure Boot is enabled
cr0x@server:~$ mokutil --sb-state
SecureBoot enabledMeaning: Firmware says Secure Boot is on, and shim/mokutil can see it.
Decision: Proceed assuming unsigned modules will likely be blocked. If it says “disabled,” your issue is probably not Secure Boot—switch tracks and look at driver compatibility, kernel ABI mismatch, or missing firmware blobs.
Task 2: Confirm you booted in UEFI mode (not legacy/CSM)
cr0x@server:~$ [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
UEFIMeaning: You’re actually in the Secure Boot world. Legacy boot means Secure Boot isn’t in play.
Decision: If you see “BIOS,” stop—your Secure Boot-related fixes won’t apply. Figure out why you’re in legacy mode (firmware setting, boot order, old install) and correct that if required.
Task 3: Check kernel lockdown status
cr0x@server:~$ cat /sys/kernel/security/lockdown
integrityMeaning: Kernel lockdown is active in “integrity” mode, commonly triggered by Secure Boot. This often pairs with signature enforcement and restricts certain low-level operations.
Decision: Expect stricter behavior. If you’re trying to load unsigned modules or use tools that poke kernel memory, you’ll hit walls. Plan for signing rather than “forcing.”
Task 4: Identify the missing driver symptom (module won’t load)
cr0x@server:~$ sudo modprobe nvidia
modprobe: ERROR: could not insert 'nvidia': Key was rejected by serviceMeaning: The module was present but rejected due to signature trust failure.
Decision: This is not a “driver not installed” problem. It’s a trust/signature problem. Go toward MOK enrollment and signing.
Task 5: Read the kernel log for the exact rejection reason
cr0x@server:~$ sudo dmesg -T | tail -n 12
[Sat Dec 28 10:11:41 2025] Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7
[Sat Dec 28 10:11:41 2025] nvidia: module verification failed: signature and/or required key missing - tainting kernel
[Sat Dec 28 10:11:41 2025] nvidia: loading out-of-tree module taints kernel.
[Sat Dec 28 10:11:41 2025] nvidia: module license 'NVIDIA' taints kernel.Meaning: You have both lockdown and verification errors. Note the difference: “tainting kernel” is informational; “restricted” can mean it won’t load at all.
Decision: If it’s restricted/rejected, you must sign/enroll or disable enforcement by disabling Secure Boot. If it loads but taints, the driver is running; your issue is elsewhere.
Task 6: Check whether the module is present and which file is being loaded
cr0x@server:~$ modinfo -n nvidia
/lib/modules/6.8.0-41-generic/updates/dkms/nvidia.koMeaning: The module is coming from DKMS output (updates/dkms). That’s a prime signing target.
Decision: Treat it as “will be rebuilt on kernel upgrade,” therefore “must be signed automatically after rebuild.”
Task 7: Check DKMS status (what’s built for what kernel)
cr0x@server:~$ dkms status
nvidia/550.90.07, 6.8.0-41-generic, x86_64: installed
vboxhost/7.0.20, 6.8.0-41-generic, x86_64: installedMeaning: DKMS has built modules for your current kernel. “Installed” doesn’t mean “loadable under Secure Boot.”
Decision: If Secure Boot is enabled, assume these DKMS products need signing (unless the packaging handles it and the key is enrolled).
Task 8: Check whether any MOK keys are enrolled
cr0x@server:~$ sudo mokutil --list-enrolled | head
[key 1]
SHA1 Fingerprint: 7a:9d:2b:1c:2f:7c:de:aa:8b:10:1b:6c:4f:5b:89:9a:1d:00:aa:41
Subject: CN=Ubuntu Secure Boot Module Signature key
Issuer: CN=Ubuntu Secure Boot Module Signature keyMeaning: A MOK is enrolled. That’s good news, but it might not be the key you’re using (or the module might not be signed at all).
Decision: If there are no enrolled keys, you need to enroll one. If keys exist, verify your module is signed by one of them.
Task 9: Verify whether a module is signed (and by whom)
cr0x@server:~$ modinfo nvidia | egrep -i 'signer|sig_key|sig_hash'
signer: CN=My DKMS Signing Key
sig_key: 3A:7F:1C:2D:4F:AA:11:9B:5A:1C:0D:32:77:2B:10:8F:DE:55:21:90
sig_hashalgo: sha256Meaning: The module is signed. Now the question is whether the signer’s public key is trusted by the kernel (i.e., enrolled via MOK or in the builtin keyring).
Decision: If it’s unsigned (no signer fields), sign it. If it’s signed but still rejected, you likely enrolled a different key than the one used to sign.
Task 10: Confirm which keyrings the kernel has available (operational sanity check)
cr0x@server:~$ sudo keyctl list %:.system_keyring
3 keys in keyring:
260754792: --alswrv 0 0 asymmetric: Ubuntu Secure Boot Module Signature key: X509.rsa
412884911: --alswrv 0 0 asymmetric: Microsoft Windows Production PCA 2011: X509.rsa
101388220: --alswrv 0 0 asymmetric: Canonical Ltd. Secure Boot Signing: X509.rsaMeaning: The system keyring includes Ubuntu/Canonical keys and often Microsoft’s UEFI CA chain. MOK keys may appear in a secondary keyring depending on setup.
Decision: If your custom key doesn’t show up in any relevant keyring, you didn’t enroll it (or you enrolled but didn’t complete the MOK Manager step at boot).
Task 11: Check whether a module is being blocked by Secure Boot policy vs. missing dependency
cr0x@server:~$ sudo modprobe vboxdrv
modprobe: ERROR: could not insert 'vboxdrv': Key was rejected by serviceMeaning: Same signature enforcement pattern. VirtualBox is classic here.
Decision: Don’t reinstall VirtualBox ten times. Sign the module and enroll the key. Reinstalling produces the same unsigned module, just with fresh disappointment.
Task 12: Inspect Secure Boot variables quickly (helps detect “firmware reset” incidents)
cr0x@server:~$ sudo bootctl status | sed -n '1,18p'
System:
Firmware: UEFI 2.70 (American Megatrends 5.17)
Secure Boot: enabled
Setup Mode: user
TPM2 Support: yes
Boot into FW: supported
Current Boot Loader:
Product: systemd-boot 255.4-1ubuntu8
Features: ✓ Boot counting
✓ Menu timeout control
✓ One-shot menu timeout control
✓ EFI variable boot loader controlMeaning: Secure Boot is enabled and the firmware is in user mode (not setup mode). Setup mode can indicate keys were cleared/reset.
Decision: If you see “Setup Mode: setup,” treat it as “platform keys possibly cleared,” which can break previously trusted boot chains and MOK behavior. Escalate to firmware/key management steps.
Task 13: Confirm the running kernel and installed kernels (avoid chasing the wrong ABI)
cr0x@server:~$ uname -r
6.8.0-41-genericcr0x@server:~$ dpkg -l 'linux-image-*' | awk '/^ii/{print $2,$3}' | tail -n 5
linux-image-6.8.0-40-generic 6.8.0-40.40
linux-image-6.8.0-41-generic 6.8.0-41.41
linux-image-generic 6.8.0.41.44Meaning: If DKMS built for one kernel but you booted another, modules won’t match and can fail for reasons unrelated to signatures.
Decision: Make sure DKMS built for the running kernel. If not, rebuild DKMS for the active kernel before signing.
Task 14: Rebuild DKMS for the current kernel (when outputs don’t match)
cr0x@server:~$ sudo dkms autoinstall -k 6.8.0-41-generic
Sign command: /lib/modules/6.8.0-41-generic/build/scripts/sign-file
Signing key: /var/lib/shim-signed/mok/MOK.priv
Public certificate (MOK): /var/lib/shim-signed/mok/MOK.der
Building module:
Cleaning build area...
make -j16 KERNELRELEASE=6.8.0-41-generic...
Installing to /lib/modules/6.8.0-41-generic/updates/dkms/Meaning: This output shows a healthy path: DKMS knows about a signing key and is invoking sign-file.
Decision: If your DKMS output doesn’t mention signing at all and Secure Boot is enabled, you need to set up the signing key integration (or sign modules manually after build).
Task 15: Verify a module signature at the file level (when modinfo is ambiguous)
cr0x@server:~$ sudo tail -c 256 /lib/modules/6.8.0-41-generic/updates/dkms/vboxdrv.ko | strings | tail -n 5
~Module signature appended~
PKCS#7
X.509
sha256
Meaning: The module contains an appended signature blob. This is crude but effective when you need proof quickly.
Decision: If there’s no signature marker, sign it. If there is, but it’s rejected, you have a trust/enrollment mismatch.
Task 16: Make sure you actually completed MOK enrollment at reboot
cr0x@server:~$ sudo mokutil --test-key /var/lib/shim-signed/mok/MOK.der
/var/lib/shim-signed/mok/MOK.der is already enrolledMeaning: The key is enrolled. If you still get rejections, you’re probably signing with a different key, or the module isn’t signed.
Decision: Align “key used for signing” with “key enrolled.” One private key, one public cert enrolled, no improvisation.
Fix paths: pick the least-bad option
There are three real-world approaches. Two are defensible. One is the “I’m going to regret this later” approach.
Path A (best): Keep Secure Boot enabled, enroll MOK, sign modules
This is what you do on fleet systems, corporate laptops, and anything that needs a clean security story. It’s also what you do if you don’t want every kernel upgrade to break your drivers again.
At a high level:
- Generate a signing key pair (private key stays on the machine, ideally with appropriate filesystem permissions).
- Enroll the public certificate via MOK.
- Sign out-of-tree modules (NVIDIA, VirtualBox, ZFS DKMS, vendor modules).
- Ensure DKMS signs automatically on rebuild, or add a post-build hook.
Path B (okay sometimes): Disable Secure Boot in firmware
This is a legitimate decision when you own the risk and you need the machine working now. It’s common on single-purpose lab workstations, air-gapped boxes, or hobby machines. It’s also common when dealing with certain vendor security agents that don’t play nicely with kernel lockdown.
But if you do this on managed endpoints without documenting it, you’re basically leaving a trap for the next on-call engineer (which might also be you, at 2 AM).
Path C (don’t): “Force load” unsigned modules
People look for boot parameters and sysctls to bypass enforcement. That path is inconsistent across kernels, often blocked by lockdown, and tends to crumble during the next update. Also, you’ll end up with an un-auditable system state.
Short joke #1: Secure Boot isn’t “being picky.” It’s just doing the one job we asked it to do, unlike half the software we ship.
Checklists / step-by-step plan
This section is the “do it, don’t debate it” plan. Pick the scenario that matches your system.
Scenario 1: NVIDIA driver installed, but blocked after reboot
- Confirm block is signature-related (Tasks 4 and 5). If you see “Key was rejected by service,” you’re in the right place.
- Identify module path (Task 6). If it’s under
updates/dkms, you’ll sign the DKMS-built module. - Check enrolled keys (Task 8) and whether the module is signed (Task 9).
- If key is missing: enroll a MOK:
cr0x@server:~$ sudo update-secureboot-policy --new-key Creating new MOK key pair... Key created in /var/lib/shim-signed/mok/ Importing new key into MOK... input password:Meaning: Ubuntu generated a keypair and queued the public cert for enrollment. It asks for a one-time password used by MOK Manager at boot.
Decision: Reboot now, complete the enrollment in the blue MOK Manager screen. If you skip it, nothing changes and you’ll waste an hour blaming the wrong layer.
- After reboot, confirm enrollment (Task 16).
- Rebuild + sign via DKMS (Task 14). Then load the module:
cr0x@server:~$ sudo modprobe nvidiaMeaning: No output is success. Linux is polite like that.
Decision: If it loads, verify with:
cr0x@server:~$ nvidia-smi Sat Dec 28 10:26:12 2025 +---------------------------------------------------------------------------------------+ | NVIDIA-SMI 550.90.07 Driver Version: 550.90.07 CUDA Version: 12.4 | +---------------------------------------------------------------------------------------+Meaning: Driver is active.
Decision: Done. Don’t touch firmware settings.
Scenario 2: VirtualBox kernel driver fails (“vboxdrv not loaded”)
- Prove it’s signature rejection (Task 11).
- Check DKMS status (Task 7).
- If DKMS isn’t installed, install the correct package:
cr0x@server:~$ sudo apt-get install virtualbox-dkms Reading package lists... Done Building dependency tree... Done The following NEW packages will be installed: virtualbox-dkmsMeaning: DKMS will build modules for your current kernel.
Decision: With Secure Boot enabled, you still must ensure signing is in place (MOK enrollment).
- Enroll/confirm MOK key (Scenario 1, step 4/5).
- Rebuild DKMS and confirm signing (Task 14). Then:
cr0x@server:~$ sudo modprobe vboxdrvMeaning: Silent success.
Decision: Confirm VirtualBox sees the driver:
cr0x@server:~$ VBoxManage list hostinfo | sed -n '1,12p' Host Information: Host name: server Operating system: Linux Operating system version: Ubuntu 24.04.1 LTS Processor online count: 16 VirtualBox kernel modules: loaded
Scenario 3: ZFS DKMS or other storage-related modules won’t load
If you run ZFS-on-Linux via DKMS, Secure Boot can bite you the hardest at the worst moment: when you reboot after a kernel update and your pools won’t import because the module won’t load. Storage incidents always have the best timing.
- Check module load failure:
cr0x@server:~$ sudo modprobe zfs modprobe: ERROR: could not insert 'zfs': Key was rejected by serviceDecision: This is signing/enrollment, not “ZFS is broken.”
- Confirm module path:
cr0x@server:~$ modinfo -n zfs /lib/modules/6.8.0-41-generic/updates/dkms/zfs.ko - Confirm you have an enrolled key and DKMS is signing (Tasks 8, 14, 16).
- After fix, import pools:
cr0x@server:~$ sudo zpool import pool: tank id: 1034459023344556677 state: ONLINE action: The pool can be imported using its name or numeric identifier. config: tank ONLINE mirror-0 ONLINE sda ONLINE sdb ONLINEMeaning: The kernel module is loaded and ZFS can see disks.
Decision: Proceed to import. If pools don’t show up, you have a storage detection problem (HBA, multipath, encryption), not Secure Boot.
Scenario 4: You can’t boot graphics (black screen) after enabling Secure Boot
Sometimes the “driver blocked” symptom manifests as a black screen or a fallback framebuffer. This is common when NVIDIA modules are blocked and the system tries (and fails) to recover gracefully.
- Boot into recovery mode or a text console (try switching TTYs).
- Confirm signature errors via
dmesg(Task 5). - If you need a quick return to GUI: temporarily use open drivers or remove conflicting packages. Then do the proper Secure Boot signing workflow.
cr0x@server:~$ sudo apt-get purge 'nvidia*'
Reading package lists... Done
The following packages will be REMOVED:
nvidia-dkms-550 nvidia-driver-550 ...
Meaning: You’re removing the blocked module set so the system can use non-NVIDIA paths.
Decision: Use this only to regain access. Then reinstall NVIDIA with a signing plan, not blind hope.
Three corporate mini-stories from the field
Mini-story 1: The incident caused by a wrong assumption
The company had a tidy workstation standard: Ubuntu LTS, Secure Boot enabled, disk encryption on laptops. It was reasonable. Then a team deployed a vendor Wi‑Fi driver package for a batch of new laptops because the in-kernel driver underperformed in one office with a noisy RF environment.
The assumption was casual and deadly: “If the package installs cleanly, the driver will load.” It was true on their test machine because Secure Boot had been disabled months earlier during a hardware swap and nobody wrote it down.
In production, the new driver installed, DKMS built, and everything looked green in the deployment logs. After the scheduled reboot window, the laptops came back with no Wi‑Fi. Not flaky Wi‑Fi. None. People tethered phones to attend meetings, which is how you know you’ve created a real incident.
The root cause was visible in five seconds of dmesg: “Key was rejected by service.” The fix wasn’t complicated—enroll a MOK and sign the DKMS module—but the recovery was slow because the machines were remote and the MOK enrollment requires an interactive reboot step. They ended up staging a temporary rollback to the in-kernel driver just to regain connectivity, then doing the signing work in a second, controlled change.
Takeaway: if your deployment depends on DKMS and Secure Boot is enabled, you don’t have a “driver install” process. You have a “key management” process that happens to result in a driver.
Mini-story 2: The optimization that backfired
A platform team wanted faster kernel patch adoption. They tuned their update cadence so workstations got new kernels quickly, and they pruned old kernels aggressively to keep disks clean and boot menus short. Neat. Efficient. Everyone loves efficiency until it has teeth.
They also relied on an out-of-tree endpoint security module distributed as a DKMS package. It had been signed properly once, and everything worked for months. Then the “optimization”: after kernel updates, they pushed immediate reboots to reduce exposure time. The window between “DKMS built a module” and “machine rebooted into a new kernel” got much smaller.
A subset of machines rebooted into the new kernel before the DKMS post-install step completed signing—or before the signing key was available due to a configuration drift. The result was a scattered outage: the security agent didn’t load, and the compliance scanner flagged the endpoints as “unprotected.”
They had created a reliability bug by squeezing time. The fix wasn’t to slow all updates; it was to make signing deterministic and observable. They added a gate: if the expected signed module isn’t present for the target kernel, the reboot is postponed. Boring, yes. Effective, absolutely.
Takeaway: speed is not the same as control. If a process includes crypto and kernel policy, remove race conditions or they will remove you.
Mini-story 3: The boring but correct practice that saved the day
A storage team ran ZFS on a fleet of Ubuntu servers for build artifacts. Not fashionable, but it worked. They also had a strict rule: every server had a “break glass” playbook printed into their runbook system, including Secure Boot state checks, MOK enrollment procedures, and a small stash of known-good kernels held back from autopurge.
One day, a firmware update rolled out from the hardware vendor. After that update, a handful of servers came back with Secure Boot enabled when it had previously been disabled (or the reverse, depending on the model). The immediate symptom was simple: after reboot, ZFS wouldn’t load on two nodes. Pools were fine. Disks were fine. The kernel was enforcing signatures and the DKMS-built ZFS module wasn’t trusted.
Because they had a boring process, the response was boring too: check Secure Boot state, confirm signature rejection, enroll the correct MOK, rebuild DKMS, sign, verify load, import pools. No panicked “fsck,” no data-path experiments, no random downgrades in production.
It still took effort, because key enrollment is interactive, but they avoided the big failure mode: making desperate changes to the storage stack while the system was already degraded. They recovered service without collateral damage, which is the only kind of recovery worth celebrating.
Takeaway: the best incident response tool is the runbook you wrote when you were bored.
Common mistakes (symptom → root cause → fix)
1) “Driver installed, but device missing after reboot”
Symptom: GPU/Wi‑Fi/VirtualBox appears fine until reboot; then module won’t load.
Root cause: Secure Boot enabled + module unsigned/untrusted, so it’s rejected at load time.
Fix: Use mokutil --sb-state, read dmesg for “Key was rejected by service,” enroll MOK, sign module (or disable Secure Boot deliberately).
2) “I enrolled a MOK but it still fails”
Symptom: You did a MOK enrollment step, but modules still reject.
Root cause: You enrolled a different public cert than the private key used to sign, or you never completed the MOK Manager UI at reboot.
Fix: Run mokutil --test-key on the cert you think is enrolled. Confirm modinfo shows the correct signer. If mismatched, re-sign with the enrolled key or re-enroll the correct cert.
3) “DKMS says installed, so it must work”
Symptom: dkms status shows “installed,” but module fails to load.
Root cause: DKMS installed only means “built and copied,” not “trusted under Secure Boot.”
Fix: Confirm signature with modinfo. Configure DKMS signing (Ubuntu tooling via update-secureboot-policy, or your own signing hooks).
4) “Black screen after enabling Secure Boot”
Symptom: System boots to black screen; TTY may work.
Root cause: GPU module blocked; display manager starts without hardware acceleration or fails.
Fix: Boot to recovery/TTY, inspect dmesg, either temporarily remove problematic driver or sign it properly and ensure key enrollment.
5) “After firmware update, everything broke”
Symptom: Previously stable DKMS modules now rejected, Secure Boot state seems to have changed.
Root cause: Firmware reset toggled Secure Boot or altered key state; MOK enrollment may be required again or boot flow changed.
Fix: Confirm with mokutil --sb-state and bootctl status. Re-enroll MOK if needed; verify keyrings; re-sign modules.
6) “I disabled Secure Boot, but it still says ‘rejected’”
Symptom: You swear Secure Boot is off, but modules still fail.
Root cause: You toggled the wrong firmware entry (some UEFIs have separate settings), or you’re booting a different boot entry, or you’re confusing Secure Boot with kernel lockdown caused by other settings.
Fix: Verify state from the OS (mokutil --sb-state) and check UEFI mode. Don’t trust the firmware UI alone.
7) “I signed the module but updates break it again”
Symptom: Works until the next kernel update; then breaks.
Root cause: DKMS rebuild creates a new unsigned module each kernel install; your signing was manual and not automated.
Fix: Integrate signing with DKMS (ensure the signing key exists where DKMS expects it; verify DKMS output includes signing). Add operational checks before rebooting into a new kernel.
Short joke #2: The quickest way to learn about Secure Boot is to ignore it once, then schedule your learning session for the next reboot.
FAQ
1) Should I just disable Secure Boot?
If this is a personal machine and you accept the tradeoff, yes—it’s a valid choice. On managed systems, prefer keeping Secure Boot enabled and signing modules. Disabling Secure Boot is easy; defending it later is not.
2) What is MOK, in plain terms?
MOK (Machine Owner Key) is a way to add your own trusted signing certificate into the boot trust chain without rewriting firmware platform keys. You enroll a public certificate; then the kernel trusts modules signed by the matching private key.
3) Why does Ubuntu block modules that are “installed correctly”?
Because “installed” means files are present on disk. Secure Boot enforcement is about whether those files are trusted at load time. The kernel enforces policy; package managers don’t override that policy.
4) How do I know it’s Secure Boot and not a broken driver?
Look for “Key was rejected by service” or “module verification failed: signature and/or required key missing” in dmesg. Also check mokutil --sb-state. If Secure Boot is disabled, your failure is probably elsewhere.
5) Does signing modules “reduce security”?
It changes the trust boundary. You’re telling the kernel to trust code signed by your key. That’s fine if you protect the private key and you control what gets signed. It’s better than disabling Secure Boot entirely.
6) What about NVIDIA specifically—why is it always involved?
Because the driver is out-of-tree and often DKMS-built. That combination means new kernels trigger rebuilds, rebuilds require signing, and signing requires an enrolled key. Miss any step and it breaks at reboot.
7) Can I sign modules on one machine and deploy to others?
You can, but be careful: the target machines must trust the signing certificate (MOK enrolled everywhere), and you need a secure process to protect the signing key. In fleets, this becomes PKI and provisioning work—do it deliberately or don’t do it at all.
8) What if I lost the private key used to sign modules?
Generate a new keypair, enroll the new public cert (MOK), then re-sign modules with the new private key. Remove old keys if you’re trying to keep the trust set tight.
9) Why does MOK enrollment require an interactive reboot?
Because the enrollment is part of the boot trust process. The firmware/shim environment presents the MOK Manager UI to confirm you really intended to add a key. It’s an anti-malware design choice, not a usability feature.
10) How do I keep this from happening again on kernel updates?
Make sure DKMS signing is automatic and verifiable. Your process should include: after kernel install, verify DKMS built modules for that kernel and that they’re signed, then reboot. If you can’t verify signing, don’t reboot yet.
Conclusion: practical next steps
Ubuntu 24.04 plus Secure Boot isn’t fragile—it’s strict. Your drivers aren’t “randomly failing.” They’re being rejected because they’re not trusted under the current boot policy.
Do this next, in order:
- Run
mokutil --sb-stateand confirm you’re in UEFI mode. - Attempt to load the failing module and capture the exact error.
- Read
dmesgto confirm signature rejection. - Pick a strategy: enroll MOK + sign (preferred), or disable Secure Boot (explicitly accepted risk).
- If you sign: confirm enrollment, confirm module signer, and make DKMS signing automatic before you let kernel updates reboot your system.
If you treat Secure Boot as a policy you manage—not a checkbox you fear—you get the best outcome: secure boot chain, working drivers, and upgrades that don’t turn into surprise outages.