Comment 21 for bug 1918427

Hi Dan,

Could you summarize the problem with flash-kernel and this system?

* dann frazier <email address hidden> [2021-03-15 18:25]:
> Attached is a patch for curtin that works for me, though it could use
> some cleanup. It installs flash-kernel in the same place GRUB gets
> installed for EFI-based systems, which seems like the appropriate place.
> Before installint it, it diverts /usr/sbin/flash-kernel so that flash-
> kernel's postinst doesn't try (and fail) to flash a kernel that isn't
> yet installed. There's existing code in enable_update_initramfs() that
> will undo this diversion. I suspect we should refactor
> disable_update_initramfs() somehow instead of duplicating this code like
> I've done here.

Looking at the patch, it looks like you could instead modify
_update_initramfs_tools() to only return flash-kernel in the case that
it's needed rather than for all aarch64.

Alternatively, enable/disable_update_initramfs could take a force
boolean which would perform the operation whether the tool is present
or not (though I don't know if dpkg-divert cares about the presence
of the binary-to-be-diverted).

>
> I've tested this w/ a locally-hacked squash image that has flash-kernel
> purged and a PPA kernel that allows grub-efi-arm64 to satisfy the
> bootloader Recommends. On an EFI-based system, flash-kernel never gets
> installed. On a Moonshot m400, flash-kernel gets installed as expected.
>
> Once curtin has been updated with a fix like this, and MAAS has been
> refreshed to include it, I think we should then be able to remove flash-
> kernel from the arm64 cloud images.

What's the criteria for determining if a particular arm instance
requires flash-kernel or not?

Ryan