[jammy] flash-kernel failure on simultaneous upgrade of kernel
Dave Jones
dave.jones at canonical.com
Wed Sep 20 14:11:52 UTC 2023
Could we get some kernel team input on LP: #2007827 ("flash-kernel
failure when upgrading f-k and kernel in the same cycle")?
Quick précis: at the point flash-kernel is triggered during kernel
installation (on those platforms where flash-kernel is used), the kernel
package may not be fully "installed". In particular, the initramfs-tools
trigger may not have run yet, so whilst the "initrd.img" link may exist,
it may not point to anything (or may point to an initrd that requires
regeneration). Nonetheless, flash-kernel attempts to run and (depending
on other configuration) either dies, or does the wrong thing.
Per comment 16 from Steve: "[...] Andy and I whiteboarded this about 5
years back, what we discussed never wound up being implemented in the
kernel packages. I believe the plan at the time was to use a dpkg-divert
in the kernel preinst to divert /boot/vmlinuz-$ver to
/boot/vmlinuz-$ver.dpkg-something, and then to un-divert it in the
postinst only after the initramfs has been generated. grub already has
code to ignore the pattern vmlinuz*.dpkg-* so no further changes would
be required for grub; and it would be easy to make flash-kernel match."
This sounds ideal, but would naturally require a commitment from the
kernel team.
I've implemented a hacky workaround in flash-kernel for lunar (and
mantic) but the SRU team (per comment 21) would like to know if the
kernel team want to weigh in (and presumably either make such a
commitment to a "proper" fix, or just say "no thanks, go ahead with the
hacky stuff") before approving any SRU of the workaround.
Thanks,
Dave Jones.
More information about the kernel-team
mailing list