From 3bab9f1ff287c61e85504ad5ab0c5a0d69bf0a61 Mon Sep 17 00:00:00 2001 From: Craig Jennings Date: Sun, 13 Sep 2026 07:00:06 -0500 Subject: docs: check Secure Boot before blaming a lost EFI boot entry A firmware update can re-enable Secure Boot without clearing NVRAM. The firmware then rejects the unsigned ZFSBootMenu or GRUB loader as "no bootable drive" rather than a security violation, which looks like a missing boot entry. A Framework BIOS update did this to an installed machine this week. I put a check-Secure-Boot-first bullet at the top of the troubleshooting section, with shim's MOK screen on the Ventoy stick as the tell and the firmware fix. --- README.org | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/README.org b/README.org index 0c3dabf..de178b9 100644 --- a/README.org +++ b/README.org @@ -494,6 +494,15 @@ The ISO includes DKMS-built ZFS modules. If modules fail to load: ** Boot Fails After Installation +- Check Secure Boot before assuming the boot entry is gone. A firmware update + can re-enable it silently, and the unsigned ZFSBootMenu or GRUB loader is + then rejected with "Default Boot Device Missing" / "no bootable drive" + rather than a security-violation message. If you boot the ISO through + Ventoy, the tell is shim's MOK screen. A plain USB write of the ISO will not + boot at all under Secure Boot. Fix: disable Enforce Secure Boot in firmware + setup (on a Framework laptop: F2, Security, Secure Boot) and save. No + ~efibootmgr~ changes are needed. + *** ZFS - Check ZFSBootMenu appears (if not, check EFI boot order with ~efibootmgr~) - Verify pool can import: boot ISO, ~zpool import -f zroot~ -- cgit v1.2.3