EFI boot from ISO does not work in existing VMs

[awhb]

I have installed Windows 10 64 Bit as guest in EFI mode in a VM under Windows 10 64 Bit as host system, it works fine. However when I mount a bootable ISO (e. g. an actual Windows 10 ISO) and set the optical device as first option in the boot priority, the machine still boots the installed Windows 10 from hard disk. Obviously the boot order is without any effect. When I create a new VM in EFI mode, booting from ISO works one time, when I close the dialog, which asks the boot medium. In legacy guest mode (without EFI) everything works fine. I found this bug first time in Virtual Box 6.1.

[aeichner]

Known issue, the boot order in the VM settings work only with the legacy BIOS so far. If you want to change the boot order, press ESC during the EFI firmware phase to get into the boot manager menu. There you can change the boot order.

[awhb]

Thanks for response. Is it planned that this bug will be fixed in the next update?

[aeichner]

No, and there is no plan to fix it currently. The changes are quite invasive and big compared to the benefit at the moment so we don't want to spend resources on it. The only thing we might do is to disable the boot priority settings when EFI selected with an explanation as to why.

[Graham Perrin]

Cc: grahamperrin

[Synthead]

If you want to change the boot order, press ESC during the EFI firmware phase to get into the boot manager menu. There you can change the boot order.

This doesn't seem to work. I am pressing Esc while the VM boots up, and it seems to ignore the keystroke. This is VirtualBox 6.1.34 on Windows.

[mauricev1]

The UEFI boot manager menu is responding to the ESC key on a Mac under 6.1.38.

[shasheene]

I ran into this open 4 year old issue while writing a script to uses VirtualBox's command-line interface to non-interactively start and stop virtual machines.

The bug is a blocker for my purposes, so I spent some time and developed a hacky-but-functional workaround that I'll share here in case it's useful.

Basically I use the command-line interface (and I believe you can use the graphical interface) to simply detach the drives from the virtual SATA controller. Then you can boot the VM and it boots from the ISO in the virtual drive as intended. And after you've started the booting process, you can reattach the drives. Even after the ISO has booted, Linux is able to detect the drives within a few seconds.

There are a few gotcha with my solution:

• the virtual SATA ports need to be enabled as 'hotpluggable' (note: it's a SATA port option, not a SATA controller option that applies to all ports)
• When detaching, you can't remove the SATA port entirely, but you instead need to swap in a different virtual drive (because hotpluggable is)
• VirtualBox's output doesn't like this (error message), but it works great!

Here are the steps I use with the command-line interface for a VM named "MyVirtualBoxVM":

1. Replace the SATA device with some-blank-temp-drive.vdi

   VBoxManage storageattach MyVirtualBoxVM --storagectl SATA Controller --port 0 --device 0 --hotpluggable on --type hdd --medium some-blank-temp-drive.vdi
   

2. Boot VM into DVD (since the bootable EFI drive is removed)

   VBoxManage startvm MyVirtualBoxVM --type headless
   

3. At some point after booting from DVD, reattach HDs

   VBoxManage storageattach MyVirtualBoxVM --storagectl SATA Controller --port 0 --device 0 --hotpluggable on --type hdd --medium my-original-harddrive.vdi
   

Note: ignore any error that says VBoxManage: error: The machine is not mutable (state is Running) -- it attaches without issue despite the error.

In the guest OS (Ubuntu), the dmesg -Tw output shows the original SATA disconnection and the new one reattaching:

[Thu Nov 23 14:41:01 2023] ata3.00: qc timeout (cmd 0xec)
[Thu Nov 23 14:41:01 2023] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[Thu Nov 23 14:41:01 2023] ata3.00: revalidation failed (errno=-5)
[Thu Nov 23 14:41:01 2023] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[Thu Nov 23 14:41:01 2023] ata3.00: serial number mismatch 'VB11111111-11111111' != 'VB50505050-50505050'
[Thu Nov 23 14:41:01 2023] ata3.00: revalidation failed (errno=-19)
[Thu Nov 23 14:41:01 2023] ata3: limiting SATA link speed to 1.5 Gbps
[Thu Nov 23 14:41:07 2023] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[Thu Nov 23 14:41:07 2023] ata3.00: serial number mismatch 'VB11111111-11111111' != 'VB50505050-50505050'
[Thu Nov 23 14:41:07 2023] ata3.00: revalidation failed (errno=-19)
[Thu Nov 23 14:41:07 2023] ata3.00: disabled
[Thu Nov 23 14:41:12 2023] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[Thu Nov 23 14:41:12 2023] ata3.00: ATA-6: VBOX HARDDISK, 1.0, max UDMA/133
[Thu Nov 23 14:41:12 2023] ata3.00: 104857600 sectors, multi 128: LBA48 NCQ (depth 32)
[Thu Nov 23 14:41:12 2023] ata3.00: configured for UDMA/133
[Thu Nov 23 14:41:12 2023] ata3.00: detaching (SCSI 2:0:0:0)
[Thu Nov 23 14:41:12 2023] sd 2:0:0:0: [sda] Synchronizing SCSI cache
[Thu Nov 23 14:41:12 2023] sd 2:0:0:0: [sda] Stopping disk
[Thu Nov 23 14:41:12 2023] scsi 2:0:0:0: Direct-Access     ATA      VBOX HARDDISK    1.0  PQ: 0 ANSI: 5
[Thu Nov 23 14:41:12 2023] sd 2:0:0:0: [sda] 104857600 512-byte logical blocks: (53.7 GB/50.0 GiB)
[Thu Nov 23 14:41:12 2023] sd 2:0:0:0: [sda] Write Protect is off
[Thu Nov 23 14:41:12 2023] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
[Thu Nov 23 14:41:12 2023] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[Thu Nov 23 14:41:12 2023] sd 2:0:0:0: Attached scsi generic sg1 type 0
[Thu Nov 23 14:41:12 2023]  sda: sda1 sda2 sda3 sda4
[Thu Nov 23 14:41:12 2023] sd 2:0:0:0: [sda] Attached SCSI disk

This hacky workaround works fine on VirtualBox v7.0.12 on my Linux host OS.

I had success with using the GUI to do the same thing too.