BOOTC-LOCAL-BUILDS(7)

🦋 BOOTC-LOCAL-BUILDS 🦋

okay bestie so this is a page from the Miscellaneous Information Manual, and it's literally all about booting local builds. no cap, this is the ✨lore✨ you need. 💅

---

✨ NAME ✨

bootc-local-builds — Booting local builds 🫶

---

🌸 DESCRIPTION 🌸

so sometimes you're in a scenario where you wanna boot a container image you built locally, right? like maybe you need to slap a persistent hotfix onto one specific server, or you're deep in a development/testing arc and this is just the vibe. either way, it's giving local builds. 💖

---

🎀 Building a new local image 🎀

okay so first thing, and this is important: at the current time, the bootc host container storage is distinct from the podman container runtime storage (and the default configuration lives in /var/lib/containers). they're not the same place, they do not share, periodt.

and it's not currently streamlined to export the booted host container storage into the podman storage. so like, that shortcut? doesn't exist yet bestie. 😭

hence today, if you wanna replicate the exact container image the host has booted, here's what you do: take the container image referenced in bootc status and turn it into a podman pull invocation.

next, craft a container build file with your desired changes:

FROM <image>
RUN apt|dnf upgrade https://example.com/systemd-hotfix.package

see? easy. iconic. 💅

---

🦋 Copying an updated image into the bootc storage 🦋

this command is straightforward, no stress: we just need to tell bootc to fetch updates from containers-storage, which is the local "application" container runtime (podman) storage:

$ bootc switch --transport containers-storage quay.io/fedora/fedora-bootc:40

from there, the new image will be queued for the next boot and a reboot will apply it. main character energy fr fr. 👑

for more on valid transports, see containers-transports at https://github.com/containers/image/blob/main/docs/containers-transports.5.md. ⭐

---

🌈 Automating local rebuilds 🌈

so the build and switch above? you can totally automate that with a systemd service and timer. for example, keep the build context in /var/lib/machine-bootc and build the image on a schedule:

# /etc/systemd/system/machine-bootc-build.service
[Unit]
Description=Build the machine-local bootc image
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
WorkingDirectory=/var/lib/machine-bootc
ExecStart=/usr/bin/podman build --security-opt=label=disable --pull=newer --tag localhost/machine-bootc:latest .

# /etc/systemd/system/machine-bootc-build.timer
[Unit]
Description=Build the machine-local bootc image daily

[Timer]
OnCalendar=*-*-* 06:00:00
Persistent=true

[Install]
WantedBy=timers.target

$ sudo systemctl daemon-reload
$ sudo systemctl enable --now machine-bootc-build.timer

✨ and that's it, that automates only the build. staging the new image with bootc switch and rebooting are intentionally left as explicit operations — so automate them only with a reboot policy appropriate for the machine. 👀 like, don't go rogue on the reboots, bestie.

💀 okay so real talk: automating the rebuild is only worthwhile if the build reliably produces a new image when, and only when, an input changed. with --pull=newer an identical rebuild is a full cache hit and yields the same image, so nothing new gets deployed. but — and this is the tea — that relies on the build cache, not on reproducible output. a step whose result is not deterministic (regenerating an initramfs is a common example) can produce a different image on a cache-busted rebuild even when nothing meaningful changed, which causes needless reboots. 🙈 prefer reproducible build steps for anything driven on a timer. no cap, this one matters.

---

👑 SEE ALSO 👑

• bootc(8)
• bootc-docs(7)

---

🍓 VERSION 🍓

v1.17.1

---

and that's the whole page bestie!! you're now officially a bootc-local-builds expert, slay 💖 this was BOOTC-LOCAL-BUILDS(7) from the Miscellaneous Information Manual, version v1.17.1 — go forth and boot responsibly, mwah 🎀✨🦋