#+TITLE: Velox UEFI Boot Entry — Recovery Reference
#+AUTHOR: Craig Jennings
#+DATE: 2026-08-15

Captured 2026-08-15 before a BIOS update (03.05 → 04.02) as insurance against
the update clearing NVRAM. Velox's mainboard swap on 2026-08-13 left exactly
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: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)
- BootCurrent: 0001
- BootOrder: 2001,0001,2002,2003  (USB ahead of ZBM — why the Ventoy stick
  boots when it's inserted)
- Timeout: 0 seconds

* The entry that matters

=Boot0001* ZFSBootMenu=

| field          | value                                        |
|----------------+----------------------------------------------|
| ESP part GUID  | 8e51b680-f90a-444f-8da5-7e4f93625775          |
|----------------+----------------------------------------------|
| partition      | 1 (GPT), start 0x800, size 0x100000           |
|----------------+----------------------------------------------|
| loader path    | =\EFI\ZBM\zfsbootmenu.efi=                    |
|----------------+----------------------------------------------|
| cmdline (data) | =spl_hostid=0x22f8a7a1 zbm.timeout=3=         |
|                | =zbm.prefer=zroot zbm.import_policy=hostid=   |
|----------------+----------------------------------------------|

The =data= field is that command line in UTF-16LE, which is how efibootmgr
passes it as optional data. Recreate with =-u= and the plain string; efibootmgr
does the encoding.

* Recreating it

From a booted system (or the archangel ISO), with the ESP identified as
=/dev/nvme0n1p1= or whatever it enumerates as:

#+begin_src bash
efibootmgr --create \
  --disk /dev/nvme0n1 --part 1 \
  --label "ZFSBootMenu" \
  --loader '\EFI\ZBM\zfsbootmenu.efi' \
  --unicode 'spl_hostid=0x22f8a7a1 zbm.timeout=3 zbm.prefer=zroot zbm.import_policy=hostid'
#+end_src

Confirm the disk/part against =lsblk -o NAME,PARTUUID,PARTTYPENAME= first —
the partition GUID above is the authoritative identifier, not the device name,
which can enumerate differently.

Then set the order so ZBM is reachable:

#+begin_src bash
efibootmgr --bootorder 0001,2001,2002,2003
#+end_src

(The original order put USB first. Keep whichever you prefer; what matters is
that the ZBM entry exists and is in the list.)

* Other entries (firmware-generated, recreate themselves)

| Boot2001 | EFI USB Device |
|----------+----------------|
| Boot2002 | EFI DVD/CDROM  |
|----------+----------------|
| Boot2003 | EFI Network    |
|----------+----------------|

These are stock firmware entries and come back on their own. Only Boot0001
carries anything unique.