f8ce015254
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>
bootc
Transactional, in-place operating system updates using OCI/Docker container images.
Motivation
The original Docker container model of using "layers" to model applications has been extremely successful. This project aims to apply the same technique for bootable host systems - using standard OCI/Docker containers as a transport and delivery format for base operating system updates.
The container image includes a Linux kernel (in e.g. /usr/lib/modules),
which is used to boot. At runtime on a target system, the base userspace is
not itself running in a "container" by default. For example, assuming
systemd is in use, systemd acts as pid1 as usual - there's no "outer" process.
More about this in the docs; see below.
Status
The CLI and API are considered stable. We will ensure that every existing system can be upgraded in place seamlessly across any future changes.
Documentation
See the project documentation.
Versioning
Although bootc is not released to crates.io as a library, version numbers are expected to follow semantic versioning standards. This practice began with the release of version 1.2.0; versions prior may not adhere strictly to semver standards.
Adopters (base and end-user images)
The bootc CLI is just a client system; it is not tied to any particular operating system or Linux distribution. You very likely want to actually start by looking at ADOPTERS.md.
Community discussion
- Github discussion forum for async discussion
- #bootc-dev on CNCF Slack for live chat
- Recurring live meeting hosted on CNCF Zoom each Friday at 15:30 UTC.
This project is also tightly related to the previously mentioned Fedora/CentOS bootc project, and many developers monitor the relevant discussion forums there. In particular there's a Matrix channel and a weekly video call meeting for example: https://docs.fedoraproject.org/en-US/bootc/community/.
Developing bootc
Are you interested in working on bootc? Great! See our CONTRIBUTING.md guide. There is also a list of MAINTAINERS.md.
Governance
See GOVERNANCE.md for project governance details.
Badges
Code of Conduct
The bootc project is a Cloud Native Computing Foundation (CNCF) Sandbox project and adheres to the CNCF Community Code of Conduct.
The Linux Foundation® (TLF) has registered trademarks and uses trademarks. For a list of TLF trademarks, see Trademark Usage.