Hopefully eventually this gets rewritten in not-shell-script
and put somewhere saner. For now, avoid failing if people have
trimmed their images.
The growpart problem only comes with bootc-image-builder and
cloud environments anyways, it's not something we hit with
Anaconda installs or `bootc install to-filesystem`, so we can
avoid this.
Closes: https://gitlab.com/fedora/bootc/base-images/-/issues/34
Signed-off-by: Colin Walters <walters@verbum.org>
We will have a better way to make derived container images
that doesn't require having dnf in the base image.
Prep for more minimal and custom images.
Signed-off-by: Colin Walters <walters@verbum.org>
- Make very clear that tier-1 is the default image
- Link to our issue tracker for supportable base image customization
- Note use of `--build-arg=MANIFEST`.
etc.
Signed-off-by: Colin Walters <walters@verbum.org>
It's supported on all architectures now, even if it's
a no-op mostly on s390x today.
But specifically this will ensure we pull in zipl on s390x,
which *is* needed.
Signed-off-by: Colin Walters <walters@verbum.org>
I don't entirely remember what happened here when forking from
CoreOS, but we definitely want toolbox and lsof at least, just
looking at the differences.
While we're here I did readd sos, but in another section.
Signed-off-by: Colin Walters <walters@verbum.org>
This service is a backfill for lack of a better option
as a baseline to run in cloud/virt environments:
- Without cloud-init
- Even with cloud-init, as it doesn't yet support growing
on ostree/composefs
Signed-off-by: Colin Walters <walters@verbum.org>
- The centos-stream9 one was removing the `.repo` files from
the buildcontext, which is just wrong; we don't want to change
the input git repo
- Use WORKDIR /src to simplify things
When we went back to the "one big image" model we simplified
things to just `centos-bootc.yaml`. But since stream10 is
here, and I think we do want to revisit having smaller images,
let's rename it back.
Signed-off-by: Colin Walters <walters@verbum.org>
I noticed we weren't getting updates and I think the
core problem here is renovate was only triggering on
the devel compose. But we just "floated" to whatever
was found in the production compose as a base.
Also we had a random copr.
Drop that stuff, and just pin on the production compose.
Right now, the relationship between this image and bootc-image-builder
is "floating". However, we may want the ability to more
strictly bind the two in the future.
With this, the bootc image links out to the recommended diskimage
builder container, so automated tooling can find it instead
of hardcoding it.
Signed-off-by: Colin Walters <walters@verbum.org>
In order to streamline the focus, let's drop fedora-bootc:eln.
- We want to be moving container builds into upstream distributions anyways
- Building two containers from one git repository is awkward in Tekton
This is a small but notable step towards making the build
process more container native. The rpm-ostree bits
are hidden much more. We use a special trick
specific to podman/buildah to do `FROM oci-archive`
on an oci-archive that was built in a previous image
stage.
This lets us do things not possible in a Containerfile
that is basically about total control over the image
layers:
- Output content-addressed reproducible "chunked" layers
- Choose whether or not to use zstd for layers
See discussion in e.g.
https://github.com/coreos/rpm-ostree/issues/4688
Signed-off-by: Colin Walters <walters@verbum.org>
This is the opposite workaround for
https://github.com/ostreedev/ostree-rs-ext/issues/612
However, we still need to finally make `/opt` a directory
to complete this, which currently wants changes in rpm-ostree.
(Or, we could tweak our build process to inject as a container
afterwards)
This is a relatively small shell script, and was already split out
from cloud-init to support use cases like ours.
systemd-repart is a lot nicer but it isn't yet designed
for our use case (root is not Discoverable Partition).
Also systemd-repart doesn't handle LVM which this script
tries to support.
(IMO the real solution to stuff like this is either Stratis
or equivalent)
I'd REALLY resisted doing this for a long time, because it
basically "forks" us from c9s. However, the c9s "devel" composes
are down to potentially *once a week* due to storage issues.
This one fast tracks https://kojihub.stream.centos.org/koji/buildinfo?buildID=59709
This ensures that systemd's creation of `/root` works instead
of falling back to what we have in
`/usr/lib/tmpfiles.d/rpm-ostree-0-integration.conf` for
`d /var/roothome 0700 root root -` which in turn ensures
that both the credential values as well as bootc's injection
of a tmpfiles.d snippet for root SSH key works.
https://github.com/containers/bootc/issues/358
Signed-off-by: Colin Walters <walters@verbum.org>
- Split into "local virt" and "production"
- Link to podman-desktop-extension-bootc
- Link to podman-bootc-cli
- Clean up, fix and inline kickstart example for readability
- Include bootc-image-builder in both local and production paths
The `nfs-utils-coreos` package was created to not depend on
Python mainly, but we are way deep into many other packages
that do at this point.
There's some other package that `Requires: nfs-utils` that
this should fix.
Pairs with https://github.com/containers/bootc/pull/299
This is intended to be the new canonical label for bootc-compatible
images, as opposed to the existing `ostree.linux` etc.
Colin Walters