Updating grub-efi breaks classic images

What gadget does this happen with, and should it not be considered a bug in the gadget that it produces a layout that is incompatible with the layout as expected by the grub packages?

Something like this gadget.yaml will make this happen: https://paste.ubuntu.com/p/ncPBvvqD7W/

The specified grub.cfg will go to the EFI partition, and there will be no grub.cfg in the rootfs partition. There is not really a way to specify what we want in /boot/grub.

This feels to me like a missing piece in the current image build behavior. When preparing the classic image, we delegated the assembly of all grub (bootloader) bits to the gadget tree. Because of that, we were discarding the /boot/grub/* files from the root filesystem to not duplicate the boot info in both the rootfs build and the gadget build. But obviously we missed the fact that in case of grub, we need to have the bootloader configuration in both the boot partition and rootfs. Right now our gadget-prepared grub bits only go to the boot partition.

I obviously missed this part during the classic image preparation reviews since generally for model-assertion based builds ubuntu-image doesn't have to worry about this. For core images the /boot/grub directory is the mount point of the boot partition, so it's enough for everything to be in the gadget.

I think we'd want parity with what the core images do in this case, i.e. mounting the boot partition at /boot/grub. In my opinion this should make sense for preinstalled images, additionally allowing for upgrades of the boot partition contents (currently that's not possible). Would that be a senseful solution for preinstalled ubuntu classic images?

So I worked on this quite recently and prepared two different solutions to the problem:

Solution A: fixing this in ubuntu-image. For classic images we already manipulate the fstab file for the root partition handling (noticed we actually have a bug there, but that's a separate thing). While we're at it, we can actually try handling creation of all the links needed for proper grub upgrade stories.

Solution B: fixing this in livecd-rootfs. Adding a hook to livecd-rootfs ubuntu-cpc that would, for IMAGEFORMAT=none (so ubuntu-image-targetted rootfs builds) create the needed links based on what bootloader packages have been installed on the rootfs.

It's hard for me to decide which solution is best. On one hand, we delegated bootloader composition and preparation to the gadget tree, so solution A seems like the right way to go conceptually. Since in this case the rootfs basically shouldn't care much about bootability of the image, as that's something the gadget (and ubuntu-image) makes sure of. On the other hand however, all these changes are to support proper upgrades of packages *on the rootfs*. So maybe we should have the rootfs (livecd-rootfs here) making sure everything works as needed?

Anyway, both solutions are basically complete, but still in testing. I'll submit both here and then we can figure out which way to go.

Also, along with this proposition, I wanted to add a common, consistent system-boot mount-point for all our ubuntu-image built images. This way we can handle all the custom per-bootloader requirements as symlinks to the system-boot mount directory. The actual mount-point location is still open to discussion though (I just picked one without much thought).

Alfonso, sorry this took so long - the work on this piece has been a bit pushed back and pushed back, which was also my fault. So after discussing this with Steve some more and investigating all other fancy approaches, we came to the conclusion that not clearing /boot/grub/ at all feels like the lesser evil. So I prepared a PR that reverts the design decision of clearing /boot/grub.

This way we'll advertise that the boot configuration should still, at best, be part of the gadget tree, but we're giving the ability to developers to decide if they want to maybe use what's provided via the rootfs as well.

Alfonso, could you take a look at https://github.com/CanonicalLtd/ubuntu-image/pull/183 and tell me if this would solve your problem?

@Lukasz, +1 on the change, this should protect against breakages when updating grub-efi. Thank you!

(released in 1.9)