Skip to content

WIP: Build via Containerfile and derive from fedora-bootc #3348

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 1 commit into
base: testing-devel
Choose a base branch
from

Conversation

jlebon
Copy link
Member

@jlebon jlebon commented Feb 3, 2025

This builds Fedora CoreOS using a Containerfile. It uses the FROM scratch flow to do a base compose.

This is structured in a way that we can build FCOS using both podman build and cosa build. This allows us to make the cutover much smoother. So then, we could turn this on in e.g. rawhide first and let it percolate down.

All the heavy lifting is done in the build-rootfs script. The idea is that this script is shared by both FCOS and RHCOS. Random notes:

  1. It's in Python. This is fine, because the builder image is separate from the target rootfs. The bootc-base-imagectl script itself is in Python and so can only be used from the :standard image.
  2. Packages are extracted from the manifest, and fed to bootc-base-imagectl (see
    https://gitlab.com/fedora/bootc/base-images/-/merge_requests/178) so it's part of a single compose.
  3. We keep respecting the in-git lockfiles. In the future, how lockfiles work will change (see discussions in Build FCOS using podman build fedora-coreos-tracker#1861).
  4. What you see overall is a lot of cosa-isms and rpm-ostree-isms being lifted and carried right into the build script. Things like overlays, versioning, postprocessing, os-release mutating, etc...

Rechunking is expected to be done as a secondary step. Once we have containers/buildah#5952, we can inline it back into the Containerfile.


Requires:

@jlebon
Copy link
Member Author

jlebon commented Feb 3, 2025

This is still in the early phase. It doesn't work yet.

Also note we're using tier-1 for now since there's no tier-x image available yet (https://gitlab.com/fedora/bootc/base-images/-/issues/25).

Edit: now using a tier-x image I built myself.

@jlebon
Copy link
Member Author

jlebon commented Feb 7, 2025

OK cool, got a successful build with this and coreos/rpm-ostree#5274 which I can even rebase to and boot successfully. We're not rebuilding the initramfs yet nor adding overlays. Those shouldn't be hard though.

@jlebon
Copy link
Member Author

jlebon commented May 20, 2025

Updated this now and updated the PR description with more details! Still working on it (notably, going over preliminary diffs between a cosa-built tree and this).

This builds Fedora CoreOS using a
Containerfile. It uses the [FROM scratch
flow](https://docs.fedoraproject.org/en-US/bootc/building-from-scratch/)
to do a base compose.

This is structured in a way that we can build FCOS using _both_ `podman
build` _and_ `cosa build`. This allows us to make the cutover much
smoother. So then, we could turn this on in e.g. rawhide first and let
it percolate down.

All the heavy lifting is done in the `build-rootfs` script. The idea is
that this script is shared by both FCOS and RHCOS. Random notes:
1. It's in Python. This is fine, because the builder image is separate
   from the target rootfs. The `bootc-base-imagectl` script itself is in
   Python and so can only be used from the `:standard` image.
2. Packages are extracted from the manifest,
   and fed to `bootc-base-imagectl` (see
   https://gitlab.com/fedora/bootc/base-images/-/merge_requests/178) so
   it's part of a single compose.
3. We keep respecting the in-git lockfiles. In the
   future, how lockfiles work will change (see discussions in
   coreos/fedora-coreos-tracker#1861).
4. What you see overall is a lot of cosa-isms and rpm-ostree-isms being
   lifted and carried right into the build script. Things like overlays,
   versioning, postprocessing, os-release mutating, etc...

Rechunking is expected to be done as a secondary step. Once we have
containers/buildah#5952, we can inline it back
into the Containerfile.
Copy link
Member

@cgwalters cgwalters left a comment

Choose a reason for hiding this comment

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

Looks generally sane to me!

# This file contains defaults for image.yaml

bootfs: "ext4"
rootfs: "xfs"
Copy link
Member

Choose a reason for hiding this comment

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

Can you also link here osbuild/bootc-image-builder#932

# # XXX: for hacking
COPY rpm-ostree /usr/bin/
COPY bootc-base-imagectl /usr/libexec/
RUN --mount=type=cache,rw,id=cache,target=/cache \
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
RUN --mount=type=cache,rw,id=cache,target=/cache \
RUN --mount=type=cache,rw,id=coreos-build-cache,target=/cache \

Copy link
Member

Choose a reason for hiding this comment

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

suggestion.. to reduce confusion, since this is coreos specific for now, rename to coreos-build-rootfs.

Comment on lines +64 to +65
argsfile.write("--install\n")
argsfile.write(f"{pkg}\n")
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
argsfile.write("--install\n")
argsfile.write(f"{pkg}\n")
argsfile.write(f"--install\n{pkg}\n")

or would argsfile.write(f"--install={pkg}\n") work?

Comment on lines +159 to +161
# inject live/ bits
target_path = os.path.join(rootfs, 'usr/share/coreos-assembler/live')
shutil.copytree(os.path.join(CONTEXTDIR, "live"), target_path)
Copy link
Member

Choose a reason for hiding this comment

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

I guess we could put this in a proper overlay to not have to special case this.

@@ -102,6 +100,26 @@ postprocess:
ConditionPathExists=
EOF

# sudo prefers its config files to be mode 440, and some security scanners
# complain if /etc/sudoers.d files are world-readable.
# https://bugzilla.redhat.com/show_bug.cgi?id=1981979
Copy link
Member

Choose a reason for hiding this comment

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

Should we mention what "overlay" this is from?

set -xeuo pipefail
ln -sf multi-user.target /usr/lib/systemd/system/default.target

- |
Copy link
Member

Choose a reason for hiding this comment

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

Would be nice to have a comment for this block.

set -xeuo pipefail
if [ -f /run/.containerenv ]; then
grep sudo /usr/lib/group >> /etc/group
fi
Copy link
Member

Choose a reason for hiding this comment

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

Should we add these three new postprocess scripts in a manifest that is shared with RHCOS/SCOS?

if [ -f /run/.containerenv ]; then
conf_file=/etc/rpm-ostreed.conf
fi

Copy link
Member

Choose a reason for hiding this comment

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

Maybe delete this newline

@@ -134,13 +144,27 @@ postprocess:
done
done

- |
Copy link
Member

Choose a reason for hiding this comment

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

Would be nice to have a comment for this block.

rm -f /etc/alternatives/*-man

# This replicates `etc-group-members` above but for the container-native case.
# We can nuke that other one once that's the only path we support.
Copy link
Member

Choose a reason for hiding this comment

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

The comment for the other one is more comprehensive :)

@dustymabe
Copy link
Member

Havne't had a chance to test this out yet. Some comments in the mean time.

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.

3 participants