OVF/OVA import results in a broken VM on Arm

[stephenr]

Importing an OVF/OVA format VM on Arm "succeeds" without error, but on boot the VM drops to an EFI shell and won't boot the installed OS.

The result is the same whether using the GUI Import Appliance, or the VBoxManage import command.

[stephenr]

screenshot of EFI shell

[stephenr]

VBox.log

[stephenr]

So it seems that this is related to how VirtualBox handles EFI booting.

Somehow the boot options work when the VM is created, but once it's exported and re-imported, those options are essentially lost/ignored.

Until this is resolved in VirtualBox, a workaround is to copy the appropriate distribution .efi (e.g. /boot/efi/EFI/debian/grubaa64.efi) file to /boot/efi/EFI/boot/bootaa64.efi.

I assume this also relates to the note in ​https://docs.oracle.com/en/virtualization/virtualbox/6.0/user/efi.html#efibootargs:

It is currently not possible to manipulate EFI variables from within a running guest.

[paulson]

The root cause of the lack of boot after importing the VM is that the VM's NVRAM file is not included in the exported appliance. On ARM-based hosts all VMs use UEFI for their firmware and thus have a <VM>.nvram which contains the UEFI firmware settings for the VM including the boot process details. The support for adding the <VM>.nvram file to an exported appliance and also extracting it when importing a VM has been added to the development branch of VirtualBox and will also be part of the next maintenance release of VirtualBox 7.1.x.

[galitsyn]

Should be fixed in 7.2.0. Closing.