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.
The systemd firstboot process does several things, but notably
it runs a preset process. This means that basically a plain
`RUN systemctl enable foo` won't work unless you *also* write
a preset file for it, and no one will know to do that.
Today it's built as a module for Fedora derivatives, but
it's a relatively small kmod.
In particular I want to be able to use a virtiofs root as
a bootstrap mechanism to generate disk images in a situation
where we can't do nested containers, but we do have `/dev/kvm` -
which is the setup we have in e.g. OpenShift Prow on `build02`
with nested virt.
First, we're still in a situation where bib doesn't work with c9s.
Let's link to the existing docs for using `bootc install to-disk`
which *does* work (and fixes multiple other bugs at the same time too).
Second: Let's document using systemd credentials to inject a root
SSH key, because this works across every image we ship where
one can inject SMBIOS bits. (But notably this doesn't work in
most production IaaS virt systems like KubeVirt, AWS etc. which
gets into cloud agents).
Right now we have an "allowlist" effectively for our dracut modules
because we specify a configuration in `/usr/lib/dracut/dracut.conf.d`
which seems to turn off autodetection.
Add in lvm which we definitely want to support.
Signed-off-by: Colin Walters <walters@verbum.org>
I was a bit confused into thinking our `-dev` images had
`root.transient` on, but they don't quite right now because
we don't regenerate the initramfs after installing the updated
ostree in that image.
However, because bootc-image-builder today is throwing away
the immutable bit on `/` (a different bug, see
https://github.com/ostreedev/ostree/pull/3094 ) we actually...
amazingly get a very similar effect in practice!
Anyways, let's go ahead and describe filesystem state here.
There is some overlap with `install.md`, but that doc is all about
how to just get started.
This doc aims to cover things that are somewhat different about
the base image we ship here versus just what one might get
from installing the same RPM packages.
The automatic updates being on by default is a big one.
Signed-off-by: Colin Walters <walters@verbum.org>
Colin Walters
