feat(images): add minimal-os image definition#18030
Conversation
Add a minimal OS VM image with: - Stripped-down package selection based on AZL3 minimal-packages - Two build profiles (minimal-os / minimal-os-dev) for repo selection - UEFI boot with GRUB2 BLS, ext4 rootfs, 5G VHD-fixed output - aarch64 and x86_64 architecture support - Registration in images.toml with static-image-checks test suite Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Adds canonical and development variants of a minimal bootable Azure Linux VM image.
Changes:
- Defines x86_64/aarch64 UEFI VHD images with a minimal package set.
- Registers both profiles with static image validation.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
base/images/minimal-os/minimal-os.kiwi |
Defines profiles, storage, boot configuration, repositories, and packages. |
base/images/images.toml |
Registers both image variants and their tests/capabilities. |
| --> | ||
| <repository type="rpm-md" alias="azurelinux-base"> | ||
| <source | ||
| path="https://packages.microsoft.com/azurelinux/4.0/beta/base/$basearch" /> |
| description = "Minimal OS Image" | ||
| definition = { type = "kiwi", path = "minimal-os/minimal-os.kiwi", profile = "minimal-os" } | ||
| tests.test-suites = [ | ||
| { name = "static-image-checks" }, |
reubeno
left a comment
reubeno
left a comment
There was a problem hiding this comment.
What's the purpose of this image? Is there a PRD that outlines its intended use and guidelines for its composition?
(Is this the intended base image for Image Customizer to use for customization?)
| <package name="azurelinux-release" /> | ||
| <package name="bash" /> | ||
| <package name="ca-certificates" /> | ||
| <package name="dbus" /> |
There was a problem hiding this comment.
My understanding is that dbus has fallen out of favor and dbus-broker is the preferred implementation. Can we confirm what's in our VM image and which is the correct one to use here?
| </repository> | ||
|
|
||
| <packages type="image"> | ||
| <package name="azurelinux-release" /> |
There was a problem hiding this comment.
Our VM, WSL, and container images use a more specific subpackage of azurelinux-release to get the right variant metadata in os-release. What's the plan for how this will work for images derived from the minimal OS image?
| <package name="dnf5" /> | ||
| <package name="e2fsprogs" /> | ||
| <package name="grub2" /> | ||
| <package name="glibc-langpack-en" /> |
There was a problem hiding this comment.
What's the trade-off between including glibc-langpack-en vs. glibc-minimal-langpack in the minimal OS image? Will Image Customizer swap it out anyway with the desired langpack?
| <release-version>4.0</release-version> | ||
| <type | ||
| image="oem" | ||
| format="vhd-fixed" |
There was a problem hiding this comment.
Does this need to be VHD fixed? It looks like 3.0 used a VHDX, which is generally preferred.
| initrd_system="dracut" | ||
| filesystem="ext4" | ||
| fscreateoptions="-m 1" | ||
| kernelcmdline="console=ttyS0 earlyprintk=ttyS0 rd.shell=0" |
There was a problem hiding this comment.
Should there be any kernel command line baked in? I don't see evidence of one in 3.0.
| overlayroot="false" | ||
| eficsm="false" | ||
| bootpartition="false" | ||
| efipartsize="200" |
There was a problem hiding this comment.
Looks like the 3.0 layout was extremely minimal (i see indication of the ESP being tiny in 3.0) since it's only expected to be used as a base image for customization and not a readily deployable OS itself. Should we be following suit?
| efipartsize="200" | ||
| rootfs_label="azurelinux"> | ||
| <bootloader name="grub2" bls="true" console="serial" timeout="1" /> | ||
| <size unit="G">5</size> |
There was a problem hiding this comment.
See above regarding partition layout.
| bootpartition="false" | ||
| efipartsize="200" | ||
| rootfs_label="azurelinux"> | ||
| <bootloader name="grub2" bls="true" console="serial" timeout="1" /> |
There was a problem hiding this comment.
Similar to kernel config, should we omit bootloader configs from the definition?
| initrd_system="dracut" | ||
| filesystem="ext4" | ||
| fscreateoptions="-m 1" | ||
| kernelcmdline="console=ttyAMA0 earlyprintk=ttyAMA0 rd.shell=0" |
There was a problem hiding this comment.
Note: if we remove the kernel command line, I assume we can collapse the 2 arch-specific <preferences/> sections.
Add a minimal OS VM image with:
Local verification with build and qemu boot and build on CT/koji was done. Static image checks passed.
The 4.0 default selection has more packages 32 vs 28. However, with dependencies pulled 4.0 has more packages ~150 for 3.0 vs ~180 for 4.0. Size difference in rpm install size is around 50MB.
AB#22015