2.1 KiB
Executable file
Developing bootupd
Currently the focus is Fedora CoreOS.
You can use the normal Rust tools to build and run the unit tests:
cargo build and cargo test
For real e2e testing, use e.g.
export COSA_DIR=/path/to/fcos
cosa build-fast
kola run -E $(pwd) --qemu-image fastbuild-fedora-coreos-bootupd-qemu.qcow2 --qemu-firmware uefi ext.bootupd.*
See also the coreos-assembler docs.
Building With Containers
There's a reference Dockerfile that builds on CentOS Stream bootc.
Integrating bootupd into a distribution/OS
Today, bootupd only really works on systems that use RPMs and ostree. (Which usually means rpm-ostree, but not strictly necessarily)
Many bootupd developers (and current CI flows) target Fedora CoreOS and derivatives, so it can be used as a "reference" for integration.
There's two parts to integration:
Generating an update payload
Bootupd's concept of an "update payload" needs to be generated as
part of an OS image (e.g. ostree commit).
A good reference for this is
88af117d1d/manifests/bootupd.yaml (L12)
Specifically, you'll need to invoke
bootupctl backend generate-update-metadata / as part of update payload generation.
This scrapes metadata (e.g. RPM versions) about shim/grub and puts them along with
their component files in /usr/lib/bootupd/updates/.
Installing to generated disk images
In order to correctly manage updates, bootupd also needs to be responsible
for laying out files in initial disk images. A good reference for this is
93efb63dcb/src/create_disk.sh (L401)
Specifically, you'll need to invoke
/usr/bin/bootupctl backend install --src-root /path/to/ostree/deploy /sysroot
where the first path is an ostree deployment root, and the second is the physical
root partition.
This will e.g. inject the initial files into the mounted EFI system partition.