bootc-ubuntu-setup: Use fixed QEMU from Resolute

[cgwalters-bot]

The QEMU selected by our Ubuntu 24.04/Plucky setup lacks the synchronous vhost-user notifier update. Investigating bootc-dev/bootc#2290 produced a controlled CentOS 9 reproducer: moving virtiofs IRQ affinity stalled the unpatched emulator, while the matched patched build completed installation. The investigation and its limitations are recorded in the debug repository.

For libvirt: true on Ubuntu 24.04, install the fixed QEMU from Resolute, together with its matching ipxe-qemu package. The latter is necessary: the first packaged-emulator smoke test failed before boot because its expected efi-virtio.rom was missing. Keep Resolute at low default apt priority and explicitly request the virtualization packages. This still upgrades their runtime dependencies, including libc, on the disposable runner; it is not a standalone executable replacement.

The step is explicitly limited to Ubuntu 24.04, leaving native Ubuntu 26.04 handling in #52 separate. Non-virtualization users are unchanged.

Add a bounded amd64/arm64 smoke test using the prebuilt CentOS Stream 9 image. It launches an ephemeral VM, verifies uname -a && true over SSH, and retains limited diagnostics before cleanup. No bootc image build is needed. SSH avoids unrelated bcvk 0.19 --execute problems uncovered during the experiment, including a false-success result when QEMU never booted.

Validation

• Local Ubuntu 24.04 container: authenticated Resolute package installation, source verification of the fix, library checks, and a QEMU virtio-net/slirp startup check.
• GitHub-hosted Ubuntu 24.04, same stock-image smoke test: stock QEMU 9.2.1 passed and Resolute QEMU 10.2.1 passed, with actual guest output verified in both cases.
• actionlint, composite shell syntax checks, and whitespace checks passed; independent AI review covered the final diff.

The new shared-action/amd64/arm64 matrix is pending this PR's CI. The full PR-2290 composefs installation and reboot tuple also still needs a fresh CI run; the smoke checks establish package integration and guest execution, not that entire test.

Generated-by: AI

Implementation and tests were AI-generated. Human review and DCO signoff are still required; no Signed-off-by was added automatically.

[cgwalters]

Hmm, this is all gross. I think what we should really do is have something like bcvk ephemeral selftest --image quay.io/centos-bootc/centos-bootc:stream9, like move some core smoke testing of functionality into the binary itself.

[cgwalters]

this is bootc-dev/bcvk#244

[cgwalters]

Ah right, I effectively bypassed the review requirement by using my bot account. Sorry about that. This is quite technically messy to handle, we'd need some database mapping between accounts.

But cc e.g. @gursewak1997 for post-merge review.

[gursewak1997]

Looks good overall

[cgwalters]

Ah right, I effectively bypassed the review requirement by using my bot account. Sorry about that. This is quite technically messy to handle, we'd need some database mapping between accounts.

Let's have a discussion on this. Should we:

1. Continue to (try to) enforce two distinct human identities every PR to merge (1 submitter and 1 reviewer, or 2 reviewers for a bot PR); we'd need to e.g. at least detect the case when there's a -bot or fully AI/LLM generated content (like bootc-bot encourages)
2. Like 1) but have a (LLM-based in https://github.com/bootc-dev/gh-agentic-workflows/ ) "risk classifier" process that dynamically adjusts the review requirements, e.g. bootc-bot could act as an independent auto-reviewer for PRs it thinks are low risk; lowering the requirement to 1 human
3. Like 3) but allow 0 humans for "very low risk" assessed PRs

---

(There's many other possibilities here, like trying really hard to ensure everyone uses a shared, efficient prioritized work queue so we keep reviews moving, etc)

[gursewak1997]

Definitely a lot of options here.
I think we should go for option 2. Keep the two-identity requirement by default, but use an LLM-based risk classifier to dynamically adjust the review requirements for low-risk PRs.
Seems like a good balance between maintaining review quality and avoiding unnecessary friction.