1
0
mirror of https://github.com/containers/bootc.git synced 2026-02-05 06:45:13 +01:00
Colin Walters f61ba60bbc Add initramfs infrastructure
This adds scaffolding to install a stub binary which can
optionally be added into the initramfs;
prep for us doing real work during setup as we aim
to move to the native composefs backend.

The binary is *built* but is only installed by a
new `Makefile` target, so existing build system
users won't pick it up. Our development-only
`Dockerfile` gains a build option to use it
(and also ensures the initramfs is regenerated).

However previously we also discussed moving the fstab
logic into the initramfs:
https://github.com/bootc-dev/bootc/pull/1113

I might try doing that once this lands.

One notable thing is that even this trivial nearly-no-op
binary is still 4MB which I think is mostly due
to linking in a whole copy of prebuilt rust `std`.
In theory we could try going to `#[no_std]` but I
don't think it'll be viable once we start doing more here.
Probably most practical thing re size is `-Z build-std` + LTO.

Signed-off-by: Colin Walters <walters@verbum.org>
2025-08-08 09:30:32 -04:00
2024-03-06 17:10:43 +08:00
2025-08-08 09:30:32 -04:00
2025-08-07 10:01:43 -04:00
2025-08-08 09:30:32 -04:00
2024-02-08 17:56:47 -05:00
2025-07-30 16:29:55 -06:00
2025-08-08 09:30:32 -04:00
2024-11-19 21:31:30 +00:00
2025-08-08 09:30:32 -04:00
2024-08-19 16:09:42 -04:00
2025-08-08 09:30:32 -04:00
2025-07-30 23:01:17 -04:00
2024-05-17 14:35:13 +03:00

bootc logo

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

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

OpenSSF Best Practices LFX Health Score LFX Contributors LFX Active Contributors

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.

Description
Boot and upgrade via container images
Readme 22 MiB
Languages
Rust 92.7%
Nushell 3%
Shell 2.2%
Just 0.6%
Dockerfile 0.5%
Other 1%