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.

[kfox1111]

Interesting. Could that mechanism write outside of /boot/efi (/boot instead) for rpi firmware updates too?

[cgwalters]

Today, bootc does not automatically run bootupd,

➡ more in bootc-dev/bootc#1354

[say-paul]

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.
EFI refers to /boot/efi/EFI
for rpi 4 firmwares we need to write in /boot/efi instead.

We can have a function:

bootc backend install-to-esp bcm2711-firmware-xx.xx.fc42.aarch

which will do the following:

cd $(mktemp -d)
dnf download bcm2711-firmware
rpm -qpl bcm-2711-firmware*.rpm | grep -q '/boot/efi/' && rpm2cpio bcm-2711-firmware*.rpm | cpio -div || echo "No /boot/efi/ files found in RPM"

update /usr/lib/bootupd/updates/ EFI efi.json
{
"timestamp": "2025-03-27T10:27:15Z",
"version": "grub2-efi-x64-1:2.12-28.fc42.x86_64,shim-x64-15.8-3.x86_64,bcm2711-firmware-xx.xx.fc42.aarch"
}
along with copying the filetree in /usr/lib/bootupd/updates/efi/{esp.files, EFI/{BOOT,centos/rhel/fedora}}.

We can also do things in a esp.json with files in usr/lib/bootupd/updates/efi/ to keep things separated

[cgwalters]

Just to xref @say-paul see also #938 which touches on this a lot, and I think we should land that PR first.

bootc backend install-to-esp bcm2711-firmware-xx.xx.fc42.aarch

Well...I am not a huge fan of making anything bootupd (or bootc) automatically call out to something dnf. At least not without it being pluggable (xref bootc-dev/bootc#1105 (comment) )

Oh oops, I now see I messed up and typed bootc when I meant bootupd in this comment (now edited). We already have the problem in this project (bootupd, not bootc) of some hardcoded dnf references and I was hoping not to add more.

So anyways again this issue strongly relates to #938 in that what I think we can do is support a flow like this:

RUN <<EORUN
set -xeuo pipefail
# *Today* this will write into `/boot/efi`
dnf -y install bcm2711-firmware
bootupctl backend extend-boot-efi

The extend-boot-efi verb would pull content out of /boot/efi and automatically translate it to the (proposed in fedora) new layout of /usr/lib/efi/<name>/<version>/EFI/<contents...>, and then from that we need to translate it into bootupd's current concept of the EFI payload (phew, I know! But I think the proposed new fedora layout is cleaner and we can probably try to migrate our internals to it over time).

[kfox1111]

@cgwalters generally sounds like a good plan to me.

One use case I'm trying to explore is using bootc with a rpi5's with m.2 drives only.

So far the only firmware I know of that works with it is:
https://github.com/worproject/rpi5-uefi

So having some mechanism for dropping that at the root of the boot partition (not /efi) would be very useful, so it can chainload grub.

Would that work with this proposed mechanism, or would that need to be handled some other way?

---

plus 1 for not making new commands depend on dnf. Maybe some wrappers could be provided for various package managers to make that easier, rather then build it into bootupd?