Comment 18 for bug 2007827

On Fri, Jun 23, 2023 at 05:40:57PM -0000, Steve Langasek wrote:
> Dave, I don't agree that there's a relevant difference here between
> flash-kernel and grub.
>
> Grub: initrd not yet generated; grub postinst is called and adds
> kernel as first entry in grub.cfg; power event happens before kernel
> postinst is called; system fails to (noninteractively) boot.
>
> flash-kernel: initrd not yet generated; flash-kernel postinst is
> called and writes kernel (without initramfs) to the boot partition;
> power event happens before kernel postinst is called; system fails to
> boot.
>
> Both scenarios need to be guarded against, and we should use the same
> model for both (and any other bootloaders on other archs).

The "system loses power while installing the kernel" is an extremely
variable story on the flash-kernel side of things. On some platforms
it's mostly guarded against, on others (including the Pi) it's not (and
never has been), and fixing this particular bug will not change that.

> *Unfortunately*, it turns out that while 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.

I see; so "linux-version list" would be modified to ignore the
"vmlinuz*.dpkg-*" pattern, causing flash-kernel to ignore the diverting
kernel as a candidate.

> However, none of this matters so long as the kernel doesn't implement
> such an interface.
>
> In any case, I'm not happy with the proposed implementation in flash-
> kernel. I think rooting around in the dpkg database is bad form.
> Ultimately, though, it's not my opinion on this that matters - we
> really need input from the Kernel Team here wrt what interface we're
> going to support between the packages. I subscribed Andy to the bug,
> but he hasn't replied yet; adding Dimitri as well.

I agree rooting around in dpkg is bad form. I don't *like* this fix, and
I'll be ecstatic if I can chop (most of) it out in future.

So I guess the question is: how long until the kernel folk can implement
the dpkg-divert + linux-version changes, and depending on that answer,
is it worth SRU'ing this in the meantime given the issue has the
potential to break apt upgrades on affected platforms?