[Bug 2007827] Re: [SRU] flash-kernel failure when upgrading f-k and kernel in the same cycle

[Dave Jones]

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?

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to flash-kernel in Ubuntu.
https://bugs.launchpad.net/bugs/2007827

Title:
  [SRU] flash-kernel failure when upgrading f-k and kernel in the same
  cycle

Status in flash-kernel package in Ubuntu:
  Fix Released
Status in flash-kernel source package in Focal:
  New
Status in flash-kernel source package in Jammy:
  New
Status in flash-kernel source package in Kinetic:
  Incomplete
Status in flash-kernel source package in Lunar:
  Fix Released

Bug description:
  [Impact]
  In version 3.104ubuntu15 of flash-kernel, when both f-k and the kernel are upgraded in the same cycle, depending on the ordering of dpkg trigger execution, f-k may find the content of /boot "inconsistent" causing it to fail and return error exit status 1.

  Erorr message:
  Processing triggers for man-db (2.10.2-1) ...
  Processing triggers for flash-kernel (3.104ubuntu15) ...
  flash-kernel: installing version 5.15.0-1018-xilinx-zynqmp
  Initrd required for FIT method
  dpkg: error processing package flash-kernel (--configure):
   installed flash-kernel package post-installation script subprocess returned error exit status 1
  Processing triggers for linux-image-5.15.0-1018-xilinx-zynqmp (5.15.0-1018.20) ...
  /etc/kernel/postinst.d/initramfs-tools:
  update-initramfs: Generating /boot/initrd.img-5.15.0-1018-xilinx-zynqmp

  flash-kernel gets the latest kernel version by "linux-version list".
  When flash-kernel was triggered to generate fitimage, the kernel version is "5.15.0-1018" and the initrd for it wasn't ready. So, flash-kernel failed to generate the fitimage.

  A subsequent run of "apt install -f" fixed things because, by that
  point, the kernel's own trigger had executed, ensuring that update-
  initramfs had been run. In the case that f-k is run "prematurely" and
  finds itself in this situation (/boot/kernel-$[ver} exists, but
  /boot/initrd-${ver}) doesn't), it should probably bail out silently
  under the assumption that whatever is responsible for it will rectify
  the situation and trigger f-k again (as happens in the kernel postinst
  hooks).

  [Test Case]
  1. Flash an old image (with an out of date kernel and flash-kernel)
  2. sudo apt-get update
  3. sudo apt install flash-kernel with the fix and linux packages
  4. Upgrade should proceed without issue

  [Regression Potential]
  As with the previous flash-kernel uploads, it is possible that a breakage in the changed code can lead to issues with upgrading kernels (due to f-k being executed via a trigger at the end) or with Xilinx devices in the field not upgrading correctly. I will test all the changes extensively though.

  Related issues:
  LP: #1861292 flash-kernel failure during kernel upgrade

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+bug/2007827/+subscriptions