Inside the New ISO Build Pipeline

The BlueOnyx ISO build process has been redesigned to be reproducible, version-aware, and release-friendly. This post explains what we build, how we build it, and how to operate the workflow without exposing internal implementation scripts.

1. Goals of the Redesign

The new pipeline was built to solve four practical problems:

• Keep one consistent process across BlueOnyx generations.
• Support both installer delivery models (NetBoot and Complete).
• Make builds reproducible and easier to validate.
• Integrate BlueOnyx branding and installer customizations in a controlled way.

2. Supported Outputs

For each BlueOnyx version, we build:

• NetBoot ISO
• Complete ISO

Current version matrix:

• 5210R (EL8 base)
• 5211R (EL9 base)
• 5212R (EL10 base)

Naming pattern:

• BlueOnyx-<VERSION>-Netboot-<YYYYMMDD>.iso
• BlueOnyx-<VERSION>-Complete-<YYYYMMDD>.iso

3. Toolchain and Build Model

The pipeline uses:

• mock for controlled build-root execution
• lorax for installer image generation
• genisoimage for final ISO creation
• createrepo_c for repository metadata
• xorriso and 7z for ISO extraction and boot image handling
• dnf download workflows for Complete payload creation

Operationally, this means we generate a clean base installer tree, apply BlueOnyx overlays, then produce release media in a deterministic format.

4. Repository Structure (Operator View)

• scripts/ build entry points and validation helpers
• kickstarts/ installer behavior per version
• updates-img/ installer runtime overrides
• product-img/ branding and product identity
• themes/ bootloader visual assets
• licenses/ license files copied into ISO root
• output/ generated ISOs and checksums
• logs/ per-build logs
• work/ temporary build artifacts

5. NetBoot vs Complete

NetBoot ISO

• Lightweight installer media
• Pulls most packages from configured repositories at install time
• Ideal for connected environments and rapid deployment

Complete ISO

• Includes a curated package payload on media (BlueOnyx/Packages)
• Includes repository metadata and installer source descriptors
• Suitable for low-connectivity or controlled/offline install scenarios

6. Branding and Installer Customization

Branding is now first-class in the build process:

• Boot menu/theme assets are injected for BIOS and UEFI paths.
• Product identity is provided via installer product configuration.
• Installer behavior overrides are delivered through versioned updates.img.
• Branding assets and product overlays are version-specific (5210R/5211R/5212R aware).

7. Command-Line Usage

Prerequisites

dnf install -y mock lorax lorax-templates-generic anaconda p7zip p7zip-plugins \
genisoimage dnf-plugins-core createrepo_c syslinux xorriso rpm

Build a Single ISO

cd /home/blueonyx-iso-builder-v3

# NetBoot
./scripts/build-blueonyx-iso.sh 5212R netboot

# Complete
./scripts/build-blueonyx-iso.sh 5212R complete

Rebuild Customization Images During Build

./scripts/build-blueonyx-iso.sh 5212R complete --rebuild-images

Enable Testing Repositories (When Needed)

TESTING=1 ./scripts/build-blueonyx-iso.sh 5212R complete

Build All Versions in Sequence

# Order is fixed: 5212R -> 5211R -> 5210R
./scripts/build-all-blueonyx-isos.sh --netboot
./scripts/build-all-blueonyx-isos.sh --complete
./scripts/build-all-blueonyx-isos.sh --complete --rebuild-images

8. Validation Workflow

After each build, we validate at three levels:

1. Build success and artifact presence
2. Smoke test on generated ISO
3. VM install confirmation

Smoke-test example:

./scripts/iso-smoke-test.sh output/BlueOnyx-5212R-Complete-YYYYMMDD.iso

What we verify includes:

• Expected installer files and boot configuration
• Complete-media metadata (.treeinfo, .discinfo, repodata)
• BlueOnyx package payload structure
• Checksums and release artifact completeness

9. Why This Is Better Than the Legacy Approach

The old approach was workable but mixed several methods, which made behavior less predictable over time. The new pipeline improves this by:

• Standardizing the end-to-end flow
• Reducing manual recovery and special-case handling
• Making output quality measurable through repeatable checks
• Supporting all maintained BlueOnyx versions under one operational model

10. Operational Guidance for Maintainers

• Treat NetBoot and Complete as separate release targets; test both.
• Keep version-specific overlays aligned with their base distro generation.
• Run smoke tests on every candidate build.
• Confirm at least one full VM install per release candidate.
• Archive logs and checksums together with release artifacts.

Closing

This redesign turns ISO production into a maintainable engineering process rather than a one-off build exercise. For BlueOnyx maintainers, it means cleaner releases, fewer surprises, and a stronger base for future versions.