[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