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.

1 files changed, 33 insertions, 0 deletions

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)