Skip to content

AIL-418: feat(iso): port AuroraBoot v0.26.2 switch + overlay-inject workaround to PE-8787 - #739

Open
vipsharm wants to merge 6 commits into
PE-8787from
AIL-418-PE-8787-auroraboot-iso
Open

AIL-418: feat(iso): port AuroraBoot v0.26.2 switch + overlay-inject workaround to PE-8787#739
vipsharm wants to merge 6 commits into
PE-8787from
AIL-418-PE-8787-auroraboot-iso

Conversation

@vipsharm

@vipsharm vipsharm commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

Summary

Ports the AuroraBoot ISO switch from AIL-AuroraBootISO (targeted at vipsharm-GPU) to the PE-8787 line. Ships the same UEFI-only-boot fixes and the --overlay-iso workaround here.

Ticket: AIL-418
Companion PR against vipsharm-GPU: #738

What changes

  • AURORABOOT_VERSION v0.21.2 → v0.26.2. Kairos upstream fixed the two defects that were blocking UEFI-only ISO boot on strict firmware (SuperMicro ATEN BMC, VMware ESXi/Workstation, OVMF/QEMU): xorriso now emits appended_part_as=gpt for hybrid MBR+GPT, and the ESP now ships the CD-variant signed GRUB (gcdx64.efi.signed, prefix /boot/grub, iso9660 baked in) instead of the installed-system variant (grubx64.efi.signed, prefix /EFI/ubuntu). See fix(iso): make live ISOs boot on strict UEFI firmware kairos-io/AuroraBoot#713 + kairos-sdk v0.25.2.
  • +build-iso and +build-uki-iso switched from $OSBUILDER_IMAGE → $AURORABOOT_IMAGE. osbuilder is archived. This is the same switch AIL-AuroraBootISO makes against vipsharm-GPU; the port is direct.
  • +build-iso's Hadron-specific WITH DOCKER branch collapsed into the unified arm64/amd64 path. With everything now FROM $AURORABOOT_IMAGE, the Hadron-specific dockerd-inside-container detour is unnecessary; AuroraBoot names the grub stage grubx64.efi consistently for all distros, which was the original reason the Hadron branch existed.
  • +build-iso ISO name normalized after AuroraBoot writes it (mv /tmp/auroraboot/*.iso /iso/$ISO_NAME.iso). AuroraBoot's --override-name / --output are inert for dir: sources — tracked upstream as AuroraBoot: build-iso --output and --override-name silently ignored for dir: sources kairos-io/kairos#4284.
  • +build-iso xorriso post-process to apply /overlay/. AuroraBoot's build-iso subcommand doesn't call StepInjectCC, so --overlay-iso <dir> silently drops overlay files. Same one-line xorriso invocation upstream uses in pipeline mode's InjectISO. Tracked upstream as AuroraBoot: build-iso subcommand silently drops --overlay-iso content (StepInjectCC not called) kairos-io/kairos#4283, with a fix PR at fix(build-iso): apply --overlay-iso via StepInjectCC + run xorriso when only overlay is present kairos-io/AuroraBoot#716.
  • overlay/files-iso/boot/grub2/grub.cfg refactored: $consoleparams/$videoparams now branch on ${grub_platform} (fixes vga=795 being inert under UEFI); loadfont restricted to BIOS path (some firmwares blank the menu under gfxterm); search corrected to /boot/kernel. Byte-identical BIOS path. Cherry-picked from Arvind's original grub.cfg cleanup.

What is NOT changed

  • +uki-genkey and +build-provider-trustedboot-image stay on osbuilder-tools. Same scope decision as AIL-AuroraBootISO — those don't produce ISOs, so the UEFI-boot bug doesn't apply; they can migrate separately.
  • +build-uki-iso uses auroraboot build-uki -t iso (a different upstream code path). The overlay-inject workaround is deliberately not applied there yet — could break UKI signing if applied naively. Follow-up needed to verify safe overlay injection into a UKI ISO.

Commits (bottom-up)

  • 1fe29df — Update grub.cfg (Arvind's cleanup, cherry-picked from 4e59375).
  • 6d409d6 — feat(iso): switch +build-iso and +build-uki-iso to AuroraBoot (from 978a633; version bumped to v0.26.2 during conflict resolution; Hadron WITH DOCKER branch removed).
  • ec549cf, 7e5c2b4, ae85eeb — ISO filename normalization (from a179757, c8ed02b, b25262e).
  • b83ded4 — fix(iso): xorriso-inject overlay into ISO ... (from 9de6067).

The 4 UEFI-workaround commits from AIL-AuroraBootISO (271195e, dec346e, 41f434f, 629a565) are deliberately not ported — they were later reverted upstream by AuroraBoot v0.26.2. This port goes straight to the v0.26.2 endpoint.

Verified

  • earthly ls — Earthfile parses cleanly.
  • No osbuilder references remain in +build-iso / +build-uki-iso.
  • Overlay-inject step in place at +build-iso.
  • ISO name normalization step in place at +build-iso and +build-uki-iso.

Not yet verified

  • End-to-end pipeline ISO build against PE-8787 base (companion appliance-builder run against vipsharm-GPU is #31126547352 — separate test, not this branch).
  • Install-and-reboot on real hardware (SuperMicro, VMware ESXi) — same status as the vipsharm-GPU PR.

Upstream

Once #716 merges and the AuroraBoot image bumps, we can drop the xorriso -map /overlay / post-process step from this Earthfile.

🤖 Co-authored-by: Claude Opus 4.7 noreply@anthropic.com

arvind-sys and others added 6 commits August 6, 2026 16:40
@arvind-sys @vipsharm
Update grub.cfg
1fe29df
@vipsharm @claude
feat(iso): switch +build-iso and +build-uki-iso to AuroraBoot
6d409d6 
kairos-io/osbuilder and kairos-io/enki are both archived, so the
osbuilder-tools image we've built ISOs against for years has no
maintained upstream. Switch to quay.io/kairos/auroraboot:v0.26.1
(kairos-io/AuroraBoot), the maintained successor.

Only +build-iso and +build-uki-iso move. +uki-genkey and
+build-provider-trustedboot-image still call the osbuilder entrypoint;
they touch container/UKI artifacts, not ISOs, and can migrate
separately once the ISO switch is boot-verified.

Mapping (osbuilder -> AuroraBoot):
  /entrypoint.sh build-iso  -> auroraboot build-iso
    --name                  -> --override-name
    --arch x86_64           -> --arch amd64 (Go arch names)
  enki build-uki -t iso     -> auroraboot build-uki -t iso
    -k /keys (bundled)      -> --public-keys / --sb-key /
                               --sb-cert / --tpm-pcr-private-key
                               (all still under /keys because the
                               three secure-boot/* source dirs are
                               flattened into the same COPY target)

Bonuses from the AuroraBoot base image (Fedora 44):
  - xorriso 1.5.8.pl02 (osbuilder-tools ships 1.4.6, which the
    Supermicro ATEN BMC virtual CD refuses to boot). This is the
    xorriso fix vipsharm-isofix built from source; no longer needed.
  - Actively maintained; kairos-sdk fixes land here.

Caveat: AuroraBoot still selects grubx64.efi.signed (installed-system
variant, prefix /EFI/ubuntu) via kairos-sdk utils.GetEfiGrubFiles.
That binary hangs immediately on Supermicro UEFI. This switch does
not fix defect 1 from the UEFI investigation on its own. Verifying
that on real hardware is the next step; if it reproduces, the
CD-variant swap workaround from vipsharm-isofix 22e00cb / 0a80d30
gets ported.

The grub.cfg cleanup (previous commit, ex-3faff86) is independent
of the toolchain switch and rides along.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
@vipsharm @claude
fix(iso): normalize AuroraBoot's ISO filename to \$ISO_NAME.iso
ec549cf 
AuroraBoot v0.26.1's --override-name is not honored for "dir:" sources
(only image sources). A build-iso against dir:/build/image landed as
kairos-ubuntu-24.04-core-amd64-generic-v4.0.4.iso in /iso/, and the
subsequent

    RUN sha256sum \$ISO_NAME.iso > \$ISO_NAME.iso.sha256

failed with "No such file or directory".

Rename /iso/*.iso to \$ISO_NAME.iso before checksumming, matching what
+build-uki-iso has done all along. This decouples us from whatever
naming scheme AuroraBoot uses internally.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
@vipsharm @claude
fix(iso): locate AuroraBoot's ISO wherever it lands, not just /iso/
7e5c2b4 
AuroraBoot v0.26.1's --output flag on build-iso is ignored for "dir:"
sources: the log line "Generating iso '...' to '/tmp/auroraboot'"
confirmed the ISO drops under /tmp/auroraboot, not /iso/, so
`mv /iso/*.iso ...` failed with "cannot stat '/iso/*.iso'".

Search /iso, /tmp/auroraboot, and (fall back) the whole filesystem for
a .iso and move it into /iso/\$ISO_NAME.iso. Applied to both +build-iso
and +build-uki-iso so we're covered if build-uki -d has the same bug.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
@vipsharm @claude
chore(iso): drop dead --output/--override-name/-d flags and clean up …
ae85eeb 
…rename

Both --output on build-iso and -d on build-uki are silently ignored by
AuroraBoot v0.26.1 for "dir:" sources -- the ISO always drops at
/tmp/auroraboot/*.iso. Two builds in a row confirmed the location, so
drop the fallback find-tree and just mv from /tmp/auroraboot directly.

Also drops --override-name (also inert for dir: sources on build-iso)
so the invocation reads honestly.

No behavior change -- the previous fallback path already worked. This
is just less noisy shell.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
@vipsharm @claude
fix(iso): xorriso-inject overlay into ISO because AuroraBoot's build-…
b83ded4 
…iso subcommand skips StepInjectCC

Empirically: AuroraBoot v0.26.2 subcommand \`build-iso dir:...\`
with --overlay-iso produces an ISO whose /boot/grub2/grub.cfg is
AuroraBoot's default "Kairos"-branded template rather than our
overlay's "Palette eXtended Kubernetes Edge Installer" version.
Confirmed by extracting the file from the built ISO.

Root cause (pkg/ops/iso.go, internal/cmd/build-iso.go): the build-iso
subcommand runs only

    PrepDirs -> StepCopyCloudConfig -> StepDumpSource -> StepGenISO

and never calls StepInjectCC. StepInjectCC is where AuroraBoot's
InjectISO() function xorriso-maps the overlay directory onto the
finalised ISO tree. Without it, --overlay-iso silently discards
every file we put under /overlay/ -- not just the grub menu, but
also user-data, cluster config (spc.tgz), content bundles, and
edge_custom_config.

Two ways to fix:

  1. Switch +build-iso to AuroraBoot pipeline mode (docker run
     auroraboot --set container_image=... --set iso.overlay_iso=...
     --cloud-config ...). This invokes StepInjectCC. But it's a
     ~100-line rewrite involving DinD, container_image loading, and
     matches the pattern +cloud-image / +kairos-raw-image already
     use.

  2. Do StepInjectCC's actual work ourselves inline. Its whole body
     is one xorriso command:

        xorriso -indev X -outdev X -map <overlay> / \
                -boot_image any replay

     No DinD, no rewrite. Same result.

Going with (2). Small, isolated, uses the same xorriso invocation
the upstream code path does, and can be trivially deleted the day
StepInjectCC is wired into the subcommand path.

Doesn't touch +build-uki-iso; that uses build-uki -t iso which is a
separate code path.

Filed separately as an upstream issue on kairos-io/AuroraBoot
(subcommand build-iso should call StepInjectCC too, or --overlay-iso
should be honored end-to-end within StepGenISO).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@rishi-anand rishi-anand rishi-anand approved these changes
@Dr-N00B Dr-N00B Awaiting requested review from Dr-N00B
@abhinavnagaraj abhinavnagaraj Awaiting requested review from abhinavnagaraj
@santhoshdaivajna santhoshdaivajna Awaiting requested review from santhoshdaivajna

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@vipsharm @rishi-anand @arvind-sys