Implement Bootable Container (bootc) image & deployment

[janhalen]

1. Image Creation & Local Build

• Draft Containerfile: Create a multi-stage Containerfile based on a bootc-compatible image

• Local Build: Use Podman Desktop/CLI to build the image locally to verify there are no layer errors.

• Decide directory stucture and make a PR with the Container file and a minimal documentation for how to test and use it

2. Registry Integration (GitHub Packages)

• GHCR Authentication: Configure local Podman to authenticate with ghcr.io using a Personal Access Token (PAT).

• Initial Push: Manually push the first stable image to the GitHub Container Registry associated with the repo.

3. Provisioning & Deployment

• Boot test device (or VM) with a bootc distro.

• Use bootc swith to deploy the image from the container repo (e.g. with bootc switch ghcr.io/os2sandbox/openclient-core:0.02)

• Status Verification: Confirm the node is running the containerized OS (e.g. with bootc status)

4. Auto-Update Testing

• Trigger Update: Modify a small component in the Containerfile, rebuild, and push a new version to GHCR.

• Verify Pull: Ensure the remote node detects the new image version via the bootc-fetcher or a manual bootc update command.

• Reboot Validation: Confirm the system performs a transactional update and reboots into the new image state without manual intervention.

Definition of Done (DoD)

• The system boots successfully from an image hosted on GHCR.
• bootc status shows the system is tracking the GitHub registry correctly.
• A change pushed to the registry is automatically pulled and applied to the device.
• Documentation provided for the Containerfile structure.

[janhalen]

@ChatBotBerg : Please confirm that @turegjorup can start estimating this.

@turegjorup : Can you estmate this pro-bono? Otherwise hold on until @ChatBotBerg has given the go!

[rriemann]

Dear all,

we demonstrate how this work with our https://eu-os.eu PoC project.

More on this PoC: https://eu-os.eu/poc/

The relevant code to create the image:

• Gitlab CI https://gitlab.com/eu-os/workspace-images/eu-os-base-demo/-/blob/main/.gitlab-ci.yml?ref_type=heads (bluebuild build -vv -S sigstore --push ./recipes/$RECIPE)
• Recipe file: https://gitlab.com/eu-os/workspace-images/eu-os-base-demo/-/blob/main/recipes/almalinux-10.yml?ref_type=heads (we have also one for Fedora in the same folder)
• Container files are created internally and only generated explicitly for transparency reasons: https://gitlab.com/eu-os/workspace-images/eu-os-base-demo/-/jobs/13556255166/artifacts/browse/recipes/

As you find in our PoC documentation on the website, we load this image straight info Foreman and deploy via PXE boot to laptops (in our case Thinkpads).

The image is built very night using Gitlab CI.

The tool bluebuild supports Github and its registry even better than Gitlab, but we anticipate to run on sovereign code forges and have thus avoided dependencies on Github.

Happy to answer any more questions you may have.

[janhalen]

@0xf1e: You are more than welcome to chip in with estimates for @ChatBotBerg to assemble into a development budget that can be presented to the steering comittee

[janhalen]

Hey @rriemann! Thank you for the additional context and for walking us through your PoC.

Your approach is a clear demonstration of your choice of a more traditional provisioning stack, and we appreciate the transparency in sharing your GitLab CI and recipe files.

As we evaluate the long-term trajectory of our reference architecture, we are moving in a different direction regarding the "on-device" lifecycle. We have a few specific architectural requirements that are central to our goals:

1. Minimizing Infrastructure Overhead: We are prioritizing a decentralized, "pull-based" model to reduce the number of moving parts. While PXE and management consoles like Foreman are established tools, they introduce significant external infrastructure dependencies. Our goal is to ensure the system is as resilient as possible by minimizing reliance on complex server-side environments.

2. GitOps as the Single Source of Truth: For our security and robustness model, we build on a GitOps workflow where the Git repository is the sole authoritative state of the fleet. By avoiding intermediate "admin consoles", statefull "device databases" and manual management practises, we proactively eliminate configuration drift—a core requirement for our project's stability.

3. Application and Config Delivery: We are leveraging modern patterns for modularity. Applications will be delivered either as part of the "core-apps" (e.g., LibreWolf) or as supplemental containerized apps via Logically Bound Images. This allows us to handle domain-specific or granular location-based configs (e.g., specific tags for self-service-pc or aarhus-municipal-library) entirely within the image structure, maintaining our "everything-is-an-image" philosophy.

4. Standardization over Custom DSLs: As mentioned previously, we are staying strictly within the OCI-native Containerfile DSL. This ensures our images remain fully portable and compatible with the broader cloud-native ecosystem without requiring specific CLI wrappers or emerging community-specific abstractions.

We genuinely appreciate you sharing these details—it helps us clarify the boundaries of our own requirements. We’d be happy to keep the dialogue open as our respective projects evolve, particularly if there are future opportunities to align on raw OCI and GitOps-native workflows!

[agnetemoos]

I have looked into https://universal-blue.org/ and suggest using a base image from that project for the OS2BorgerPC POC.

Universal Blue is a real-world implementation of the NornNet idea. The project maintains a range of base images and builds custom distros on top of those.

They encourage the community to create custom images based on their base images, and they provide a fine, well-documented template for that: https://github.com/ublue-os/image-template.

The Universal Blue community is very active. There are discussion forums, chat, video tutorials, and lots of fine documentation.

[janhalen]

@agnetemoos: I certainly appreciate your desire for momentum on this. However, before we commit to an indie developer ecosystem that carries significant pre-existing configurations, it would be prudent to finalize our core "Whys." This will ensure we don't inadvertently select a base image populated with software that is incompatible with or not needed for our specific user stories.

For our foundational layer, we should seek a bootc-native distribution with a minimal footprint. While the uBlue desktop images are impressive for personal workstations, they are perhaps too "opinionated" for the "selvbetjening" (self-service) or kiosk domains we are targeting.

Having tested Bluefin as a daily driver for several months, I have found it to be heavily customized—containing very non standard software choices, such as native IDE installations on the immutable host, that do not align with a streamlined immutable production environment.

My recommendation for our architectural approach:

• Strict Separation of Concerns: We should utilize a clean, minimal base image and layer domain-specific requirements on top.
• Purpose-Built Design: Avoid the "universal image" approach in favor of one tailored strictly to our delivery goals.

For the Proof of Concept, I believe a "less is more" philosophy will serve us best.

[agnetemoos]

For a prototype, speed and evidence of real-world usability are crucial. A complete infrastructure project is not within the scope of a prototype.

An infrastructure setup will, of course, be needed if the prototype succeeds and receives further funding. But further funding is usually tied to the prototype providing evidence that it can produce the product it promises — namely a BorgerPC.

I am aware that Bluefin has too much software bundled in. I don't suggest using that as a base image