Secure Boot doesn't have to mean distro lock-in — enroll your own keys, auto-sign your kernel, and keep custom builds booting on Arch in about ten minutes.

Every Arch user hits this wall eventually: you build a custom kernel — patched for your hardware, stripped for speed, whatever the reason — reboot, and the firmware refuses to boot it. No error from the bootloader, no kernel panic, just a flat denial. That's Secure Boot doing its job: your firmware only trusts binaries signed with keys it knows, and your hand-rolled vmlinuz isn't one of them.

Most people's fix is to turn Secure Boot off. That works, but it throws away the one thing Secure Boot is actually good at: making sure nothing below the OS — bootkits, tampered bootloaders, a "helpful" live USB someone left in the machine — gets to run before your kernel. The better fix is to become your own signing authority. On Arch, that takes about ten minutes with sbctl.

How the Trust Chain Works (the 30-Second Version)

Secure Boot is a chain of signatures. Your firmware holds a set of trusted keys (usually Microsoft's plus your vendor's). It verifies the bootloader's signature, the bootloader verifies the kernel's, and so on. Distro kernels boot because Microsoft signed the shim loader, which trusts the distro's key, which signed the distro kernel.

Your custom kernel breaks the chain at the last link: nobody signed it with a key the firmware trusts. sbctl fixes this by generating your keys, enrolling them into the firmware, and signing your kernel with them. You're not bypassing Secure Boot — you're joining it.

The Drill

0. Check where you stand. sbctl status tells you whether Secure Boot is enabled and whether you're in setup mode. bootctl status shows your boot setup. If Secure Boot is already on and working with a distro kernel, you're mid-chain and just need to extend it.

1. Enter setup mode. Reboot into firmware settings and clear the Secure Boot keys (often labeled "Clear Secure Boot Keys" or "Reset to Setup Mode"). In setup mode, the firmware will enroll whatever keys you present — this is the one moment the door is open, so don't skip what's next.

2. Create and enroll your keys. Back in Arch:

sudo sbctl create-keys
sudo sbctl enroll-keys -m

The -m keeps Microsoft's keys enrolled alongside yours — do this if you dual-boot Windows, or Windows will stop booting. Without it, your keys become the only trusted ones, which is fine for a Linux-only box.

3. Sign your kernel and bootloader.

sudo sbctl sign -s /boot/vmlinuz-linux
sudo sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI
sudo sbctl verify

sbctl verify lists every EFI binary it knows about and whether each is signed. Everything that executes before the kernel must show as signed.

4. Make it automatic. Kernel updates replace vmlinuz, which invalidates the signature. sbctl ships a pacman hook that re-signs on every kernel install — verify it exists at /usr/share/libalpm/hooks/zz-sbctl.hook (installed with the package). From here, updates just work.

5. Reboot and confirm. Re-enter firmware settings, turn Secure Boot back on (it was off in setup mode), boot, and run sbctl status — you want "Secure Boot: enabled" with your keys enrolled.

The Gotchas Worth Knowing

  • Every new kernel binary needs a signature. The pacman hook covers repo kernels. If you compile kernels manually with makepkg, either sign them in your build script or run sbctl sign after installing.
  • UKI users, you're already halfway there. If you boot a Unified Kernel Image (via mkinitcpio UKI presets or systemd's ukify), you sign one file — the UKI — instead of kernel plus initramfs separately. Fewer moving parts, fewer surprises.
  • Don't lose your keys. They're in /usr/share/secureboot/ by default. Back them up somewhere safe. If you lose them and need to sign a new kernel, you'll repeat the setup-mode dance.
  • This doesn't protect a running system. Secure Boot verifies the boot chain, not runtime integrity. It pairs with — not replaces — full-disk encryption and sane user permissions.

The Takeaway

Secure Boot's reputation as a distro lock-in tool is half-earned: the default key setup does favor whoever the vendor trusts. But the machinery is neutral — enroll your own keys and the same chain of trust protects your builds. Ten minutes with sbctl turns "custom kernel vs Secure Boot" from a fight into a non-issue, and you get to keep the one boot-time guarantee that actually matters.

Sources: ArchWiki — Secure Boot — https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot ; sbctl — https://github.com/Foxboron/sbctl ; systemd-boot documentation — https://www.freedesktop.org/software/systemd/man/latest/systemd-boot.html