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

[Dave Jones]

I'll try and explain my understanding of the differences between GRUB-
based (x86) systems and flash-kernel systems (ARM, RISCV, x86 using
u-boot, etc.), but I admit my knowledge of the GRUB side is considerably
less than the flash-kernel side:

On all systems, the kernel packaging installs the kernel (and its
device-trees, if they exist) into /boot, and initramfs-tools generates
the initrd in /boot.

On GRUB-based systems, /boot may be part of the root partition (when
root is not encrypted), or it may be its own partition (when root is
encrypted) but in either case it's *typically* an ext-based file-system
(ext2, ext4, etc). No further copying of the kernel or initrd is
required.

On flash-kernel systems, /boot is always part of the root partition.
It's "just another directory". The kernel or initrd then needs copying /
flashing to some other location.

On GRUB-based systems, the boot (whether BIOS or EFI based) will
eventually reach a GRUB stage which understands how to read the ext-
based file-system, from where it'll load the kernel and initrd and
proceed from there.

On flash-kernel systems, the bootloader (u-boot, pi-boot, aboot, etc.)
is typically configured only to read FAT (some of these bootloaders
*can* be configured to read ext-fs but aren't, usually due to
performance / stability concerns). Hence, flash-kernel is called to copy
artefacts from /boot to wherever they're required (some FAT file-system,
or perhaps an EEPROM block).

Hence, on GRUB-based systems, there need not be a guard against the
initrd not being generated before GRUB is updated. Even if the GRUB
config is generated before the initrd exists, it doesn't matter because
it will by the time we next boot (and the config just "points at" the
file under /boot). However, on flash-kernel systems, the initrd under
/boot is being actively transferred elsewhere and therefore it *does*
matter that it exists prior to f-k being called.

At least, that's my understanding!

-- 
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