Ok, so the fact that we thought this worked is clearly the result from bad testing on our part, probably because of our simplestreams parsing code we fixed yesterday...
We obviously still need to move LXD onto this images as booting the non- kvm images takes twice as long as it should (due to them panic + reboot every time) AND also breaks cloud-init, at least in the way we'd like to use it. Now realistically this can't be fixed in time for 20.04, so what we've done is submitted a change to simplestreams to force all LXD users onto the non-kvm image: https://code.launchpad.net/~stgraber/simplestreams/+git/simplestreams/+merge/382597 We'll also tell all users of `ubuntu:` and `ubuntu-daily:` that they need to do: - lxc config device add NAME config disk source=cloud-init:config Which passes a stable config drive to cloud-init, avoiding the cloud- init issue they'd be getting out of the box. Moving forward, we'd like the -kvm kernel to be both EFI enabled AND signed. This will then allow those images to work properly inside LXD, at which point we can undo the simplestreams change and have those images used once again by our users. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1873809 Title: disk-kvm.img aren't UEFI bootable Status in cloud-images: New Status in linux-kvm package in Ubuntu: New Bug description: The `disk-kvm.img` images which are to be preferred when run under virtualization, completely fail to boot under UEFI. This is a critical issue as those are the images that LXD is now pulling by default. User report on the LXD side: https://github.com/lxc/lxd/issues/7224 Note that the non optimized images boot just fine (disk1.img). I've reproduced this issue with: - wget http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda focal-server-cloudimg-amd64-disk-kvm.img -m 1G On the graphical console, you'll see EDK2 load (TianoCore) followed by basic boot messages and then a message from grub (error: can't find command `hwmatch`). Those also appear on successful boots of other images so I don't think there's anything concerning that. However it'll hang indefinitely and eat up all your CPU. Switching to the text console view (serial0), you'll see the same issue as that LXD report: BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM00003 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM00001 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM00001 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) error: can't find command `hwmatch'. e!!!! X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - 00000000 !!!! ExceptionData - 0000000000000000 RIP - 000000003FF2DA12, CS - 0000000000000038, RFLAGS - 0000000000200202 RAX - AFAFAFAFAFAFAFAF, RCX - 000000003E80F108, RDX - AFAFAFAFAFAFAFAF RBX - 0000000000000398, RSP - 000000003FF1C638, RBP - 000000003FF34360 RSI - 000000003FF343B8, RDI - 0000000000001000 R8 - 000000003E80F108, R9 - 000000003E815B98, R10 - 0000000000000065 R11 - 0000000000002501, R12 - 0000000000000004, R13 - 000000003E80F100 R14 - 0000000000000000, R15 - 0000000000000000 DS - 0000000000000030, ES - 0000000000000030, FS - 0000000000000030 GS - 0000000000000030, SS - 0000000000000030 CR0 - 0000000080010033, CR2 - 0000000000000000, CR3 - 000000003FC01000 CR4 - 0000000000000668, CR8 - 0000000000000000 DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000 DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400 GDTR - 000000003FBEEA98 0000000000000047, LDTR - 0000000000000000 IDTR - 000000003F2D8018 0000000000000FFF, TR - 0000000000000000 FXSAVE_STATE - 000000003FF1C290 !!!! Find image based on IP(0x3FF2DA12) /build/edk2-dQLD17/edk2-0~20191122.bd85bf54/Build/OvmfX64/RELEASE_GCC5/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll (ImageBase=000000003FF1E000, EntryPoint=000000003FF30781) !!!! If booting in a SecureBoot enabled environment, you instead get a `Access Denied` at kernel loading time, indicating that the kernel binary isn't a normal signed kernel. That has the same result (boot hangs) but without the crash message. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1873809/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
