From 08b63f4ae4ac587bdef3a9ff996afe85a68c36ce Mon Sep 17 00:00:00 2001
From: Craig Jennings <c@cjennings.net>
Date: Sat, 27 Jun 2026 17:20:58 -0400
Subject: fix(test): give each filesystem profile its own OVMF NVRAM file

init_vm_paths suffixed the disk image per profile but shared one
OVMF_VARS.fd across btrfs and zfs. NVRAM holds the UEFI boot entries and
lives outside the qcow2, so a disk-snapshot revert can't restore it. A zfs
run's ZFSBootMenu entries clobbered the btrfs GRUB entry, and with no
removable ESP fallback the btrfs base then booted to "no bootable device"
and timed out before archsetup ran.

NVRAM now carries the same per-profile suffix as the disk image, so the two
profiles keep separate boot state. Validated by a full green zfs run
(ArchSetup exit 0, Testinfra 96 passed / 0 failed).
---
 scripts/testing/lib/vm-utils.sh |  6 +++++-
 todo.org                        | 33 +++++++++++++++++++++++++++++++++
 2 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/scripts/testing/lib/vm-utils.sh b/scripts/testing/lib/vm-utils.sh
index 10c0ca5..118d1be 100755
--- a/scripts/testing/lib/vm-utils.sh
+++ b/scripts/testing/lib/vm-utils.sh
@@ -59,7 +59,11 @@ init_vm_paths() {
     local img_suffix=""
     [ "$FS_PROFILE" != "btrfs" ] && img_suffix="-$FS_PROFILE"
     DISK_PATH="$VM_IMAGES_DIR/archsetup-base${img_suffix}.qcow2"
-    OVMF_VARS="$VM_IMAGES_DIR/OVMF_VARS.fd"
+    # Per-profile NVRAM: UEFI boot entries live here, outside the qcow2, so a
+    # disk-snapshot revert can't restore them. Sharing one file across profiles
+    # let a zfs run's ZFSBootMenu entries clobber the btrfs GRUB entry, leaving
+    # the btrfs base unbootable (no removable ESP fallback to recover from).
+    OVMF_VARS="$VM_IMAGES_DIR/OVMF_VARS${img_suffix}.fd"
     PID_FILE="$VM_IMAGES_DIR/qemu.pid"
     MONITOR_SOCK="$VM_IMAGES_DIR/qemu-monitor.sock"
     SERIAL_LOG="$VM_IMAGES_DIR/qemu-serial.log"
diff --git a/todo.org b/todo.org
index ac0b68c..1870f08 100644
--- a/todo.org
+++ b/todo.org
@@ -21,6 +21,39 @@ The vocabulary is open — topic tags are coined as needed — so these are conv
 - *Effort / autonomy*: =:quick:= a spare-moment fix (minutes, not a sitting); =:solo:= Claude can carry it end to end — there's a build path, a test path, and no upfront decision needed (a leftover manual spot-check doesn't disqualify it).
 - *Topic / area* (open): the subsystem a task touches — e.g. =:hyprland:= =:waybar:= =:mpd:= =:music:= =:network:= =:tooling:= =:llm:= =:eask:= =:pocketbook:= =:cmail:=. Coin a new one when it aids filtering.
 * Archsetup Open Work
+** DONE [#B] VM test harness shared one NVRAM file across filesystem profiles :bug:test:
+CLOSED: [2026-06-27 Sat]
+The harness shared one OVMF NVRAM file (=vm-images/OVMF_VARS.fd=) across the btrfs
+and zfs profiles (=init_vm_paths= suffixed the disk image per profile but not the
+NVRAM). NVRAM lives outside the qcow2, so a disk-snapshot revert can't restore it,
+and a zfs run's ZFSBootMenu boot entries clobbered the btrfs GRUB entry. With no
+removable =\EFI\BOOT\BOOTX64.EFI= fallback on the base ESP, the next btrfs run
+booted into UEFI with no bootable device ("BdsDxe: No bootable option or device
+was found", then PXE/HTTP, then SSH timeout before archsetup ran). Found
+2026-06-27 trying to VM-validate the installer refactor.
+
+Fixed: =OVMF_VARS= now carries the same per-profile suffix as the disk image
+(=OVMF_VARS${img_suffix}.fd=) in =vm-utils.sh init_vm_paths=, so btrfs and zfs keep
+separate NVRAM. Validated by a full green zfs run 2026-06-27 (ArchSetup exit 0,
+Testinfra 96 passed / 0 failed). Remaining hardening tracked below.
+
+** TODO [#B] btrfs base VM unbuildable — archangel ISO bakes zfs-auto-snapshot :bug:test:
+=make test-vm-base= (btrfs) fails in archangel's installer: the ISO bakes a fixed
+AUR list ("downgrade yay informant zrepl pacman-cleanup-hook zfs-auto-snapshot
+topgrade ventoy-bin") into every install regardless of =FILESYSTEM=. On a btrfs
+install =zfs= isn't present, so =zfs-auto-snapshot='s =zfs= dependency can't
+resolve and the unattended pacstrap aborts ("unable to satisfy dependency 'zfs'
+required by zfs-auto-snapshot"). This is an archangel ISO bug (the baked list isn't
+controllable from =archsetup-test.conf=), so it blocks btrfs-profile VM testing
+until archangel ships an ISO that conditions the AUR list on the filesystem (or
+drops zfs tooling from non-zfs installs). The 2026-06-27 btrfs base regen attempt
+also wiped the prior (unbootable) btrfs base, so there's no btrfs base image until
+this is fixed. zfs-profile testing works (=make test FS_PROFILE=zfs=).
+
+Companion hardening (defense-in-depth, archangel-side): install the bootloader
+with a removable =\EFI\BOOT\BOOTX64.EFI= fallback so a base boots even from
+fresh/empty NVRAM, and real installs survive firmware that drops boot entries.
+
 ** TODO [#C] Scratchpad launch turns on focus-follows-mouse :bug:hyprland:
 Imported from roam inbox 2026-06-25. Repro: with two tiled windows, moving the mouse over the other tile does nothing (focus-follows-mouse off, as expected). Then launch a terminal (scratchpad), move the mouse over a tile, and focus now switches to the window under the pointer. Something about the scratchpad/terminal launch flips focus-follows-mouse on. Find what re-enables it (likely a Hyprland focus/input setting or a pyprland scratchpad side effect) and keep it off.
 
-- 
cgit v1.2.3