Previously, `BootedStorage::new()` unconditionally tried to open
`/sysroot` before checking the environment type. This caused
`bootc status` to fail on non-ostree/composefs systems.
(We did work in containers and we had tests for that; but
the container case is special cased even earlier)
Fixes: https://issues.redhat.com/browse/RHEL-135687
Assisted-by: Claude Code (Opus 4.5)
Signed-off-by: Colin Walters <walters@verbum.org>
Main goal is to reduce signing logic duplication between the systemd-boot
and UKI generation.
However, this quickly snowballed into wanting to actually verify
by providing a custom secure boot keys to bcvk that things worked.
This depends on https://github.com/bootc-dev/bcvk/pull/170
Now as part of that, I ran into what I think are bugs in pesign;
this cuts things back over to using sbsign. I'll file a tracker for that
separately.
Finally as part of this, just remove the TMT example that builds
a sealed image but doesn't actually verify it works - it's already
drifted from what we do outside here. Ultimately what we need
is to shift some of this into the Fedora examples and we just
fetch it here anyways.
Assisted-by: Claude Code (Sonnet 4.5)
Signed-off-by: Colin Walters <walters@verbum.org>
The build-sealed script introduced in PR #1810 referenced
BOOTC_buildroot_base which is only defined in GitHub Actions CI,
causing failures when running 'just build-sealed' manually.
This allows manual execution while maintaining CI compatibility.
Signed-off-by: Wei Shi <wshi@redhat.com>
Part 1: Use bcvk
For local tests, right now testcloud+tmt doesn't support UEFI, see
https://github.com/teemtee/tmt/issues/4203
This is a blocker for us doing more testing with UKIs.
In this patch we switch to provisioning VMs with bcvk, which
fixes this - but beyond that a really compelling thing about
this is that bcvk is *also* designed to be ergonomic and efficient
beyond just being a test runner, with things like virtiofs
mounting of host container storage, etc.
In other words, bcvk is the preferred way to run local virt
with bootc, and this makes our TMT tests use it.
Now a major downside of this though is we're effectively
implementing a new "provisioner" for tmt (bypassing the
existing `virtual`). In the more medium term I think we
want to add `bcvk` as a provisioner option to tmt.
Anyways for now, this works by discovers test plans via `tmt plan ls`,
spawning a separate VM per test, and then using uses tmt's connect
provisioner to run tests targeting these externally provisioned
systems.
Part 2: Rework the Justfile and Dockerfile
This adds `base` and `variant` arguments which are propagated through
the system, and we have a new `variant` for sealed composefs.
The readonly tests now pass with composefs.
Drop the continuous repo tests...as while we could keep
that it's actually a whole *other* entry in this matrix.
Assisted-by: Claude Code (Sonnet 4.5)
Signed-off-by: Colin Walters <walters@verbum.org>
In the future, we may want to "shard" tests across multiple runners,
but as is right now it's basically just adding overhead to copy
the disk image as an artifact across the job.
While we're here, clean things up further to match the general
principle that GHA flows should mostly just be running `just`.
The logic from build.sh to map from strings -> containers though
moves into the GHA for now.
Signed-off-by: Colin Walters <walters@verbum.org>
- Change the install logic to detect UKIs and automatically
enable composefs
- Change the install logic to detect absence of bootupd
and default to installing systemd-boot
- Move sealing bits to the toplevel
- Add Justfile entrypoints
- Add basic end-to-end CI coverage (install + run) using
our integration tests
- Change lints to ignore `/boot/EFI`
Signed-off-by: Colin Walters <walters@verbum.org>
Make builds unprivileged by default and start using bcvk in
our own CI, the same way we expect people to do so locally
now.
Signed-off-by: Colin Walters <walters@verbum.org>
By default bootc will enable fsverity when ext4 is the chosen
filesystem, and we need fsverity to do composefs testing.
Signed-off-by: John Eckersberg <jeckersb@redhat.com>
A key thing for me is that the `Justfile` should be a one-stop
shop for development of the project. It can't have everything but
it should answer the basic questions of "how do I build and test
this project".
This aligns the recently added tmt-on-GHA flow a *bit* more closely
with some of that. Biggest is to use the `just build-integration-test-image` as the canonical
way to build a container image with our testing stuff in it;
which uses our main Dockerfile
Other cleanups:
- Change test script to move into tests/tmt/ as a workaround for
https://github.com/teemtee/tmt/pull/3037#issuecomment-3259585271
- Change the qemu logic to use SMBIOS credentials so we don't
have to carry around both a disk image and a SSH key
- Change qemu to use `-snapshot` so we can reuse disks
- Change the scripts to accept data via argv[1] and not environment
- Drop the hardcoded testing directory and use `target/` as
a generic build artifact dir
Signed-off-by: Colin Walters <walters@verbum.org>
And add a single test which verifies that our internal `reboot`
code actually does what it should (via systemd-run etc.)
This took me way, way too long to do...there were so many missteps
and confusion. First of all, I kept trying to use `systemd.extra-unit`
from https://www.freedesktop.org/software/systemd/man/latest/systemd-debug-generator.html#
but that doesn't exist in stream9.
I spent way too long trying to debug the fact that switching from
`podman run <image> /sbin/init` to `podman run <image> /bin/sh -c '<stuff> && exec /sbin/init`
fails because in the latter case podman's auto-detection fails and
we need to explicitly say `--systemd=always`. In retrospect obvious...but oh well.
On the positive side, I think with some cleanup we could extend this model
and generalize it for "test running in a container with systemd" (with
a lot of cleanup really)
Signed-off-by: Colin Walters <walters@verbum.org>
The previous work here wasn't quite right in a few ways.
Our LSM/SELinux code is a bit complex and under-tested.
Here we:
First, refactor some of the labeling bits so we have a clean
"relabel this file" API.
For the bootc-owned containers-storage we don't want
"recursive create dir and relabel" in the general case - we
need to handle upgrades, where there are definitely
non-directories too.
Hence rework the API to just be a clean recursive
relabeling pass, don't attempt to create anything
on our own.
The install path hence changes to let podman create
the dirs first, then we relabel.
While we're here:
- Rework the recursive traversal to operate on shared
single `&mut` path buffers to avoid a heap alloc per directory.
- Add a `bootc internals relabel` CLI verb that
makes it easy to test this code both interactively
and in integration testing.
- Add a test case
Closes: https://github.com/bootc-dev/bootc/issues/1219
Signed-off-by: Colin Walters <walters@verbum.org>
Running some containers (e.g. mssql) requires the imgstorage labels to
be identical to the /var/lib/containers/storage. So, this code
recursively sets the labels for the bootc storage directory to mimic
/var/lib/containers/storage. This operation is done once, then a
.bootc_labeled file is created to signify the directory was labeled.
This operation could be done anytime the storage is
accessed, i.e. on installation, upgrade, or running a `bootc image`
command.
Signed-off-by: ckyrouac <ckyrouac@redhat.com>
Split this out of the fsverity PR.
We obviously want a `fsck` command. This starts by doing
just two checks:
- A verification of `etc/resolv.conf`; this tests
98995f662b
- Just run `ostree fsck`
But obvious things we should be adding here are:
- Verifying kargs
- Verifying LBIs
etc.
Signed-off-by: Colin Walters <walters@verbum.org>
The previous change here was a no-op for two reasons:
- It's actually usr/etc at this point
- We were operating on the wrong rootfs
Fixes: 57bd0dc983
Signed-off-by: Colin Walters <walters@verbum.org>
One CI run just got a server error fetching the spec from Fedora.
We have a spec here (which I don't like but we do) so use it
to lower CI flakes.
Signed-off-by: Colin Walters <walters@verbum.org>
The format is not as important as what the option *does*. There's
multiple things that can be JSON, but this is specifically
about dynamic progress information.
Signed-off-by: Colin Walters <walters@verbum.org>
We could add a new test case for this, but it's expensive to
do these image push/pull ones so let's just pile onto this one.
Signed-off-by: Colin Walters <walters@verbum.org>
Followup to https://github.com/containers/bootc/pull/977
In chatting with John we had some agreement to statically
enable the `.path` unit by default upstream here since
it's a feature we want to be available by default
so that tooling can react dynamically to changes.
Signed-off-by: Colin Walters <walters@verbum.org>
It looks like the default `column1` became `column0` which
broke this. But really we don't need a table, we just need a list;
and piping to `from csv` was a weird way to go about splitting
lines into a list.
Change the assertion to just expect a list which simplifies
the code.
Signed-off-by: Colin Walters <walters@verbum.org>
Keep the bind mounts in the docs though for now because many
people will be using the current docs with older bootc.
Signed-off-by: Colin Walters <walters@verbum.org>
Solves the second part of https://github.com/containers/bootc/issues/846
The (hidden) image list command now has a `--type` flag to allow users
to list only logical images, only host images, or all images.
Also the command has been adjusted so that it can run even when not
booted off of a bootc system. In that case, it will only list logical
images. If a user tries to list host images without a booted system, an
error will be thrown.
The command also has a `--format` flag to allow users to choose between
a human-readable table format and a JSON format.
Signed-off-by: Omer Tuchfeld <omer@tuchfeld.dev>
Previously, the check to verify install to-filesystem is being run
within a container happened fairly late in prepare_install. This moves
the check up before some of the other container specific checks. Now,
the error should occur when trying a basic install to-filesystem
invocation, e.g. `bootc install to-filesystem /var/mnt`.
This also adds a test to verify the error occurs with minimal arguments
and adds host_is_container to the global state.
Signed-off-by: Chris Kyrouac <ckyrouac@redhat.com>
Today rpm-ostree exposes the `ostree container` verb. As part of
taking over from rpm-ostree we need to do the same.
Followup to merging ostree-rs-ext in this repository.
A next step here is for us to start owning the
/usr/libexec/libostree/ext/ostree-container
symlink but that will be a followup.
Signed-off-by: Colin Walters <walters@verbum.org>
