From c667485437e9e34a2517c963152a1a86dbc19972 Mon Sep 17 00:00:00 2001 From: Craig Jennings Date: Sun, 13 Sep 2026 07:02:39 -0500 Subject: docs(health-check): record the velox 2026-09-12 findings These come from velox's 2026-09-12 health check. The Framework 04.02 BIOS update re-enabled Secure Boot, which rejects the unsigned ZFSBootMenu loader and reads as "no bootable device" while the boot entries are intact. I added a pre-firmware-update checklist to Phase 3 and a check-Secure-Boot-first section to the velox boot-entry reference. Four Known Issues entries cover the Secure Boot flip, fwupdmgr activating passim, the topgrade containers step failing on local images and the harmless mkinitcpio firmware warnings. Phase 3 also notes why lsinitcpio needs sudo: the images are 0600, so an unprivileged run errors on stderr with an empty stdout, and a piped count reads 0. --- .../velox-uefi-boot-entry-reference.org | 33 ++++++++++++++++++++++ 1 file changed, 33 insertions(+) (limited to 'working/velox-reinstall') diff --git a/working/velox-reinstall/velox-uefi-boot-entry-reference.org b/working/velox-reinstall/velox-uefi-boot-entry-reference.org index 8d677da..53e6511 100644 --- a/working/velox-reinstall/velox-uefi-boot-entry-reference.org +++ b/working/velox-reinstall/velox-uefi-boot-entry-reference.org @@ -8,6 +8,39 @@ this kind of empty NVRAM, which is what forced the reinstall — so a cleared boot entry is the specific failure worth being able to undo in one command rather than reconstruct. +* Before recreating anything: check Secure Boot first + +The 04.02 update landed on 2026-09-12 (staged via fwupd, flashed on the next +reboot). It did NOT clear NVRAM: Boot0001 survived with its command line +intact. What it did was re-enable Secure Boot (Enforce Secure Boot = +Enabled), so the unsigned ZBM loader was rejected and the Framework BIOS +reported it as "Default Boot Device Missing / no bootable drive" rather than +a security violation. The symptom is indistinguishable from the NVRAM wipe +this document was written for. + +The tell: booting the Ventoy stick shows shim's MOK management screen. + +Fix: F2 → Security → Secure Boot → Enforce Secure Boot = Disabled, F10. The +machine then boots straight into ZBM. No efibootmgr needed. + +So when velox says no bootable device after a firmware update, check Secure +Boot before touching the boot entries. Only if Secure Boot is already off +and =efibootmgr -v= (from the stick) shows Boot0001 gone does the recreate +below apply. + +Before any future firmware update, record both =efibootmgr -v= and the +Secure Boot state so the post-reboot diagnosis is a comparison, not a guess. +The pre-firmware-update checklist in +[[file:../../docs/workflows/system-health-check.org][docs/workflows/system-health-check.org]] +(Phase 3) carries the steps. + +Still open: velox's ESP has no removable-media fallback (=/efi/EFI/BOOT= +does not exist), so a real NVRAM wipe would still need the stick. Copying +=zfsbootmenu.efi= to =/efi/EFI/BOOT/BOOTX64.EFI= would let it boot unaided. +That belongs to archangel's ZBM install, where it is filed as [#C] +"Installed systems have no removable-media boot fallback on the ESP" +(2026-09-12) and ships with the next ISO rebuild after it lands. + * State at capture - BIOS: 03.05 (2025-10-30) -- cgit v1.2.3