Secure Boot Errors After Install: Fix the Key/Mode Mismatch

The mental model: modes, keys, and what is actually failing

Secure Boot is not “a setting.” It’s a chain-of-trust system enforced by UEFI firmware. The firmware decides whether the next executable is allowed to run. That “next executable” is typically shim (on many Linux distros), which then validates GRUB, which then validates the kernel (and sometimes kernel modules).

User Mode vs Setup Mode: the two states that matter

UEFI Secure Boot has two relevant operational states:

• Setup Mode: the platform key (PK) is not installed. The firmware is effectively “not owned.” You can enroll keys without authorization because there is no PK enforcing ownership. This is the state you often enter when you “clear Secure Boot keys.”
• User Mode: a PK is installed. Secure Boot databases are protected and updates to keys require authorization. This is the normal, expected state for a system that enforces Secure Boot.

Many “post-install Secure Boot” failures happen because the machine is in Setup Mode (or has empty db/dbx), while the OS expects Microsoft’s third-party CA chain to be present, or expects your custom keys to be present. The reverse also happens: the machine is in User Mode with vendor keys, but you installed a kernel or bootloader that isn’t signed by a trusted key.

The key databases: PK, KEK, db, dbx, and why dbx is the bouncer

• PK (Platform Key): establishes platform ownership. If PK is missing, you’re in Setup Mode.
• KEK (Key Exchange Key): allows updates to the allowed/forbidden lists.
• db: allowed signatures/hashes. If your bootloader’s signature chains to a cert in db, it can run.
• dbx: forbidden signatures/hashes (revocation list). If dbx says “no,” it’s no—even if db would otherwise allow it.

Distros that support Secure Boot usually ship a signed shim. That shim is signed by a key that chains up to a Microsoft third-party UEFI CA that many vendors include in db by default. Shim then uses its own embedded cert and/or the Machine Owner Key (MOK) list to validate GRUB and kernels.

So what is “key/mode mismatch” in practice?

You get a mismatch when one side assumes a trust root that isn’t true:

• The firmware is enforcing Secure Boot in User Mode, but the installed bootloader/kernel isn’t signed by a trusted chain.
• The firmware is in Setup Mode (PK cleared), but your OS expects vendor/Microsoft keys to exist, so the signatures don’t validate as expected (or you’re not really enforcing anything, but the boot chain you installed still expects a particular environment).
• You have custom keys but you forgot to enroll them (or you enrolled them to MOK, but you needed them in db; or vice versa).
• dbx was updated and now blocks an older shim/grub (SBAT-related errors often live here).

One quote worth keeping in your head when you’re tempted to “just disable it”: (paraphrased idea) “Hope is not a strategy.” — Gene Kranz. Secure Boot isn’t perfect, but disabling it because it’s annoying is the reliability equivalent of cutting your seatbelt because it wrinkles your shirt.

Joke #1: Secure Boot is like a nightclub bouncer with a clipboard. If your name isn’t on the list, you’re not getting in—even if you “know the owner.”

Interesting facts and historical context (because the mess has history)

1. UEFI Secure Boot shipped into the mainstream with Windows 8-era hardware. It wasn’t invented to annoy Linux users; it was a response to bootkits and persistent malware living below the OS.
2. Microsoft’s third-party UEFI CA became the de facto “bridge” for Linux. Many vendors ship it in db, which lets distros boot a Microsoft-signed shim without forcing every user to manage their own keys.
3. Shim exists because firmware vendors didn’t want to ship every distro’s key. A single signed shim plus a distro-managed trust chain is scalable; stuffing db with everybody’s certs is not.
4. dbx updates are effectively global “revocations.” When a vulnerability is found in a widely used boot component, dbx can block it across systems—useful and brutal.
5. SBAT was introduced to make revocation more granular. Instead of revoking an entire signing cert (collateral damage), SBAT metadata can block specific vulnerable builds.
6. “Clearing Secure Boot keys” is not the same as “turning Secure Boot off.” Clearing keys often puts you into Setup Mode and can create weirder behavior than simply disabling enforcement.
7. MOK (Machine Owner Key) is a shim-level mechanism, not firmware-level. MOK is great for signing kernels/modules, but it does not magically populate firmware db.
8. Some vendors ship with Secure Boot enabled but allow third-party keys; some don’t. That one BIOS toggle labeled “Allow Microsoft 3rd party UEFI CA” decides whether common Linux shims will boot.
9. Kernel module signing is adjacent but not identical. You can successfully boot and still have drivers fail to load because module signature enforcement is separate from UEFI Secure Boot validation.

Fast diagnosis playbook (check these in order)

You want signal fast. Don’t start by reinstalling anything. Don’t start by disabling Secure Boot. Check state, identify which link in the chain broke, then choose the smallest fix.

1) Check firmware mode and Secure Boot state

• Is the system booted in UEFI mode (not legacy/CSM)?
• Is Secure Boot enabled and active?
• Is the firmware in Setup Mode (PK missing) or User Mode?

2) Identify the failing component

• Is the error from firmware before shim runs (“Security violation”, “Invalid signature”)?
• Is shim starting but rejecting GRUB/kernel (“Verification failed: (15)”, “SBAT policy violation”)?
• Does it boot but later rejects drivers (NVIDIA, ZFS, Wi-Fi)? That’s module signing territory.

3) Confirm what keys are actually enrolled

• Firmware db/dbx contents (at least existence/health).
• MOK list contents if using shim/MOK.
• Whether “Microsoft 3rd party UEFI CA” is enabled in firmware.

4) Decide your trust model

• Corporate fleet: usually keep vendor keys + Microsoft keys, use distro shim, use MOK for your own kernel/modules.
• High control: use custom keys (your own PK/KEK/db), sign everything you boot. More work. More certainty.
• Lab box: if it’s not connected to anything sensitive, disabling Secure Boot is acceptable, but document it and stop pretending it’s “secure.”

Failure signatures: what the error really means

Firmware: “Security violation” / “Invalid signature” before any bootloader menu

Firmware rejected the EFI binary. Typical causes:

• Bootloader isn’t signed by a key in db.
• Bootloader hash/signature is in dbx (revoked).
• You installed GRUB directly (unsigned) instead of shim-signed path, or you overwrote the signed binary.
• Firmware is configured to disallow third-party CAs.

Shim: “Verification failed: (15)” after selecting an entry

Shim is running, so firmware accepted shim. Now shim is rejecting GRUB or the kernel because it can’t validate the next stage with its embedded cert or MOK list.

SBAT policy violation

This is often revocation logic doing its job. Your shim/grub build is old enough (or tagged vulnerable) that current dbx/SBAT policy blocks it. The fix is usually to boot a newer shim/grub, not to fight the revocation list.

System boots, but drivers fail: “Required key not available”

The kernel is enforcing module signatures (often because Secure Boot is enabled and kernel lockdown kicks in). Your third-party module (NVIDIA, DKMS, ZFS, VirtualBox) isn’t signed with a key the kernel trusts. That’s not a UEFI db problem; it’s a kernel keyring/MOK problem.

Hands-on tasks: commands, outputs, and decisions (12+)

These are the checks I run on real systems. Each task includes: command, what output means, and what decision you make from it. Commands assume a Linux environment; if you can’t boot normally, use a live USB in UEFI mode and chroot where noted.

Task 1: Confirm the system booted in UEFI mode

cr0x@server:~$ test -d /sys/firmware/efi && echo "UEFI boot" || echo "Legacy boot"
UEFI boot

Meaning: If you get “Legacy boot,” Secure Boot state is irrelevant because you’re not in UEFI boot.

Decision: If legacy, fix firmware boot mode first (disable CSM/Legacy). Don’t touch keys yet.

Task 2: Check whether Secure Boot is enabled (runtime view)

cr0x@server:~$ mokutil --sb-state
SecureBoot enabled

Meaning: “enabled” means the kernel believes Secure Boot is active. “disabled” can mean it’s off in firmware or you booted via a path that bypasses it.

Decision: If disabled but you expected enabled, look for firmware setting changes or legacy boot.

Task 3: Check if firmware is in Setup Mode (PK missing)

cr0x@server:~$ mokutil --pk
PK is not enrolled

Meaning: No PK typically means Setup Mode.

Decision: If PK not enrolled and you want enforcement, you must restore/enroll keys (vendor defaults or custom PK/KEK/db).

Task 4: Check if Microsoft and vendor keys are present (quick health check)

cr0x@server:~$ sudo efi-readvar -v db | head
Variable db, length 2346
PKCS7 signature:
Signer: Microsoft Corporation UEFI CA 2011

Meaning: Seeing Microsoft UEFI CA signers suggests the common trust anchor is present in db.

Decision: If db is empty or unreadable, restore default keys (if your policy allows) or enroll your own.

Task 5: Inspect dbx for obvious revocations causing your failure

cr0x@server:~$ sudo efi-readvar -v dbx | head
Variable dbx, length 17892
Signature list 1
Signature type: X509

Meaning: dbx is populated. That’s normal. A “too new dbx + too old shim” combination can break boots after updates.

Decision: If the error is SBAT-related, prioritize updating shim/grub rather than trying to roll back dbx.

Task 6: Verify what EFI binaries exist and which one you’re booting

cr0x@server:~$ sudo ls -R /boot/efi/EFI | sed -n '1,80p'
/boot/efi/EFI:
Boot  ubuntu

/boot/efi/EFI/Boot:
BOOTX64.EFI

/boot/efi/EFI/ubuntu:
grubx64.efi  mmx64.efi  shimx64.efi

Meaning: Presence of shimx64.efi indicates a Secure Boot-friendly path. If you only have grubx64.efi and it’s unsigned, firmware may reject it.

Decision: If shim is missing, reinstall the distro’s shim-signed package and re-register the boot entry.

Task 7: Check UEFI boot entries and what file they point to

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0002
Boot0003* ubuntu	HD(1,GPT,4d7b...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot0001* UEFI OS	HD(1,GPT,4d7b...,0x800,0x100000)/File(\EFI\Boot\BOOTX64.EFI)

Meaning: If your entry points to grubx64.efi directly, and Secure Boot is on, you’re gambling on that binary being accepted.

Decision: Point the entry to shim where appropriate, or fix the signature/trust chain for GRUB.

Task 8: Confirm shim/grub are actually signed (file-level check)

cr0x@server:~$ sbverify --list /boot/efi/EFI/ubuntu/shimx64.efi
signature 1
image signature issuers:
 - /CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
 - /CN=Canonical Ltd. Secure Boot Signing

Meaning: If sbverify can list signatures and they chain to something plausible, the binary isn’t obviously unsigned.

Decision: If it’s unsigned, reinstall from trusted packages. Don’t hand-copy EFI binaries from random places.

Task 9: Check MOK enrollment status (common after installing DKMS modules)

cr0x@server:~$ mokutil --list-enrolled | head
[key 1]
SHA1 Fingerprint: 9a:7c:...
Subject: CN=Local DKMS Signing

Meaning: A locally enrolled key exists. Good if you need to load signed DKMS modules.

Decision: If your kernel/modules are failing with “Required key not available,” you likely need to enroll a key (or sign modules with the existing one).

Task 10: See kernel lockdown and Secure Boot effects

cr0x@server:~$ dmesg | grep -i -E 'secureboot|lockdown' | head -n 20
[    0.000000] Secure boot enabled
[    0.532101] Kernel is locked down from EFI Secure Boot mode; see man kernel_lockdown.7

Meaning: Kernel lockdown is active; certain operations (like raw MSR access, kexec in some modes) may be restricted.

Decision: If a tool suddenly fails after enabling Secure Boot, confirm it’s a lockdown consequence, not a “random regression.”

Task 11: Diagnose module signature failures (NVIDIA/DKMS symptoms)

cr0x@server:~$ sudo journalctl -k -b | grep -i -E 'module verification|Required key not available' | head
kernel: Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7
kernel: nvidia: module verification failed: signature and/or required key missing

Meaning: The system booted fine; now the kernel is refusing a module.

Decision: Sign the module with a key the kernel trusts (often via MOK), or use distro-signed modules where possible.

Task 12: Check installed shim/grub package versions (are you running antique boot components?)

cr0x@server:~$ dpkg -l | egrep 'shim-signed|grub-efi-amd64-signed' || true
ii  grub-efi-amd64-signed  1.187.3+2.12-1ubuntu7  amd64  GRUB EFI signed kernel loader
ii  shim-signed            1.58+15.7-0ubuntu1     amd64  Secure Boot chain-loading bootloader (Microsoft-signed)

Meaning: You can correlate these versions with whether the system is likely SBAT-compatible and patched.

Decision: If you’re behind and seeing SBAT policy failures, update these packages from your normal repository path.

Task 13: Validate the kernel image signature (when your distro signs kernels)

cr0x@server:~$ sbverify --list /boot/vmlinuz-$(uname -r) | head
signature 1
image signature issuers:
 - /CN=Canonical Ltd. Secure Boot Signing

Meaning: If the kernel is signed and shim expects signed kernels, this should look sane.

Decision: If unsigned, you’re likely running a custom kernel that needs signing and MOK enrollment, or you installed a kernel outside the distro’s signed set.

Task 14: Repair the EFI boot entry to point at shim (common simple fix)

cr0x@server:~$ sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -L "ubuntu-shim" -l '\EFI\ubuntu\shimx64.efi'
BootCurrent: 0003
BootOrder: 0007,0003,0001,0002
Boot0007* ubuntu-shim	HD(1,GPT,4d7b...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)

Meaning: You created a new entry that boots shim directly.

Decision: If Secure Boot works after this, the earlier boot entry was pointing at the wrong binary.

Task 15: Identify whether you’re in a “firmware won’t allow third-party” configuration

cr0x@server:~$ sudo efi-readvar -v db | grep -i -E 'Microsoft Corporation UEFI CA 2011|Windows UEFI' | head
Signer: Microsoft Windows UEFI Driver Publisher
Signer: Microsoft Corporation UEFI CA 2011

Meaning: Presence suggests the firmware db includes Microsoft keys. Still, some firmware has a separate toggle that disables third-party CA usage.

Decision: If db contains the CA but shim still won’t boot, inspect firmware UI for “third-party” setting, or the vendor “Standard/Custom” key mode.

Task 16 (live USB + chroot): Reinstall signed boot components cleanly

cr0x@server:~$ sudo mount /dev/nvme0n1p2 /mnt
cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/boot/efi
cr0x@server:~$ for i in /dev /dev/pts /proc /sys /run; do sudo mount --bind $i /mnt$i; done
cr0x@server:~$ sudo chroot /mnt bash -lc 'apt-get update && apt-get install --reinstall shim-signed grub-efi-amd64-signed && update-grub'
Reading package lists... Done
Setting up shim-signed ...
Setting up grub-efi-amd64-signed ...
Generating grub configuration file ...

Meaning: You force a clean re-deploy of signed EFI binaries and rebuild GRUB config.

Decision: If the system previously booted unsigned GRUB or a stale shim, this usually fixes it—assuming keys/modes are correct.

Fixing the key/mode mismatch: practical paths

There are three sane strategies. Pick one. Mixing them is how you end up in “works until next update” purgatory.

Path A: Vendor defaults + distro shim (recommended for most people)

When to choose: laptops, servers running mainstream distros, corporate endpoints, anything where you want a standard supportable posture.

Goal: Firmware stays in User Mode with vendor/Microsoft keys. You boot via distro-provided, signed shim and signed GRUB/kernel. If you need DKMS modules, you sign them and enroll a MOK.

What you do:

• In firmware: load default keys (often called “Install factory default keys” or “Restore factory keys”).
• Ensure “Microsoft 3rd party UEFI CA” is enabled if your distro uses it.
• In OS: reinstall shim-signed and grub-efi-*-signed, ensure boot entry points at shim.
• If you have unsigned modules: generate a local signing key, enroll via MOK manager, sign modules.

Path B: Full custom keys (PK/KEK/db) for high-control environments

When to choose: regulated systems, appliances, environments where you don’t want Microsoft keys in your trust store, or you ship a product and want deterministic boot trust.

Goal: You control PK/KEK/db. You sign shim/grub/kernel yourself (or use a shim signed by your keys and enroll them). You maintain your own revocation logic.

Hard truth: this is operational work. Key rotation, recovery procedures, firmware UI quirks, and bricking avoidance are now your problem. If you can’t commit to that, do Path A.

Path C: Disable Secure Boot (only when you mean it)

When to choose: short-term emergency to restore service, lab systems, or as an explicit policy decision with compensating controls.

Goal: Boot reliably now, then come back and implement A or B properly.

Joke #2: Disabling Secure Boot to fix Secure Boot is like fixing a smoke alarm by removing the battery. The noise stops; the fire doesn’t care.

Common “mode mismatch” situations and the clean fix

Situation: PK cleared (Setup Mode), Secure Boot “enabled,” and nothing boots consistently

Why it happens: someone cleared keys to “reset things,” then left Secure Boot toggled on. You’re now in a state that varies by vendor firmware and often breaks expected chains.

Fix: restore factory default keys (Path A) or enroll custom PK/KEK/db (Path B). Don’t leave it half-owned.

Situation: Firmware doesn’t allow third-party CA

Why it happens: some systems have a setting that only trusts Windows production keys by default. Your Linux shim relies on the Microsoft third-party UEFI CA.

Fix: enable third-party CA in firmware, or enroll your distro’s shim cert into db (less common, more tedious), or go full custom keys.

Situation: You installed a custom kernel or self-built GRUB

Why it happens: you replaced signed components with unsigned ones, then Secure Boot did its job.

Fix: sign the binaries and enroll trust properly. Or revert to distro-signed packages.

Situation: SBAT policy violation after updates

Why it happens: dbx/SBAT revoked old vulnerable shim/grub builds. Now your installed EFI binaries are blocked.

Fix: update shim/grub to a non-revoked version using a rescue environment, then boot normally. Avoid rolling back dbx unless you’re deliberately accepting known risk.

Three corporate mini-stories from the land of “it worked on my laptop”

Incident #1: the outage caused by a wrong assumption

The company was rolling out a new Linux image for developer workstations. The image team tested it on three models of laptops and called it good. On Monday, the helpdesk queue turned into a denial-of-service attack—with receipts. Half the fleet booted into a firmware error about invalid signatures.

The wrong assumption was subtle: “All vendors ship the Microsoft third-party UEFI CA in db.” Many do. Some don’t. And some ship it but gate it behind a BIOS toggle that defaults to “off” in certain regions or security profiles.

What made it worse: the image had been built with the expectation that shim would be accepted, but the boot entry pointed directly to grubx64.efi on a subset of machines due to a packaging quirk during imaging. On machines that did have permissive db contents, it still booted. On stricter firmware, it was dead on arrival.

The fix wasn’t heroic. They standardized firmware settings via their management tooling, explicitly enabled third-party CA where allowed, and updated the imaging process to always register the boot entry to shim. The real win was the postmortem: they added a preflight check step in staging that validated Secure Boot on every hardware SKU, not just “whatever was near the lab bench.”

Incident #2: the optimization that backfired

A platform team wanted faster kernel iteration for a latency-sensitive service. Someone proposed building a custom kernel with a small patch set and rolling it out to a fleet of edge servers. They also wanted to keep Secure Boot enabled—good instinct.

The “optimization” was skipping the signing pipeline. The theory: “We’re already inside the data center; physical security is strong; we’ll sign later.” They pushed the kernel via automation, rebooted a canary, and watched it fail to boot with signature errors. That was expected. The unexpected part was what came next: their automation interpreted the canary failure as “node is unhealthy, reboot it again,” and created a small reboot storm on a subset of machines before someone stopped the job.

They recovered by booting the previous signed kernel via the bootloader’s fallback entry—on the machines where GRUB still offered it. On machines where the bootloader config had been “simplified” to a single entry (to reduce boot time by a second), there was no fallback. Those required hands-on rescue.

Lesson: Secure Boot doesn’t break your deployment. Your deployment breaks your deployment. If you’re going to ship custom kernels, signing cannot be an afterthought. It is the release artifact.

Incident #3: the boring but correct practice that saved the day

A storage team ran a small but critical cluster that handled backups and long-term archives. The servers were not glamorous, which is exactly why they were valuable: they changed rarely and worked always.

They had a policy: whenever firmware updates were applied, they recorded Secure Boot state (enabled/disabled), PK enrollment status, and the current EFI boot entry paths. The record lived in their change ticket. It was boring, repetitive, and nobody got promoted for it.

One quarter, a firmware update silently reset Secure Boot key settings on two nodes. The nodes still booted, but later a kernel module used for HBA monitoring stopped loading with “Required key not available.” The on-call engineer did not spiral. They compared the change record, saw that MOK enrollment had been wiped, re-enrolled the key during the maintenance window, and re-signed the modules. No data loss, no extended outage, no drama.

The best part: the team didn’t “fix” it by disabling Secure Boot. They fixed the mismatch and moved on. Reliability is mostly unsexy repetition, plus good notes.

Common mistakes: symptom → root cause → fix

1) “Verification failed: (15)” after install

• Symptom: shim runs, but selecting Linux entry fails.
• Root cause: GRUB or kernel not signed by a key shim trusts; MOK not enrolled; or you replaced signed GRUB with unsigned.
• Fix: reinstall signed grub package; ensure boot entry points to shim; enroll MOK and sign kernel if you run custom builds.

2) Firmware “Invalid signature” before any menu appears

• Symptom: immediate rejection loading EFI binary.
• Root cause: firmware db doesn’t trust the binary’s signer, or third-party CA disabled, or binary is revoked by dbx.
• Fix: restore factory keys and enable third-party CA; or enroll your own keys and sign the EFI binary; or update shim/grub if revoked.

3) SBAT policy violation after a “normal” update

• Symptom: system booted yesterday; today shim refuses with SBAT message.
• Root cause: your shim/grub is older than the revocation policy now enforced via dbx/SBAT.
• Fix: boot rescue media, chroot, update/reinstall shim/grub, verify EFI entry points to updated shim.

4) Boots fine, but NVIDIA/ZFS/VirtualBox fails: “Required key not available”

• Symptom: missing driver, DKMS build succeeded but module won’t load.
• Root cause: module not signed with a key in the kernel’s trusted keyrings; MOK not enrolled or wiped.
• Fix: enroll a MOK and sign modules; re-trigger DKMS signing; verify mokutil --list-enrolled.

5) Someone “cleared keys” to troubleshoot and now everything is weird

• Symptom: Setup Mode, inconsistent behavior across reboots, Secure Boot toggles don’t behave as expected.
• Root cause: PK removed; platform not in stable User Mode trust state.
• Fix: restore factory default keys (Path A) or implement full custom key set (Path B). Stop clearing keys as a debugging step.

6) Dual-boot suddenly broken after reinstalling Windows or Linux

• Symptom: one OS boots; the other fails with signature errors or missing entries.
• Root cause: boot entries overwritten; EFI binaries replaced; vendor keys unchanged but boot path now points at unsigned GRUB.
• Fix: rebuild boot entries with efibootmgr; reinstall shim/grub for Linux; confirm each OS points at its correct signed loader.

7) “SecureBoot disabled” in OS but firmware says enabled

• Symptom: discrepancy between firmware UI and mokutil --sb-state.
• Root cause: booted in legacy mode, or via a path not enforcing Secure Boot, or firmware implementation quirks.
• Fix: verify UEFI boot via /sys/firmware/efi; check boot entries; disable CSM.

Checklists / step-by-step plan

Checklist 1: Minimal checks before touching firmware settings

1. Confirm UEFI boot: test -d /sys/firmware/efi.
2. Check Secure Boot runtime state: mokutil --sb-state.
3. Check PK enrollment: mokutil --pk.
4. Inspect boot entries: efibootmgr -v.
5. List EFI binaries: ls -R /boot/efi/EFI.

If you can’t boot: do these from a live USB booted in UEFI mode, after mounting the EFI System Partition.

Checklist 2: Repair path for “wrong boot entry” (fast win)

1. Mount ESP and confirm shim exists: /boot/efi/EFI/<distro>/shimx64.efi.
2. Create a new UEFI entry pointing to shim using efibootmgr -c ... -l '\EFI\...\shimx64.efi'.
3. Move it to the top of BootOrder (or set it explicitly).
4. Reboot and confirm you pass firmware validation.

Checklist 3: Repair path for “old shim/grub revoked” (SBAT/dbx mismatch)

1. Boot a current rescue/live environment in UEFI mode.
2. Mount root filesystem and ESP; bind-mount /dev, /proc, /sys, /run.
3. Chroot and reinstall shim/grub signed packages.
4. Run update-grub (or distro equivalent).
5. Verify boot entry points to updated shim.

Checklist 4: Repair path for “module signing required” (boots but drivers fail)

1. Confirm module failure in logs: journalctl -k -b.
2. Check MOK list: mokutil --list-enrolled.
3. If no suitable key exists: create one (via your distro tooling), enroll it, reboot through MOK manager.
4. Sign modules (or rebuild DKMS so it signs automatically).
5. Confirm module loads: modprobe <module> and re-check logs.

Checklist 5: Fleet-safe policy (what to standardize)

1. Document whether you rely on Microsoft third-party UEFI CA or custom keys.
2. Standardize firmware toggles (Secure Boot enabled, third-party CA allowed if needed, CSM disabled).
3. Pin or stage shim/grub updates; don’t let ancient EFI binaries linger.
4. Have a rescue workflow that can update shim/grub from offline media.
5. Track MOK enrollment procedures for DKMS-heavy systems.

FAQ

1) Why did Secure Boot fail right after install? I didn’t change anything.

Because the installer did. It may have created a boot entry pointing at the wrong EFI binary, installed an unsigned GRUB, or assumed firmware keys that your system doesn’t have (or has disabled).

2) What’s the difference between clearing keys and disabling Secure Boot?

Disabling Secure Boot turns off enforcement. Clearing keys removes PK/KEK/db state and often puts you into Setup Mode. Clearing keys can create a broken half-state; disabling is at least deterministic.

3) If shim is Microsoft-signed, does that mean Microsoft controls my Linux boot?

No. Microsoft’s signature lets firmware run shim. After that, shim enforces the next steps using distro certificates and/or MOK. Your trust model depends on what keys you accept in firmware db and what shim trusts.

4) I see “Secure boot enabled” and “Kernel is locked down.” Is that bad?

It’s a trade. Lockdown reduces attack surface (good) and blocks some low-level tooling (sometimes annoying). If your workflow needs those tools, decide deliberately whether you want Secure Boot and lockdown on that machine.

5) Can I just sign GRUB myself and keep everything else the same?

Yes, but you need to make sure the signer is trusted by the component validating it. Firmware validates the first stage it runs; shim validates the next stage based on embedded certs and MOK. Signing without enrolling trust is just producing expensive bits.

6) Why does a driver fail to load even though the system boots?

Because boot-time Secure Boot validation and runtime kernel module signature enforcement are separate layers. Your kernel can be signed and accepted, but your DKMS-built module can still be unsigned and rejected.

7) What is SBAT and why is it suddenly ruining my day?

SBAT is a mechanism to revoke vulnerable boot components more precisely. If your shim/grub is too old, SBAT policy may block it. The fix is typically updating shim/grub, not fighting the revocation list.

8) I dual-boot. Should I use custom keys?

Usually not, unless you enjoy maintaining a key management program in your spare time. Vendor defaults + distro shim is the most supportable approach for dual-boot systems.

9) What should I do if I can’t boot at all and I need the machine back now?

Boot a live USB in UEFI mode, mount the system, and reinstall signed shim/grub as shown above. If policy allows, temporarily disable Secure Boot to regain access, then fix keys and re-enable.

10) How do I know whether the problem is db/dbx or MOK?

If firmware rejects before shim, it’s db/dbx/trust at the firmware level. If shim runs but rejects GRUB/kernel, it’s shim trust/MOK/distro certs. If the OS boots but modules fail, it’s kernel keyrings/MOK module signing.

Next steps you should actually do

Secure Boot failures after install are rarely “random.” They’re usually a broken expectation: the firmware is enforcing one trust model, your installed boot chain was built for another, and keys/modes don’t match.

1. Run the fast diagnosis checks: UEFI boot, Secure Boot state, PK presence, boot entry target.
2. Pick a strategy: vendor defaults + distro shim (most cases) or full custom keys (only if you can operate it).
3. Repair the boot chain with the smallest change: point entries to shim, reinstall signed shim/grub, update if SBAT/dbx is blocking old builds.
4. If you need DKMS modules, treat MOK enrollment and module signing as part of the build pipeline—not a late-night ritual.
5. Write down what you changed in firmware. Future you is a different person, and they don’t deserve surprises.

If you do this right, Secure Boot stops being a roulette wheel. It becomes what it was supposed to be: a predictable gate that only opens for software you explicitly trust.