support dynamically extending/adding update payloads

[cgwalters]

See this https://github.com/ondrejbudai/fedora-bootc-raspi/blob/cbff66a8bdb82b6276814765ffdb82c4ec4efa9c/bootupctl-shim#L7

Basically today the bootloader update payload is often part of the base image, but we need to support dynamically extending it with layered image content as well.

---

In the short term, what may suffice is to offer an explicit user-hookable phase that can copy things from the container to /boot as part of bootc install to-filesystem.

[HuijingHei]

Is this something that teach bootupctl to read config for example: /usr/lib/bootc/install/00-firmware.toml

[install.firmware]
type = "bootc-raspi-firmwares"

then it will get install.fimware.type, and find /usr/lib/bootc-raspi-firmwares/, finally copy the files to default directory /boot/efi.

Or maybe make bootc to read the config file and get install.fimware.type, then pass the env to bootupctl ?

Not sure if my understanding is correct. Any suggestions? Thanks!

[cgwalters]

So one thing heavily related to this is today rpm-ostree in "unified core" mode automatically redirects content in /boot to /usr/lib/ostree-boot - so that means the files here:

rpm -ql bcm2711-firmware
/boot/efi/bcm2711-rpi-4-b.dtb
/boot/efi/bcm2711-rpi-400.dtb
/boot/efi/bcm2711-rpi-cm4-io.dtb
/boot/efi/bcm2711-rpi-cm4.dtb
/boot/efi/bcm2711-rpi-cm4s.dtb
/boot/efi/bcm2712-rpi-5-b.dtb
/boot/efi/bcm2712-rpi-cm5-cm4io.dtb
/boot/efi/bcm2712-rpi-cm5-cm5io.dtb
/boot/efi/bcm2712-rpi-cm5l-cm4io.dtb
/boot/efi/bcm2712-rpi-cm5l-cm5io.dtb
/boot/efi/bcm2712d0-rpi-5-b.dtb
/boot/efi/fixup4.dat
/boot/efi/fixup4cd.dat
/boot/efi/fixup4db.dat
/boot/efi/fixup4x.dat
/boot/efi/start4.elf
/boot/efi/start4cd.elf
/boot/efi/start4db.elf
/boot/efi/start4x.elf

But dnf does no such thing, so...one simple way to handle this might actually just be changing bootupctl backend install to be idempotent - in the case where the base image already has an /usr/lib/bootupd/updates/EFI.json we extend (regenerating) it.

In theory though, it would be nicer to represent e.g. shim+grub as a distinct payload from these other blobs?

Doing that though...hmm, I guess the cleanest way would be for shim+grub to explicitly flag themselves as a unit, or we teach bootc to recognize those directly?

[alexlarsson]

For automotive we need more than just put stuff in /boot. For example, if android boot is used, then the boot dir will contain an aboot.img file, and this needs to be written to the boot_a partition. We do ship tools to do the writing, but we need to have a place to hook in callouts to those commands with the right arguments.

[cgwalters]

Yeah, bootupd abstracts today over the (GRUB) MBR/BIOS case which is a dedicated partition.

But this is all hardcoded (in Rust) in this project. Adding more bootloaders here I think wouldn't be hard, and the code was definitely designed to enable it.

But, maybe we could in theory try to rework things such that we have /usr/lib/bootupd/backends with drop-in executables that we fork/exec - in the simplest case of a single bootloader state then bootupd would end up being a really thin wrapper.

(Unfortunately we do need to think about cases like disk images bootable with both grub BIOS as well as UEFI, so there are conceptually two. But OTOH today that case is grub for both, so maybe we could collapse that into just "grub" conceptually and always update both)