qemu: find the kernel + initramfs in the UEFI stone manifest shape

[mobileoverlord]

What

stone-provision-direct.sh read the kernel + initramfs out of the boot FAT image's build_args.files, matching plain filenames. qemux86-64's move to systemd-boot turned those entries into {in, out} objects (and added top-level images.kernel / images.initramfs), so jq -r printed raw JSON, neither pattern matched, and every direct provision of that machine failed:

manifest's boot.build_args.files must include a kernel + initramfs entry
[ERROR] Provision script 'stone-provision-direct.sh' failed with exit code 1

qemuarm64 is unaffected — it still carries the U-Boot shape, plain filenames, no top-level keys.

How

Take images.kernel / images.initramfs when present, else fall back to scanning the file list, unwrapping {in, out} objects as well as plain strings. A machine that later gains the ESP layout without the top-level keys still resolves. Both machines' copies of the script are identical, so both are patched.

scripts/test-stone-provision-direct.sh runs each machine's real script against its real manifest in a fabricated data dir.

Results

$ bash scripts/test-stone-provision-direct.sh
  PASS  qemuarm64: kernel staged
  PASS  qemuarm64: initramfs staged
  ...
  PASS  qemux86-64: kernel staged
  PASS  qemux86-64: initramfs staged
  ...
all checks passed

On the unfixed script the same test reproduces the CI failure exactly:

  FAIL  qemux86-64: script exited 1 (manifest's boot.build_args.files must include a kernel + initramfs entry)

The x86 assertion is the regression guard: the kernel must resolve to bzImage, not the systemd-bootx64.efi sitting in the same file list.

Not build-tested — the change is provision-time shell and stone data, no recipe or task logic. The consumer is avocado-vm's direct profile, whose x86-64 build is red on the 2026/next feed for exactly this reason and needs a re-lock once this is in a snapshot.

[Copilot]

🟢 Approval recommended

The updated jq lookups match the current manifest shapes for both machines and the added test covers the regression scenario that previously broke qemux86-64 direct provisioning.

Pull request overview

Updates QEMU stone direct provisioning to correctly locate and stage the kernel + initramfs for both qemu machines despite differing manifest shapes (U-Boot vs UEFI/systemd-boot), and adds a regression test that exercises the real scripts against the real manifests.

Changes:

• Teach stone-provision-direct.sh to prefer storage_devices.rootdisk.images.kernel / .initramfs when present, otherwise fall back to scanning boot.build_args.files while unwrapping {in,out} entries.
• Improve the failure message when the manifest doesn’t name a kernel/initramfs in either supported shape.
• Add scripts/test-stone-provision-direct.sh to validate both machines stage the expected artifacts and role links (including guarding against mistakenly selecting systemd-bootx64.efi on x86).

File summaries

File	Description
scripts/test-stone-provision-direct.sh	New integration-style test that runs each machine’s real direct provision script against its real manifest and validates staged outputs/links.
meta-avocado-qemu/stone/qemux86-64/stone-provision-direct.sh	Fix kernel/initramfs resolution for UEFI manifest shape (prefer images.kernel/initramfs, else scan file list unwrapping objects).
meta-avocado-qemu/stone/qemuarm64/stone-provision-direct.sh	Keep U-Boot behavior working via fallback scan, while sharing the same logic as x86-64.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.