Change Details

**Summary** `sudo make testraid -- --uefi` fails. Install and first boot succeed normally under UEFI, but the test then simulates a failed RAID-1 member by wiping the primary disk and rebooting off the surviving mirror disk — and that reboot never reaches a login prompt. QEMU's boot-order arguments correctly prioritize the surviving disk, so this isn't a test-script ordering issue; OVMF simply has no bootable UEFI entry to find there. It appears VyOS's RAID-1 installer only makes the primary disk independently UEFI-bootable (ESP + GRUB EFI stub), the way it replicates BIOS/MBR boot code to both disks, but doesn't replicate the same for UEFI. The BIOS-only equivalent (make testraid without --uefi) passes today, and no existing CI target exercises --raid and --uefi together, so this gap has gone uncaught. **Steps to reoduce** * Build an ISO * Run `sudo make testraid -- --uefi` * Wait through install and first boot, which complete successfully **Actual behavior** Once the RAID disk-failure simulation wipes the primary disk and reboots, OVMF falls through to its interactive shell instead of booting VyOS: ``` Press ESC in 1 seconds to skip startup.nsh or any other key to continue. Shell> ``` No OS boots, so the harness times out waiting for a login prompt: ``` ERROR - Timeout waiting for VyOS system pexpect.exceptions.TIMEOUT: Timeout exceeded. at loginVM() (scripts/check-qemu-install:350). ```

**Summary** `sudo make testraid -- --uefi` fails. Install and first boot succeed normally under UEFI, but the test then simulates a failed RAID-1 member by wiping the primary disk and rebooting off the surviving mirror disk. That reboot never reaches a login prompt. OVMF only honors QEMU's per-device "bootindex" when disks sit behind separate PCI controllers; sharing one virtio-scsi-pci controller via SCSI LUN makes it always boot LUN 0 regardless of bootindex. **Steps to reoduce** * Build an ISO * Run `sudo make testraid -- --uefi` * Wait through install and first boot, which complete successfully **Actual behavior** Once the RAID disk-failure simulation wipes the primary disk and reboots, OVMF falls through to its interactive shell instead of booting VyOS: ``` Press ESC in 1 seconds to skip startup.nsh or any other key to continue. Shell> ``` No OS boots, so the harness times out waiting for a login prompt: ``` ERROR - Timeout waiting for VyOS system pexpect.exceptions.TIMEOUT: Timeout exceeded. at loginVM() (scripts/check-qemu-install:350). ```

**Summary** `sudo make testraid -- --uefi` fails. Install and first boot succeed normally under UEFI, but the test then simulates a failed RAID-1 member by wiping the primary disk and rebooting off the surviving mirror disk — and that reboot never reaches a login prompt. QEMU's boot-order arguments correctly prioritize the surviving disk, so this isn't a test-script ordering issue; OVMF simply has no bootable UEFI entry to find there. It appears VyOS's RAID-1 installer only makes the primary disk independently UEFI-bootable (ESP + GRUB EFI stub), the way it replicates BIOS/MBR boot code to both disks, but doesn't replicate the same for UEFI. The BIOS-only equivalent (make testraid without --uefi) passes today, and no existing CI target exercises --raid and --uefi together,at reboot never reaches a login prompt. OVMF only honors QEMU's per-device "bootindex" when disks sit behind separate PCI controllers; so this gap has gone uncaughtsharing one virtio-scsi-pci controller via SCSI LUN makes it always boot LUN 0 regardless of bootindex. **Steps to reoduce** * Build an ISO * Run `sudo make testraid -- --uefi` * Wait through install and first boot, which complete successfully **Actual behavior** Once the RAID disk-failure simulation wipes the primary disk and reboots, OVMF falls through to its interactive shell instead of booting VyOS: ``` Press ESC in 1 seconds to skip startup.nsh or any other key to continue. Shell> ``` No OS boots, so the harness times out waiting for a login prompt: ``` ERROR - Timeout waiting for VyOS system pexpect.exceptions.TIMEOUT: Timeout exceeded. at loginVM() (scripts/check-qemu-install:350). ```