From fb13378559cdc6a9ef3b23883bcbda2937dc1195 Mon Sep 17 00:00:00 2001 From: Craig Jennings Date: Thu, 20 Aug 2026 11:46:19 -0500 Subject: fix(velox): trace the dead touchpad to its own connector, and repair two lost todo headings MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The touchpad fault was an interrupt line that never fired: the device enumerated, hid-multitouch bound, and the handler sat correctly on amd_gpio pin 8, but the count stayed at zero across all 24 CPUs under active use and the i2c-HID reset timed out at every boot. A live USB reproduced it exactly, which ruled out software. The fix was the touchpad's own connector — the input-cover ribbon I reseated first fixed the phantom power button and left this untouched, and the 4-pin connector beside the silkscreen is GND and VCC only, so it could never have carried i2c. Both faults from the mainboard swap are now closed. Two task headings had been overwritten by inserts at the top of Open Work, and I recovered both verbatim from the commits that introduced them. One displaced task had ridden an archived parent into Resolved, so an open bug had been sitting outside Open Work for weeks. Filed the install placeholder passwords still live on this laptop as an [#A], graded on severity alone rather than the frequency matrix: full-disk encryption protected by a dictionary word does no work at all on a machine that travels. Corrected the ARCHSETUP_DIR line in the reinstall runbook. It carried a tilde on the right-hand side of an assignment, which zsh does not expand, so following it would have produced an ISO with the installer silently absent. --- .../velox-uefi-boot-entry-reference.org | 75 ++++++++++++++++++++++ 1 file changed, 75 insertions(+) create mode 100644 working/velox-reinstall/velox-uefi-boot-entry-reference.org (limited to 'working/velox-reinstall/velox-uefi-boot-entry-reference.org') 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. -- cgit v1.2.3