1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
|
#+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.
|
