microsoft / microsoft/azurelinux

[4.0] Official Azure Linux 4.0 bootc base image (bootable container, atomic updates from an OCI registry)

Open
#18,817 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

4.0 enhancement
Dominant language
Python
Stars
5.3k
Forks
707
Avg merge
2d 18h
Merged PRs (30d)
235

Description

**Is your feature request related to a problem? Please describe.**

Azure Linux 4.0 already packages bootc, ostree, rpm-ostree, bootupd and composefs, but there is no official bootable container image and no documented path to build one. Fedora publishes `quay.io/fedora/fedora-bootc` and CentOS `quay.io/centos-bootc/centos-bootc`; users derive their own images from those with a Containerfile, push them to any OCI registry, and machines update from the registry atomically with rollback. Azure Linux users cannot do that today without reverse-engineering the packaging gaps.

**Describe the solution you'd like**

An official Azure Linux 4.0 bootc base image on MCR, built and tested by the project, that follows the bootc image contract: kernel and initramfs under `/usr/lib/modules//`, an empty `/boot`, the bootupd payload under `/usr/lib/efi`, the rpm database at `/usr/share/rpm` in rollback-journal mode, the composefs layout from bootc's reference files, and `bootc container lint` passing. With that image, a user builds a derived image with a Containerfile, installs it with `bootc install to-disk`, and updates it from a registry, the way Fedora CoreOS and Silverblue users do.

**Describe alternatives you've considered**

I built a working proof of concept on top of `mcr.microsoft.com/azurelinux-beta/base/core:4.0` with the packages from the preview repo: https://github.com/JayDoubleu/azurelinux-bootc. It boots in QEMU on x86_64 and aarch64, updates and rolls back from a registry, verifies sigstore signatures with a policy in the image, splits the image into package-aligned layers with `rpm-ostree compose build-chunked-oci` so a version bump downloads about 1.5 MB, and runs the whole loop in GitHub Actions. The fixes it needed are the things an official image would settle once: move `vmlinuz` out of `/boot`, stage `/boot/efi` for `bootupctl backend generate-update-metadata`, add `bubblewrap` and `grub2-pc-modules` so `bootc install` works, move the rpm database to `/usr/share/rpm` and take it out of WAL mode so `rpm -qa` works on a read-only `/usr`, and the rpm-ostree upgrade bug in #18802. The decisions and measurements are in that repository's `docs/`.

**Additional context**

The same image model gives Azure Linux a simple story for VM images (`bootc install to-disk`, or `bootc-image-builder` for VHD), for people who host their own derived images on GitHub Container Registry and update fleets from them, and possibly for WSL2 distributions built from the same container image, though I have not tried that last one. The Containerfile and the test loop in the proof of concept are available for the project to reuse or adapt.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the proof-of-concept repository's Containerfile and docs/, then compare its required fixes with Azure Linux packaging and issue #18802. Reproduce the QEMU and GitHub Actions test loop and use bootc container lint as the completion check. Done means an official Azure Linux 4.0 MCR image meets the listed bootc contract and supports installation, updates, and rollback.

Written by the indexing model from the issue text.

Assessment

Tech stack
azure, github-actions, linux
Domain
cloud, devops, operating-systems
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.