BOOTC-PA...MANAGERS(7)

🌸 NAME 🌸

bootc-package-managers — package manager integration, bestie 💅

---

✨ DESCRIPTION ✨

okay so the whole toplevel goal of bootc is to push a default model where Linux systems get built and delivered as (container) images. iconic. and in that model, the default usage of package managers such as apt and dnf is at container build time. periodt. 🫶

but like… sometimes you end up shipping the package manager tooling onto the end system anyway. and lowkey in some cases that's even desirable, because it lets you do workflows with transient overlays using e.g. bootc usroverlay. 💖

Detecting image-based systems 🌈

ngl, bootc is not the only image based system — there are many. and the common emphasis is on having the operating system content in /usr, and for that filesystem to be mounted read-only at runtime. ⭐

so a first recommendation here: package managers should detect if /usr is read-only, and give a useful error message referring users to documentation guidance. that's the vibe. that's the ask. 🎀

an example of a non-bootc case is "Live CD" environments, where the physical media is readonly. some Live operating system environments end up mounting a transient writable overlay (whether via e.g. devicemapper or overlayfs) that makes the system appear writable — but it's arguably clearer not to do so by default. detecting /usr as read-only here and providing the same information would make sense. 💜

and if you want to specifically detect if bootc is in use, you can parse its JSON status (if the binary is present) to tell if a system is tracking an image. the following command succeeds if an image is not being tracked:

test $(bootc status --format=json | jq .spec.image) = null

The /run/ostree-booted file 🦋

this one is created by ostree, and hence created by bootc (with the ostree backend). so yes, you can use it to detect ostree. however — important — most cases should instead detect via one of the recommendations above. 👑

Running a read-only system via podman/docker 🔥

so the historical default for docker (which got inherited into podman) is that / is a writable (but transient) overlayfs. but like, e.g. podman supports a --read-only flag, and Kubernetes pods (https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/) offer a securityContext.readOnlyRootFilesystem flag. 💅

running containers in production in this way is a good idea, for exactly the same reasons that bootc defaults to mounting the system read-only. slay. 👑

make sure your package manager offers a useful error message in this mode. today, for example:

$ podman run --read-only --rm -ti debian apt update
Reading package lists... Done
E: List directory /var/lib/apt/lists/partial is missing. - Acquire (30: Read-only file system)
$ podman run --read-only --rm -ti quay.io/fedora/fedora:40 dnf -y install strace
Config error: [Errno 30] Read-only file system: '/var/log/dnf.log': '/var/log/dnf.log'

however, note that both of these fail on /var being read-only; in a default bootc model, it won't be. so a more accurate check is thus closer to:

$ podman run --read-only --rm -ti --tmpfs /var quay.io/fedora/fedora:40 dnf -y install strace
...
Error: Transaction test error:
  installing package strace-6.9-1.fc40.x86_64 needs 2MB more space on the / filesystem

$ podman run --read-only --rm --tmpfs /var -ti debian \
    /bin/sh -c 'apt update && apt -y install strace'
...
dpkg: error processing archive /var/cache/apt/archives/libunwind8_1.6.2-3_amd64.deb (--unpack):
 unable to clean up mess surrounding './usr/lib/x86_64-linux-gnu/libunwind-coredump.so.0.0.0' before installing another version: Read-only file system

these error messages are misleading and confusing for the user 😭. a more useful error may look like e.g.:

$ podman run --read-only --rm --tmpfs /var -ti debian \
    /bin/sh -c 'apt update && apt -y install strace'
error: read-only /usr detected, refusing to operate. See `man apt-image-based` for more information.

Transient overlays 💜

today there is a simple bootc usroverlay command that adds a transient writable overlayfs for /usr. this makes many package manager operations work; conceptually it's similar to the writable overlay that many "Live CDs" use. however — one cannot change the kernel this way, for example. 💀

an optional integration that package managers can do is to detect this transient overlay situation and inform the user that the changes will be ephemeral. 🧚

Persistent changes ⭐

a bootc system by default does have a writable, persistent data store that holds multiple container image versions (more in filesystem (see bootc-filesystem(7))). 💖

systems such as rpm-ostree (https://github.com/coreos/rpm-ostree/) implement a "hybrid" mechanism where packages can be persistently layered and re-applied; the system effectively does a "local build", unioning the intermediate filesystems. that's giving main character energy honestly. 🌈

one aspect of how rpm-ostree implements this is by caching individual unpacked RPMs as ostree commits in the ostree repo. 👑

this section will be expanded later; you may also be able to find more information in booting local builds (see bootc-local-builds(7)).

---

💅 SEE ALSO 💅

• bootc(8)
• bootc-docs(7)
• bootc-filesystem(7)
• bootc-local-builds(7)

🎀 VERSION 🎀

v1.17.1

---

okay bestie that's the whole page, no cap 🫶 it's from the Miscellaneous Information Manual, it's bootc-package-managers(7), and the version on it is v1.17.1 — go forth and be image-based, you absolute icon 💖✨👑