Hey folks, I'm running libvirt 10.1.0/qemu-system-x86-core-9.0.1-1.fc40.x86_64 on Fedora 40. I'm trying to boot an Ubuntu image in UEFI mode, like this: virt-install -r 2048 -n ubuntu.virt --os-variant ubuntu24.04 \ --disk pool=default,size=10,backing_store=mantic-server-cloudimg-amd64.img,backing_format=qcow2 \ --cloud-init root-ssh-key=$HOME/.ssh/id_ed25519.pub \ --boot uefi This results in the domain booting up and then immediately resetting: BdsDxe: loading Boot0001 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x2,0x3)/Pci(0x0,0x0) BdsDxe: starting Boot0001 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x2,0x3)/Pci(0x0,0x0) Reset System Domain creation completed. At this point, the machine is actually powered down and needs to be restarted manually: virsh start ubuntu.virt This works fine, and the domain boots successfully, but now the cloud-init metadata provided by the `--cloud-init` option to `virt-install` is no longer available (because this is no longer the initial, virt-install managed boot of the domain). What is causing the firmware to reset the system when it first boots?

On Fri, Nov 01, 2024 at 02:19:46PM +0000, Daniel P. Berrangé wrote: > On Fri, Nov 01, 2024 at 09:54:14AM -0400, Lars Kellogg-Stedman wrote: > > Hey folks, > > > > I'm running libvirt 10.1.0/qemu-system-x86-core-9.0.1-1.fc40.x86_64 on Fedora > > 40. I'm trying to boot an Ubuntu image in UEFI mode, like this: > > > > virt-install -r 2048 -n ubuntu.virt --os-variant ubuntu24.04 \ > > --disk pool=default,size=10,backing_store=mantic-server-cloudimg-amd64.img,backing_format=qcow2 > > \ > > --cloud-init root-ssh-key=$HOME/.ssh/id_ed25519.pub \ > > --boot uefi > > > > This results in the domain booting up and then immediately resetting: > > > > BdsDxe: loading Boot0001 "UEFI Misc Device" from > > PciRoot(0x0)/Pci(0x2,0x3)/Pci(0x0,0x0) > > BdsDxe: starting Boot0001 "UEFI Misc Device" from > > PciRoot(0x0)/Pci(0x2,0x3)/Pci(0x0,0x0) > > Reset System > > > > Domain creation completed. > > > > At this point, the machine is actually powered down and needs to be > > restarted manually: > > > > virsh start ubuntu.virt > > > > This works fine, and the domain boots successfully, but now the cloud-init > > metadata provided by the `--cloud-init` option to `virt-install` is no longer > > available (because this is no longer the initial, virt-install managed boot of > > the domain). > > > > What is causing the firmware to reset the system when it first boots? > > This will be shim configuring the NVRAM bootloade entries. > > You've taken a pre-installed disk image, but have not been provided > the associated UEFI NVRAM that was populated when the disk was first > installed. This is normal, since the NVRAM created at the time is > not guaranteed to be compatible with your EFI binary. > > Your VM is booting with a clean NVRAM, and no bootloader entries will > be present. Thus EFI launches the default binary $ESP/EFI/BOOT/BOOTX64.EFI, > which is a copy of shim. > > Shim sees that has been launched with no bootloader entries present, > and so will then invoke $ESP/EFI/BOOT/fbx64.efi which will read the > info in $ESP/<vendor>/BOOTX64.CSV file and create boot loader entries > in the EFI NVRAM. Then it will trigger a system reset, which is the > one you see. <vendor> in your case is probably 'ubuntu' I guess. > > When you run virsh start, EFI will see bootloader entries and so > instead of $ESP/EFI/BOOT/BOOTX64.EFI, it will probably be launching > $ESP/EFI/ubuntu/shim.efi, which will then run grub, etc, as normal > The latter will be done forever more, unless you purge the NVRAM > of all bootloader entries. > > Ideally virt-install would be aware of this and automatically restart > the VM after shim populates the NVRAM. Depends if we can come up with > a relativel foolproof way to identify this situation. The need for a full reset (as opposed to shim just creating the missing entries and moving on) is apparently triggered by the presence of a TPM, which these days we add by default when UEFI is used. virt-manager has added some code to deal with this very situation: https://github.com/virt-manager/virt-manager/commit/ec434948a8384541c56bf... Unfortunately it's not part of any release yet, but once it is the scenario we're discussion should no longer present itself.