[Bug 2034253] Re: Jammy buildd image doesn't boot because grub is installed to \EFI\debian instead of \EFI\ubuntu

[Julian Andres Klode]

This seems to have come up again in noble

** Changed in: livecd-rootfs (Ubuntu)
       Status: Invalid => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to livecd-rootfs in Ubuntu.
https://bugs.launchpad.net/bugs/2034253

Title:
  Jammy buildd image doesn't boot because grub is installed to
  \EFI\debian instead of \EFI\ubuntu

Status in cloud-images:
  Fix Released
Status in cloud-images focal series:
  Fix Released
Status in cloud-images jammy series:
  Fix Released
Status in grub2 package in Ubuntu:
  In Progress
Status in livecd-rootfs package in Ubuntu:
  Confirmed
Status in grub2 source package in Focal:
  New
Status in livecd-rootfs source package in Focal:
  Fix Released
Status in grub2 source package in Jammy:
  New
Status in livecd-rootfs source package in Jammy:
  Fix Released

Bug description:
  Recent Jammy buildd images fail to boot (since at least September 1st:
  https://github.com/canonical/craft-
  application/actions/runs/6016993725/job/16424264050?pr=64).

  Trying to run an image from https://cloud-
  images.ubuntu.com/buildd/daily/jammy/current in QEMU, only gets me a
  GRUB prompt. Multipass and Snapcraft consequently fail to work with
  these images.

  I haven't checked other image series.

  This is similar to https://bugs.launchpad.net/cloud-
  images/+bug/2027686, but a new issue.

  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,type=user,hostfwd=tcp::2222-:22 \
  -device virtio-net-pci,netdev=net00 \
  -drive if=virtio,format=qcow2,file=build.output/livecd.ubuntu-base.disk-linux-virtual.img \
  -cdrom <A_WORKING_CLOUD_INIT_FILE> \
  -bios /usr/share/OVMF/OVMF_CODE.fd

  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2034253/+subscriptions