Comment 15 for bug 2007827

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!