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?