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)

[kfox1111]

Has there been any progress on this? interested in simplifying bootc based images on rpi's. Need some way of copying the rpi boot bits onto the boot partiion when its mounted.

[cgwalters]

To be clear in this there's two very different cases, though ideally we make them one:

• Content shipped in an RPM with files in /boot that are present in the initial base image build where bootupctl backend generate-update-payload is invoked
• Content added after

So the most ideal thing here would be to again define a generic/extensible/pluggable payload mechanism, and then the cases fold together.

[HuijingHei]

Maybe can teach bootc container lint be aware the files under /boot, then teach bootupd to install them.
But not sure if bootupctl update should concern about this, as we now only cares about /boot/efi/EFI that comes from grub2/shim.

[cgwalters]

For the bcm2711-firmware I'd propose a flow like this:

cd $(mktemp -d)
dnf download bcm2711-firmware
rpm2cpio bcm-2711-firmware*.rpm | cpio -div
bootupctl backend add-esp-content --timestamp <ts> --version $(rpm -q bcm2711-firmware) ./boot/efi
```

Crucially we don't need a new payload type I think, the `EFI` one is already a rollup of all files in the ESP and that's all we need.

The `add-esp-content` command would extend what appears in the existing `/usr/lib/bootupd/updates/EFI{,.json}`

[cgwalters]

One might wonder: "Why is this any harder than RUN dnf install bcm2711-firmware"?

The answer is basically that the rationale for bootupd is that we don't have a mechanism to transactionally update the bootloaders (again see the README.md) and in general it makes sense to split management of the bootloader state from management of the operating system.
They are different things.

dnf does no such thing of course today but it doesn't have transactional updates and rollbacks so it doesn't matter.

Related to this, bootupd puts all the content of bootloader state in /usr, and only copies it into /boot/efi when bootupctl update is invoked. That's why bootupd has this whole concept of "payloads".

Today, bootc does not automatically run bootupd, but of course some operating systems are shipping the example bootloader-update.service from this repo.