Skip to content

osbuild: use bootc install to deploy the container#4224

Merged
dustymabe merged 9 commits intocoreos:mainfrom
jbtrystram:osbuild-bootc-install-fs
Apr 9, 2026
Merged

osbuild: use bootc install to deploy the container#4224
dustymabe merged 9 commits intocoreos:mainfrom
jbtrystram:osbuild-bootc-install-fs

Conversation

@jbtrystram
Copy link
Copy Markdown
Member

Instead of deploying the container to the tree then copy all the contents to the disk image, use bootc to directly manage the installation to the target filesystems.

Right now this requires to use the image as the buildroot so this requires python (for osbuild). This is tracked in [1].

[1] bootc-dev/bootc#1410 Requires osbuild/osbuild#2149

@openshift-ci
Copy link
Copy Markdown

openshift-ci Bot commented Jul 17, 2025

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

The pull request introduces changes to use bootc install to deploy the container, which simplifies the image build process. There are a few critical issues in the YAML manifest related to copy-paste errors that lead to incorrect configurations for the 4k image builds and missing options for loopback devices. These issues need to be addressed.

Comment thread src/osbuild-manifests/coreos.osbuild.x86_64.mpp.yaml Outdated
Comment thread src/osbuild-manifests/coreos.osbuild.x86_64.mpp.yaml Outdated
Comment thread src/osbuild-manifests/coreos.osbuild.x86_64.mpp.yaml Outdated
Comment thread src/osbuild-manifests/coreos.osbuild.x86_64.mpp.yaml Outdated
Comment thread src/osbuild-manifests/coreos.osbuild.x86_64.mpp.yaml Outdated
Comment thread src/osbuild-manifests/coreos.osbuild.x86_64.mpp.yaml Outdated
Comment thread build.sh Outdated
Comment thread build.sh Outdated
@dustymabe
Copy link
Copy Markdown
Member

dustymabe commented Jul 17, 2025

I switched the CI on this to run against rawhide (contains python) so we could actually test the change.

@dustymabe
Copy link
Copy Markdown
Member

A few diffs picked up by cosa diff --metal from #4226

cosa-diff-metal.txt

We should probably profile each diff (maybe in coreos/fedora-coreos-tracker#1827) and evaluate whether it's a change we want to make or not.

@dustymabe
Copy link
Copy Markdown
Member

I can't get a built qemu image to boot. I suspect probably the root= and boot= UUIDs added on the kernel command line?

@jbtrystram
Copy link
Copy Markdown
Member Author

I can't get a built qemu image to boot. I suspect probably the root= and boot= UUIDs added on the kernel command line?

do you mind sharing more logs ? What I am getting locally is ignition failing on coreos/fedora-coreos-tracker#1250

@dustymabe
Copy link
Copy Markdown
Member

Ahh. I see that too now:

[    4.726843] ignition[875]: Ignition failed: failed to create users/groups: failed to configure users: failed to create user "core": exit status 10: Cmd: "useradd" "--root" "/sysroot" "--create-home" "--password" "*" "--comment" "CoreOS Admin" "--groups" "adm,sudo,systemd-journal,wheel" "core" Stdout: "" Stderr: "useradd: cannot lock /etc/group; try again later.\n"

@jbtrystram

This comment was marked as outdated.

@jbtrystram

This comment was marked as outdated.

@jbtrystram
Copy link
Copy Markdown
Member Author

I can't get a built qemu image to boot. I suspect probably the root= and boot= UUIDs added on the kernel command line?

looks like removing those make the boot process go further (ignition completes), and out of the initramfs but fail to mount the boot partition.

@jbtrystram
Copy link
Copy Markdown
Member Author

Blocked on bootc-dev/bootc#1441

@jbtrystram
Copy link
Copy Markdown
Member Author

ok this works with the following PRs :

for the bootc PR, it can be built then added into the image through overrides/rootfs. Make sure to build rawhide.

Comment thread src/osbuild-manifests/coreos.osbuild.x86_64.mpp.yaml Outdated
@jbtrystram
Copy link
Copy Markdown
Member Author

follow-up : either find a way to get the boot components inside cosa, or change the bootc code to call bootupd from the deployed root . I think the latter is preferable.
I filed bootc-dev/bootc#1455

@jbtrystram
Copy link
Copy Markdown
Member Author

jbtrystram commented Jul 29, 2025

follow-up : either find a way to get the boot components inside cosa, or change the bootc code to call bootupd from the deployed root . I think the latter is preferable. I filed bootc-dev/bootc#1455

Made bootc-dev/bootc#1460
With this, we no longer require to use the container as the buildroot, cosa works, so we could do that on all streams.

@jbtrystram jbtrystram force-pushed the osbuild-bootc-install-fs branch 4 times, most recently from bb4270f to 310bd60 Compare July 30, 2025 07:38
@jbtrystram
Copy link
Copy Markdown
Member Author

Alright, marking this as ready for review as all the bits are in place.
I guess i need to update the osbuild manifest or the other arches as well, but I'll do that after a review to reduce the amount of back and forth.

This will need a release of bootc.

@jbtrystram jbtrystram marked this pull request as ready for review July 30, 2025 07:44
Copy link
Copy Markdown
Member

@dustymabe dustymabe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some comments.

I think there are a few things we need to iron out before we can really move forward with this:

  1. supporting both old and new paths at the same time

Do we need to? Usually when we make a change this large we roll it out slowly, which means we have to support both ways for some time.

This PR is ignoring that fact, but TBH looking at OSBuild configs that support both would be pretty intimidating, so I'm not excited about trying to do that either. I'd be interested in @jlebon or @travier's thoughts.

  1. We need to make sure any/every diff that exists between images generated this way and the old way are considered and acknowleged as acceptable before we'd make this change.

Comment thread src/cmd-osbuild Outdated
Comment thread src/osbuild-manifests/coreos.osbuild.x86_64.mpp.yaml Outdated
Comment thread src/osbuild-manifests/coreos.osbuild.x86_64.mpp.yaml Outdated
Comment thread src/osbuild-manifests/coreos.osbuild.x86_64.mpp.yaml Outdated
Comment thread src/osbuild-manifests/coreos.osbuild.x86_64.mpp.yaml Outdated
Comment thread src/osbuild-manifests/coreos.osbuild.x86_64.mpp.yaml Outdated
Comment thread src/osbuild-manifests/coreos.osbuild.x86_64.mpp.yaml Outdated
Comment thread src/osbuild-manifests/coreos.osbuild.x86_64.mpp.yaml Outdated
Comment thread src/osbuild-manifests/coreos.osbuild.x86_64.mpp.yaml Outdated
Comment thread src/osbuild-manifests/coreos.osbuild.x86_64.mpp.yaml Outdated
@jbtrystram
Copy link
Copy Markdown
Member Author

Ok I just built 43.20260301.3.1 with this to confirm zincati is happy updating.
So I had to change the /usr/share/coreos-assembler/image.json in a Containerfile, then import that image, then run cosa osbuild qemu then spin up cinncinati serving my new image digest in the graph otherwise Zincati was not able to find itself in the graph, but it works :

 journalctl -u zincati -f
Apr 07 15:10:07 cosa-devsh zincati[2249]: [INFO  zincati::cli::agent] starting update agent (zincati 0.0.32)
Apr 07 15:10:07 cosa-devsh zincati[2249]: [INFO  zincati::cincinnati] Cincinnati service: http://10.0.2.2:8080
Apr 07 15:10:07 cosa-devsh zincati[2249]: [INFO  zincati::cli::agent] agent running on node 'b8630492e9a148ebb1159acd79a13dbe', in update group 'default'
Apr 07 15:10:07 cosa-devsh zincati[2249]: [INFO  zincati::update_agent::actor] registering as the update driver for rpm-ostree
Apr 07 15:10:07 cosa-devsh zincati[2249]: [INFO  zincati::update_agent::actor] initialization complete, auto-updates logic enabled
Apr 07 15:10:07 cosa-devsh zincati[2249]: [INFO  zincati::strategy] update strategy: immediate
Apr 07 15:10:07 cosa-devsh zincati[2249]: [INFO  zincati::update_agent::actor] reached steady state, periodically polling for updates
Apr 07 15:10:07 cosa-devsh systemd[1]: Started zincati.service - Zincati Update Agent.
Apr 07 15:10:07 cosa-devsh zincati[2249]: [INFO  zincati::cincinnati] current release detected as not a dead-end
Apr 07 15:10:07 cosa-devsh zincati[2249]: [INFO  zincati::update_agent::actor] target release '43.20260316.3.1' selected, proceeding to stage it
Apr 07 15:10:34 cosa-devsh zincati[2249]: [ERROR zincati::update_agent::actor] failed to stage deployment: rpm-ostree deploy failed:
Apr 07 15:10:34 cosa-devsh zincati[2249]:     error: While checking against deployment timestamp: Upgrade target revision '9c75fe338f4381dd0fdd73b3bcc9f441b1143ba525932a957b8e1d53894bc851' with timestamp 'Tue Mar 31 14:31:58 2026' is chronologically older than current revision '78e3b91234bfc480220daa09ae4e5de7ce48928e543e11cb24bcb379acb4c219' with timestamp 'Tue Apr  7 09:28:52 2026'; use --allow-downgrade to permit

the failure is expected here, that's because I just built the image.

@jbtrystram
Copy link
Copy Markdown
Member Author

jbtrystram commented Apr 8, 2026

Filed bootc-dev/bootc#2130 for the /ostree/bootc/storage/overlay/backingFsBlockDev

@jbtrystram jbtrystram force-pushed the osbuild-bootc-install-fs branch from e39271a to c880bc3 Compare April 8, 2026 10:05
@travier
Copy link
Copy Markdown
Member

travier commented Apr 8, 2026

This looks reasonable to me. I found #4526 while reviewing this one and it will likely conflict.

travier
travier previously approved these changes Apr 8, 2026
Copy link
Copy Markdown
Member

@travier travier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved but let's wait for the sync with Dusty before merging.

@jbtrystram
Copy link
Copy Markdown
Member Author

Comment thread src/cmd-osbuild Outdated
Comment thread src/cmd-osbuild Outdated
Comment thread src/cmd-osbuild
Comment thread src/osbuild-manifests/build.common.ipp.yaml
@dustymabe
Copy link
Copy Markdown
Member

Filed bootc-dev/bootc#2130 for the /ostree/bootc/storage/overlay/backingFsBlockDev

Thanks. Can you add a commit here with the following patch (and also link to bootc-dev/bootc#2130 in a comment).

diff --git a/src/cmd-diff b/src/cmd-diff
index 5424fa497..78051e544 100755
--- a/src/cmd-diff
+++ b/src/cmd-diff
@@ -568,6 +568,7 @@ def diff_metal_helper(diff_from, diff_to):
                 # in filenames with XXXXXXXXXXXXXXXX so that we can get a real diff between
                 # two of the same files in different builds.
                 runcmd(['tar', '-xf', tmp_tar.name, '-C', diff_dir,
+                        '--exclude', '*backingFsBlockDev',
                         '--transform', 's|[[:xdigit:]]{64}|XXXXXXXXXXXXXXXX|gx'])
 
         except Exception as e:

@jbtrystram
Copy link
Copy Markdown
Member Author

Filed bootc-dev/bootc#2130 for the /ostree/bootc/storage/overlay/backingFsBlockDev

Thanks. Can you add a commit here with the following patch (and also link to bootc-dev/bootc#2130 in a comment).

Added a commit.

@jbtrystram jbtrystram force-pushed the osbuild-bootc-install-fs branch from 1fb0d0b to 9acecf5 Compare April 9, 2026 09:00
@jbtrystram
Copy link
Copy Markdown
Member Author

The last push here is purely cosmetic, I addressed all the review comments, a build in jenkins passed all the tests : https://jenkins-fedora-coreos-pipeline.apps.ocp.stg.fedoraproject.org/job/build/140/console

Let's merge this !

jbtrystram added a commit to jbtrystram/fedora-coreos-config that referenced this pull request Apr 9, 2026
Introduce a new overlay to ship configuration files for bootc and
image-builder. These file are sourced from the container during
`bootc install to-filesystem`.
We can also use this later to ship other bits as we make the container
more and more the source of truth, e.g. the partition table definition.

This is prep work for [1]

[1] coreos/fedora-coreos-tracker#1827

See also coreos/coreos-assembler#4224
@jbtrystram jbtrystram enabled auto-merge (rebase) April 9, 2026 11:36
The log disk usage message comming every 10 seconds is quite noisy,
hide it when we are in a shell in osbuild.

I aslo added a couple of helpful tips in comments given by @dustymabe
to work with osbuild.
This adds raw-{,4k}-image-bootc manifests that are alternative versions
of the raw-{,4k}-image manifests. This will allow to keep the legacy build
path with a new path that leverages bootc install to filesystem.

In this mode instead of deploying the container to the tree then copy all
the contents to the disk image, use bootc to directly manage the installation
to the target filesystems.

We can conditionalize this until we are confident to roll this to all streams
or move to image-builder.

Requires:
bootc-dev/bootc#1460
bootc-dev/bootc#1451
osbuild/osbuild#2149
osbuild/osbuild#2152
bootc-dev/bootc#1978
bootc-dev/bootc#1909
Create symlinks to the aleph file created by bootc so our tests and
tooling find the aleph at the expected path.

Note that when moving to image-build we will likely move this to
an overlay in the config, that's way easier than having to wire up a
blueprint option to allow creating arbitrary symlinks.
By default bootc calls bootups with the `--write-uuid` option that
write a stamp file with the boot partition UUID in the UEFI parition.
We want to restamp those UUID at first boot, so adding this option make
sure bootc does not pass that flag to bootupd.

See bootc-dev/bootc#1978
Bootc is looking for the prepare-root config file in the buildroot
environnement because the main assumption is that it's run from the
target container.
However, in osbuild, it's run from te buildroot, because podman inside
bwrap (inside supermin in our case) causes issues.
It's fine for RHCOS and SCOS where we use the target container as the
buildroot but we cannot do that for FCOS because we require python in
the buildroot.

For now, insert a prepare-root file in the supermin VM (use as the
buildroot for osbuild) until either :
- bootc learn to look into the container for it [1]
- we ship python in our images and can use them as buildroot.

Another approach would be to layer python and the osbuild dependencies
on top of our image and use that as the buildroot, but that would create
room for packages drift (what was in the repos at build time?). At least
using COSA it's easier to keep track of versions.

[1] bootc-dev/bootc#1410
Tell bootc to enforce that `/etc/containers/policy.json` include a default
policy that verify our images signature.

When moving to image-builder, this config can be moved into the container itself
but as long as we are using osbuild manually we have to carry this in the buildroot.
TODO: uncomment this when bootc-dev/bootc#2116
is merged and released

See coreos/fedora-coreos-config#4093 (comment)
Until we are able to tune this through and install config file, let's
always pass the flag at the osbuild label.

This can be dropped once we have bootc-dev/bootc#2116
in bootc.
Add a bootc install config file[1] to set ostree repo options so we inject
the `grub_users` config on non-default entries.

[1] https://bootc-dev.github.io/bootc/man/bootc-install-config.5.html#ostree

See bootc-dev/bootc#1909
bootc install to-filesystem currently leave a leftover blockdev file
in the resulting image.
This is causing tar to fail on a permission denied error, so let's filter
it out for now.

This is tracked in bootc-dev/bootc#2130
@dustymabe
Copy link
Copy Markdown
Member

Since there is a merge conflict now (with the merge of #4526) I'll rebase this.

@dustymabe dustymabe force-pushed the osbuild-bootc-install-fs branch from 9acecf5 to b29f433 Compare April 9, 2026 17:24
Copy link
Copy Markdown
Member

@dustymabe dustymabe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@dustymabe dustymabe disabled auto-merge April 9, 2026 19:58
@dustymabe dustymabe merged commit aaf1bb1 into coreos:main Apr 9, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants