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?
Hi Dan,
Could you summarize the problem with flash-kernel and this system?
* dann frazier <email address hidden> [2021-03-15 18:25]: flash-kernel so that flash- update_ initramfs( ) that update_ initramfs( ) somehow instead of duplicating this code like
> 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/
> kernel's postinst doesn't try (and fail) to flash a kernel that isn't
> yet installed. There's existing code in enable_
> will undo this diversion. I suspect we should refactor
> disable_
> I've done here.
Looking at the patch, it looks like you could instead modify initramfs_ tools() to only return flash-kernel in the case that
_update_
it's needed rather than for all aarch64.
Alternatively, enable/ disable_ update_ initramfs could take a force to-be-diverted) .
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-
>
> 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