Comment 28 for bug 1928674

We figured out the root causes for the failure on the cloud, and it is not a regression of this update compared to the one in -updates, so I'm marking xenial as verified again.

What is happening on the cloud is that the cloud images ship with the grub "loader" installed into
/boot/efi/EFI/BOOT/BOOTAA64.EFI, which loads the modules and core image from /boot/grub. On upgrade, we install new modules to /boot/grub and the loader to /boot/efi/EFI/ubuntu/grubaa64.efi - we do not replace the removable path one.

We do register the new grub in the boot menu, but the cloud does not seem to persist that - the entry is gone in the next boot (or the 2nd boot?). There are some KVM crashes in the cloud due to
https://github.com/qemu/qemu/commit/089fd80376196adc0274a53eb9729c3ef7ee5ae7 which might be related and corrupt the variable storage, I can't say.

So when we boot the next time, instead of loading the new grubaa64.efi, it will load the BOOTAA64.EFI from 2.02 instead, which then gets confused by the 2.04 modules.

We can fix this by passing --force-extra-removable to grub-install, which is supported in xenial. I believe the maintainer scripts are messed up a bit. I can set force_efi_extra_removable, but the maintainer script checks for no_efi_extra_removable. I reconfigured grub-efi-arm64 to set the latter to true, but the former is still true as well, so we don't pass the argument. Something went wrong in migrating this setting presumably.

# Skip extra installation to the EFI removable media path?
grub-efi-arm64 grub2/no_efi_extra_removable boolean true
# Force extra installation to the EFI removable media path?
grub-efi-arm64 grub2/force_efi_extra_removable boolean true