Add Docker-based CirrOS build environment#132
Open
SeanMooney wants to merge 3 commits into
Open
Conversation
The CirrOS build system has historically required a bare Ubuntu 22.04
host with a specific set of system packages installed via system-setup.
This makes it difficult to build CirrOS reproducibly on modern
workstations or in CI environments running a different host OS.
This change introduces a Docker-based build environment that encapsulates
all build dependencies in an ubuntu:22.04 image while preserving the
existing native build-release contract.
Dockerfile installs all packages from bin/system-setup plus the implicit
dependencies (binutils, cpio, kmod, sudo) and the CI extras
(qemu-system-*, cloud-utils, openbios-ppc) in a single layer. It also
sets USER=root so the existing `sudo chown -R $USER:$USER` ownership
handoff remains valid when bin/build-release runs inside the container.
It pre-creates /dev/loop0-7 nodes and declares /cirros/download and
/cirros/ccache as volumes so that build caches persist across runs.
docker-entrypoint.sh validates that the cirros source tree is bind-mounted
at /cirros, loads the loop kernel module (required for bin/bundle's
loopback mounts), and delegates to bin/build-release. The ARCHES
environment variable can be set to limit the build to a subset of
architectures, e.g. ARCHES=x86_64.
bin/build-release also updates the Buildroot download URL from the
defunct buildroot.uclibc.org domain to buildroot.org, which now hosts the
official release archives. The existing sudo-based bundle and chown steps
are intentionally left unchanged so native and GitHub Actions builds keep
working as before.
To build an x86_64 image:
docker build -t cirros-builder .
docker run --privileged --rm \
-e ARCHES=x86_64 \
-v "$PWD":/cirros \
-v cirros-dl:/cirros/download \
-v cirros-ccache:/cirros/ccache \
cirros-builder daily
The --privileged flag is required because bin/bundle mounts a loopback
partition image during the disk image assembly stage.
Assisted-By: pi claude-sonnet-4-6
Signed-off-by: Sean Mooney <work@seanmooney.info>
CirrOS currently ships a bootable qcow2 image with a mostly empty root filesystem partition. On first boot the initramfs detects that the labeled rootfs partition does not contain /sbin/init, mounts it read-write, and copies the initramfs contents into the partition before switching root. If that first boot is interrupted, the partition can be left only partly populated. A later boot may then find /sbin/init and switch into the partition, but fail when a required shared library or file was never copied. That presents as PID 1 exiting, followed by a kernel panic. Keep the traditional minimal qcow2 image for compatibility, but rename it from the old .img suffix to -minimal.qcow2 so its format is explicit. Add a second -full.qcow2 image whose root filesystem is pre-populated at build time from the assembled filesys tarball. The full initramfs is still copied into /boot so that the early boot environment has the kernel modules required to find and mount the root device. This removes the first-boot rootfs copy window for users that choose the full image while preserving the existing minimal image and initramfs fallback behavior. Assisted-By: pi claude-sonnet-4-6 Signed-off-by: Sean Mooney <work@seanmooney.info>
CirrOS root filesystem partition images are currently formatted as ext3. The previous change makes the partition hold the real root filesystem at build time, so use ext4 for that filesystem to get the newer ext4 layout and metadata handling while keeping compatibility with the existing resize2fs-based grow path. The initramfs mounts the root device by label without forcing a filesystem type, so no initramfs change is needed. The generated x86_64 image was also boot-tested under QEMU to confirm GRUB can load the kernel and initramfs from the ext4 partition and the system reaches the CirrOS login prompt. Tested with an x86_64 Docker build and a QEMU boot smoke test. The image boots to the CirrOS login prompt, mounts /dev/vda1 as the root filesystem, and does not copy the initramfs to the rootfs partition at boot. Assisted-By: pi claude-sonnet-4-6 Signed-off-by: Sean Mooney <work@seanmooney.info>
SeanMooney
force-pushed
the
feature/docker-build-support
branch
from
aac0a69 to
6ab7a3f
Compare
This was referenced Jun 2, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Related: #131
Testing
bash -n bin/build-release docker-entrypoint.sh