Repository navigation
Add support for the native bootc composefs aboot support - #2797
Conversation
This supports parsing the new `Type` field from from `bootc container inspect` and propagates to BootcDistro, BbootcDiskImage and RawBootcImage. Signed-off-by: Alexander Larsson <alexl@redhat.com>
Aboot images contain their kernel, initramfs and command line in a partition payload, rather than a /boot filesystem layout. Select the composefs backend for aboot images, omit install-time kernel arguments, and skip post-install customizations that mount an OSTree deployment. Disable automatic XBOOTLDR creation and select UEFI boot when the image requests the ukiboot bootloader. For firmware-managed boot with bootloader=none, allow installation without an ESP. Relax both mount-generation and stage-validation checks while retaining the requirement for a root mount. Also, report errors if disk custimization is used with aboot, we don't currently support this. Note that aboot images still return true for unifiedKernel, but although there is a new boot_type field that can contain "uki", we use the old one to remain compatible with older bootc version that don't set boot_type. Add tests for composefs selection, omission of external kernel arguments, and manifest generation without an ESP. Partition layout and initial payload placement continue to come from disk.yaml. Assisted-by: AI Signed-off-by: Alexander Larsson <alexl@redhat.com>
|
I'd love to have a full end-to-end build-and-boot test for these scenarios. Or at least a build-only test if booting these in CI is hard. We should talk about getting some base containers into our test pipelines for these images. |
|
It's possible at least for the ukiboot version of aboot to build and boot this with just a Dockerfile. However it needs a release of bootc in fedora so we can use it in CI first. |
|
Seconded that we need a build+boot test for this scenario after it's available in rawhide. Do you know when that release will happen? |
|
@supakeen It seems to be in the 1.7.3 bootc release happening now (bootc-dev/bootc#2596), I'm not sure how long until that is in fedora, but probably not that long. After that I can produce a fedora-only Dockerfile to test this. I'm not sure what is the best way to do that though, we probably don't want to rely on a constantly changing fedora repo upstream that can break in all sorts of other ways. Does image-builder use frozen upstream repos, or pre-built base images or something like that for the tests? |
We have repository snapshots that we use for CI that we sync regularly, so that any failures show up in snapshot updates instead of suddenly in a PR (or on |
|
@supakeen Ok, so once this works in fedora we can sync that and create an integration test. |
This support was added in: bootc-dev/bootc#2490