[Bug 1949102] Autopkgtest regression report (livecd-rootfs/2.664.33)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted livecd-rootfs (2.664.33) for focal have finished running.
The following regressions have been reported in tests triggered by the package:

ubuntu-image/1.11+20.04ubuntu1 (armhf)


Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/focal/update_excuses.html#livecd-rootfs

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
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/1949102

Title:
  Preinstalled amd64 images cannot upgrade grub.cfg on boot partition +
  technical debt

Status in cloud-initramfs-tools package in Ubuntu:
  New
Status in livecd-rootfs package in Ubuntu:
  New
Status in cloud-initramfs-tools source package in Focal:
  Fix Committed
Status in livecd-rootfs source package in Focal:
  Fix Committed

Bug description:
  [Impact]

  This is a design flaw that needs to be fixed. Basically we inherited
  the design from old Ubuntu Core devices that the boot configuration is
  prepared in the gadget and - therefore - is quite static. Newer Core
  devices have mechanisms for updating boot assets, while classic
  images... well, we never actually thought about it.

  Now that we have a valid use-case for preinstalled amd64 images, we
  actually need to make sure we can update at least the grub config
  somehow. To do this, we introduce the hook from preinstalled desktop
  images from groovy+ with an additional change to generate the grub.cfg
  by using `update-grub2`. We switch the design to now only shipping a
  blanket grub.cfg on the boot partition, pointing to the rootfs one -
  which can be freely updated via existing mechanisms.

  While adding the hook, we also fix a few other technical dept - like
  adding a swap file and making the rootfs resizable. Everything that we
  already had for our Pi images in groovy+.

  The growroot part might also require a quick workaround in cloud-
  initramfs-tools.

  [Test Case]

  * Base test case:

  Build an image with -proposed enabled, make sure that it still boots
  as before on Intel IOT platforms. Try booting the image on an USB when
  there are other USB drives present on the device.

  * Growroot:

  Resize the image so that growroot finds space to expand the rootfs.
  Boot the image, make sure that the image boots fine on first boot (no
  initramfs prompt!). Log into the system and run `sudo udevadm info
  /dev/sda3` and check if there are "ID_*" properties present. Check if
  the root partition has expanded as expected.

  * Grub updates:

  On the booted image, run `sudo update-grub2`, make sure that there are no errors present. Reboot, check if the image still boots correctly.
  To make sure the rootfs grub.cfg is used, modify /etc/default/grub and change GRUB_TIMEOUT to 10. Run `sudo update-grub2` again and reboot. Confirm that the grub menu appears with a 10 second timeout.

  
  [Regression Potential]

  This can basically only regress intel-iotg desktop images, which is
  what we want to fix right now. But it requires for the images to go
  through the whole testing cycle again, to make sure that everything
  still works - since we're basically switching to a completely new
  grub.cfg. The test case should be sufficient to make sure there are no
  regressions.

  The cloud-initramfs-tools changes for growroot might, in some very
  weird way, break cloud image resizing. So it would be good to double
  check with the CPC team if images still work as expected with this
  change.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-initramfs-tools/+bug/1949102/+subscriptions