From 08b63f4ae4ac587bdef3a9ff996afe85a68c36ce Mon Sep 17 00:00:00 2001 From: Craig Jennings 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 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'scripts/testing/lib') 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" -- cgit v1.2.3