aboutsummaryrefslogtreecommitdiff
path: root/working/velox-reinstall/velox-uefi-boot-entry-reference.org
diff options
context:
space:
mode:
Diffstat (limited to 'working/velox-reinstall/velox-uefi-boot-entry-reference.org')
-rw-r--r--working/velox-reinstall/velox-uefi-boot-entry-reference.org75
1 files changed, 75 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
new file mode 100644
index 0000000..8d677da
--- /dev/null
+++ b/working/velox-reinstall/velox-uefi-boot-entry-reference.org
@@ -0,0 +1,75 @@
+#+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.
+
+* 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.