Jammy buildd image doesn't boot because grub is installed to \EFI\debian instead of \EFI\ubuntu
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-images |
Fix Released
|
High
|
John Chittum | ||
Focal |
Fix Released
|
Undecided
|
Unassigned | ||
Jammy |
Fix Released
|
Undecided
|
Unassigned | ||
grub2 (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Focal |
New
|
Undecided
|
Unassigned | ||
Jammy |
New
|
Undecided
|
Unassigned | ||
livecd-rootfs (Ubuntu) |
Confirmed
|
Undecided
|
John Chittum | ||
Focal |
Fix Released
|
Undecided
|
Unassigned | ||
Jammy |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Recent Jammy buildd images fail to boot (since at least September 1st: https:/
Trying to run an image from https:/
I haven't checked other image series.
This is similar to https:/
SRU Template for cloud-images and livecd-rootfs (not the change for grub2)
[ Impact ]
* snapcraft consumers daily buildd images for running snap builds. in this case Core22 based builds will use the daily 22.04 build image. At this time, that image drops to a grub menu. This causes snap builds to fail by having everything hang for a long time (multipass doesn't handle this case well, and it hangs and enters an odd state. snapcraft then hangs, also in a bad state)
[ Test Plan ]
* build image
* boot image using qemu. example script:
qemu-system-x86_64 \
-cpu host -machine type=q35,accel=kvm -m 1024 \
-nographic \
-snapshot \
-netdev id=net00,
-device virtio-
-drive if=virtio,
-cdrom <A_WORKING_
-bios /usr/share/
This is very close to how multipass calls qemu under the hood.
* observe that the machine successfully boots (no grub prompt)
[ Where problems could occur ]
* for `livecd-rootfs`, images could still fail to boot, probably from an incorrect GRUB variable being written in the file.
* ensuring grub2 is updatable properly. The current known use case for buildd daily vm images is multipass, via snapcraft, so they're ephemeral. but there is nothing stopping someone from utilizing them in a longer running setup.
[ Other Info ]
* buildd images need more testing. that's on my team at this time. it's in the backlog as an item, and we should endeavor to add it in the next roadmap cycle.
Related branches
- Steve Langasek: Approve
-
Diff: 66 lines (+23/-11)2 files modifieddebian/changelog (+7/-0)
live-build/buildd/hooks/02-disk-image-uefi.binary (+16/-11)
summary: |
- Jammy buildd image doesn't boot + Jammy buildd image doesn't boot because grub is installed to \EFI\debian + instead of \EFI\ubuntu |
Changed in livecd-rootfs (Ubuntu): | |
status: | Confirmed → Invalid |
description: | updated |
description: | updated |
1. could you provide any specific failures?
2. can you provide how it's booting? UEFI boot? Secureboot? etc
right now i'm trying directly with QEMU. in a Bios booting (not UEFI) setup, i cannot reproduce.
with UEFI i'm seeing this error, which is new to me:
BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM00005 " from PciRoot( 0x0)/Pci( 0x1F,0x2) /Sata(0x2, 0xFFFF, 0x0): Not Found 0x0)/Pci( 0x3,0x0) 0x0)/Pci( 0x3,0x0)
BdsDxe: loading Boot0002 "UEFGNU GRUB version 2.06iRoot(
BdsDxe: starting Boot0002 "UEFI Misc Device" from PciRoot(
Minimal BASH-like line editing is supported. For the first word, TAB
lists possible command completions. Anywhere else TAB lists possible
device or file completions.
this is my QEMU call:
qemu-system-x86_64 \ type=user, hostfwd= tcp::2222- :22 \ net-pci, netdev= net00 \ format= qcow2,file= 20230901- jammy-server- cloudimg- amd64-disk1. img \ format= raw,file= /home/jchittum/ dev01/vmdks/ ci-ssh- pub-set. iso \ format= raw,file= /usr/share/ OVMF/OVMF_ CODE.fd, readonly= on
-cpu host -machine type=q35,accel=kvm -m 2048 \
-nographic \
-snapshot \
-netdev id=net00,
-device virtio-
-drive if=virtio,
-drive if=virtio,
-drive if=pflash,
I can confirm that OVMF_CODE.fd is on my local filesystem at that path:
stat /usr/share/ OVMF/OVMF_ CODE.fd OVMF/OVMF_ CODE.fd
File: /usr/share/
Size: 1966080 Blocks: 3840 IO Block: 4096 regular file
Device: 10305h/66309d Inode: 11534775 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2023-09-05 15:22:39.599644073 -0500
Modify: 2022-09-12 22:05:26.000000000 -0500
Change: 2022-10-28 01:11:35.003430249 -0500
Birth: 2022-10-28 01:11:34.859427923 -0500
What's interesting is when i do this on an Openstack instance, i see the failure but it still boots:
BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM00005 " from PciRoot( 0x0)/Pci( 0x1F,0x2) /Sata(0x2, 0xFFFF, 0x0): Not Found 0x0)/Pci( 0x3,0x0) 0x0)/Pci( 0x3,0x0) lcy02-amd64- 027) (gcc (Ubuntu 11.4.0- 1ubuntu1~ 22.04) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #91-Ubuntu SMP Mon Aug 14 14:14:14 UTC ) /boot/vmlinuz- 5.15.0- 82-generic root=LABEL= cloudimg- rootfs ro console=tty1 console=ttyS0
BdsDxe: loading Boot0002 "UEFI Misc Device" from PciRoot(
BdsDxe: starting Boot0002 "UEFI Misc Device" from PciRoot(
[ 0.000000] Linux version 5.15.0-82-generic (buildd@
[ 0.000000] Command line: BOOT_IMAGE=
Lots more to do on triage, but if i know the way this is being launched more specifically, it'll help.