From 1c4145a581115e160fe0c0f995f445283c52d454 Mon Sep 17 00:00:00 2001
From: Codex <codex@openai.com>
Date: Fri, 8 May 2026 14:10:17 -0500
Subject: [PATCH] fix(ci1): swap bootOrder so Windows install ISO boots first
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Original order: rootdisk=1 (empty 200Gi virtio), windows-iso=2 (SATA CDROM).
UEFI tried the empty virtio disk first, got nothing, fell back to Boot0001
(the SATA CDROM) with a short timeout, and aborted with:
  BdsDxe: failed to start Boot0001 ... Time out
  BdsDxe: No bootable option or device was found.

VM had been running 38+ min with rootdisk actualSize stuck at 4.13 GiB and
no AgentConnected condition — install never started.

Diagnosis via debug pod mounting the windows-server-2025-iso PVC:
  /pvc/disk.img: ISO 9660 CD-ROM filesystem data 'SSS_X64FRE_EN-US_DV9' (bootable)
  bytes 0..15: zeros (NOT QCOW2 magic 51 46 49 fb)
  bytes 32769..32773: "CD001" (ISO9660 primary volume descriptor)

So the PVC content is a real bootable ISO — the only fix needed is to make
the ISO bootOrder=1 for first install. After Windows installs, it writes its
own UEFI Boot#### entries pointing at the rootdisk EFI partition; UEFI then
boots from rootdisk going forward and the ISO at bootOrder:2 is a fallback
for re-install scenarios.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---
 apps/kubevirt-vms/ci1.yaml | 25 ++++++++++++++++++++-----
 1 file changed, 20 insertions(+), 5 deletions(-)

diff --git a/apps/kubevirt-vms/ci1.yaml b/apps/kubevirt-vms/ci1.yaml
index ddb010a..d3ed7e7 100644
--- a/apps/kubevirt-vms/ci1.yaml
+++ b/apps/kubevirt-vms/ci1.yaml
@@ -329,14 +329,29 @@ spec:
         devices:
           tpm: {}             # Non-persistent vTPM — sufficient for runner; no BitLocker
           disks:
-            - name: rootdisk
-              bootOrder: 1
-              disk:
-                bus: virtio
+            # bootOrder: ISO must be 1 for first-boot install (the rootdisk has no
+            # EFI bootloader yet). After Windows installs, it writes its own UEFI
+            # Boot#### entries pointing at the rootdisk's EFI partition; UEFI then
+            # boots from rootdisk going forward and the ISO at bootOrder:2 acts as
+            # a fallback for re-install scenarios.
+            #
+            # Original (broken) order had rootdisk=1, windows-iso=2 — UEFI tried
+            # the empty virtio disk first, got nothing, fell back to the SATA
+            # CDROM at Boot0001 with a short timeout, and timed out before the
+            # CDROM enumerated. Console showed:
+            #   BdsDxe: failed to start Boot0001 ... Time out
+            #   BdsDxe: No bootable option or device was found.
+            # Confirmed via debug pod: PVC content IS a real bootable ISO9660
+            # (file: "ISO 9660 CD-ROM filesystem data ... (bootable)"), so the
+            # only bug was boot priority.
             - name: windows-iso
-              bootOrder: 2
+              bootOrder: 1
               cdrom:
                 bus: sata
+            - name: rootdisk
+              bootOrder: 2
+              disk:
+                bus: virtio
             - name: virtio-drivers
               cdrom:
                 bus: sata