mkosi for test image builds

[Torxed]

It's significantly faster than mkarchiso, and produce smaller images in general.
The downside might be that mkosi use case is probably not this.

The current limiting factor is that I have no idea how to get mkosi to boot the disk image after archinstall has done it's thing. But using this to test installs works fine if done with:

mkosi -B build
mkosi qemu \
  --drive=archinstall_small:25G \
  -- \
  -device nvme,serial=archinstall_small,drive=archinstall_small

You could manually craft a qemu-system-x86_64 command line, but the whole point of swapping to mkosi would be that it would allow us to do:

mkosi build -B
mkosi qemu

And both build with the latest/given archinstall, and also facilitate a qemu "builder" that matches whatever we built.

Currently exploring ways of booting the archinstall'd system: Torxed/mkosi@6f3c208

[svartkanin]

Looking forward to it, the current build step is slooooooooowwww

[Torxed]

If we're fine booting the disk image outside of mkosi, then this can be merged after I fix the runner.

Because it works to install with, and run a full installation. There's just no way for mkosi qemu to not boot the UKI and boot the HDD after the UKI's been used to install on the HDD.

[0xdeadd]

The runner is failing because the workflow is still calling build_iso.sh at the old path:

@@ -32,7 +32,7 @@ jobs:
       - run: pacman-key --init
       - run: pacman --noconfirm -Sy archlinux-keyring
-      - run: ./build_iso.sh
+      - run: ./test_tooling/mkarchiso/build_iso.sh

The script does cp -r . into the archive, so CWD has to stay at the repo root — that one path swap is all you need, no working-directory workaround.

Happy to send a tiny PR against your branch if that is easier. Not touching the mkosi qemu boot-after-install puzzle, that one is all yours :)

[0xdeadd]

Following up on the boot-chain question separately — dug into why -kernel none alone does not get there. The chain that is missing has three pieces, not one:

1. Stripping -kernel falls back to SeaBIOS (qemu default), which cannot load a UEFI bootloader from a GPT disk. Need OVMF explicitly.
2. NVRAM has to be persistent across runs — or rely on bootctl install's \EFI\BOOT\BOOTX64.EFI fallback path (which it does write). Either works, as long as OVMF is loaded at all.
3. bootindex=0 on the installed disk (already in your command) just needs the live UKI not to be a competing boot source. Format=uki handles that for free since there is no live disk attached.

If two invocations is acceptable, a small wrapper for the post-install boot does the job:

#!/usr/bin/env bash
# test_tooling/mkosi/boot_installed.sh
set -euo pipefail
DISK="${1:-mkosi.output/archinstall_small}"
NVRAM="./archinstall_small_VARS.fd"
OVMF_CODE="/usr/share/edk2/x64/OVMF_CODE.4m.fd"
OVMF_VARS="/usr/share/edk2/x64/OVMF_VARS.4m.fd"

[[ -f "$NVRAM" ]] || cp "$OVMF_VARS" "$NVRAM"

exec qemu-system-x86_64 \
  -enable-kvm -cpu host -m 8G -smp 4 \
  -drive if=pflash,format=raw,readonly=on,file="$OVMF_CODE" \
  -drive if=pflash,format=raw,file="$NVRAM" \
  -drive file="$DISK",format=raw,if=none,id=disk0 \
  -device nvme,serial=archinstall_small,drive=disk0,bootindex=0 \
  -display gtk

Flow becomes:

mkosi -B build
mkosi qemu --drive=archinstall_small:25G -- -device nvme,serial=archinstall_small,drive=archinstall_small
./boot_installed.sh

Keeps the Format=uki speed win, loses the "one command chains both" property, but ships now.

The clean version of this is probably upstream in mkosi — something like [Runtime] DirectKernelBoot=no that skips -kernel and auto-attaches OVMF + a persistent VARS file. Happy to take a swing at that PR after this one lands if it would be useful.

[Torxed]

Clarification: I haven't adjusted the runner code at all yet. Just fixed the tooling :)

And you're more than welcome to take a swing! I'll see if I can get feedback on your idea from the mkosi project

[Torxed]

Now we just need a GitHub runner that produces a UKI artifact that we can download and boot (to test individual commits). And keep ISO for 1:1 real world Arch ISO releases.

That might get gnarly to use mkosi to boot, as it checks versions against the version file when it tries to locate a UKI.

So we can use this PR as-is for local tests, but we'd need something like archtest.py to do more generic booting of a UKI -> HDD boot on downloaded UKI artifacts?

Tl;Dr: I'd like to create a generic helper script to help boot UKI's our GitHub runners produce

[h8d13]

Maybe you can rework #4470 ? Or you meant something else then QEMU testing ?

[Torxed]

We could, but I'd be more comfortable with Python and it would need a few tweaks to work with a few of the normal test cases.

But this is something I'd enjoy tinkering with :)

[Torxed]

Added the runner now, it's ~3min on the Github hardware.
Not too bad, it's still faster locally but I'll take the W on this one vs ISO build :)