Every guest boots the UEFI firmware the host's QEMU declares; ovmf/ and aavmf/ go

[Japabu]

Guests now boot whatever UEFI firmware the host's QEMU installation declares. The tree no longer carries firmware: ovmf/ and aavmf/ are deleted, 140,509,184 bytes in total. ovmf/ held two images of unknown version and recipe, plus DEBUGX64_OVMF.fd, which nothing referenced. aavmf/ was byte-identical to Homebrew QEMU 11.1.1's edk2-aarch64-code.fd and edk2-arm-vars.fd. The owner ruled that firmware QEMU installs is inside "Rust and QEMU" and a committed firmware binary is not. #563 made the kernel boot on QEMU's stock edk2.

What changed

• src/firmware.rs finds the firmware. It follows QEMU's interop spec, docs/interop/firmware.json:
  • The descriptors are the firmware/*.json files under, in order, the user's override ($XDG_CONFIG_HOME, else $HOME/.config, /qemu/firmware), the system's (/etc/qemu/firmware), then every data directory qemu-system-* -L help prints.
  • Descriptors are taken in that order. A name in an earlier directory hides the same name in a later one, and an empty file hides its name.
  • The first descriptor that fits wins. It must declare UEFI flash firmware for the machine as a raw code image beside a raw variable-store template, with neither secure-boot nor requires-smm. No guest here sets up either. The selection test carries a qcow2, a requires-smm-only and a mode: combined descriptor ahead of the fitting one, each refused by exactly the rule named for it.
  • The machine is pc-q35-<major.minor> or virt-<major.minor>, the type the q35 and virt aliases resolve to, with the version from --version. Arch::machine is the one place q35/virt is declared; src/qemu.rs and the harness (tests/common/qemu.rs) both read it.
  • If nothing fits, the boot is refused, naming every descriptor read and every directory searched.
  • A descriptor that does not parse is refused by name. The machine glob reader is a trailing-* prefix match; anything else — a non-trailing *, or another fnmatch metacharacter — is refused by name.
  • There is no hard-coded path and no fallback. The answer is asked once per process for each architecture.
• Every boot writes its own copy of the variable-store template, made owner-writable after the copy regardless of the template's own mode — std::fs::copy carries the template's permissions, and a read-only template (a 0444 store, as on Nix) would otherwise leave the boot's own copy, and every boot after it, unwritable.
  • The harness copies it into the boot's lane as vars-<seq>.fd and deletes it when the instance drops, the same way it handles the boot's own image.
  • A test's BootOptions::firmware_vars is still the test's own file. The update rig keeps its copy across boots as before, now copied from the declared template.
  • cargo run writes target/firmware-vars.fd fresh on every launch.
  • Before, the x86 store was mounted read-only and the AArch64 one as a snapshot QEMU discarded. Both are now one writable file per boot, so what firmware writes survives a guest reset within that boot.
• The harness reads the virtio console from the kernel's first record on. QEMU's own edk2 drives the virtio-serial port as a UEFI console, which the old ovmf/ did not. Firmware and the loader write there before the kernel does: 42 lines in the 572r2 nightly, with the loader's last line cut off at the handoff and fused onto the kernel's first record (Loader log: the kernel handoff begins, so [kernel 0.000 cpu0 boot] black box: …).
  • src/kernelconsole.rs's KernelConsole::pass withholds a console's bytes until the first [kernel head and passes everything from it on. It finds the head anywhere in the stream, so the fused line splits, and across chunk boundaries.
  • Before, every stdio reader took those lines as the kernel's console. root_named_twice_on_the_boot_disk counted one loader read twice, and c_capture_ignores_daemon_lines read the firmware's lines as userland's.
  • tests/common/qemu.rs's reader thread passes a virtio profile's stdio through it before ConsoleStream, the line channel and boot_log. A 16550 on stdio has no other file, so it is read whole.
  • The rule is where the kernel begins, so a firmware that writes nothing on the port reads the same.
  • HEAD is the [kernel head's one declaration. The harness's is_kernel_line, Serial::interleaved and the update rig's loader_said read it.
  • root_named_twice_on_the_boot_disk reads the loader's line from the 16550 alone.
  • The split holds at most HEAD.len() - 1 bytes before the kernel begins, and nothing_before_the_kernel_passes asserts that.
  • It does not re-arm across a guest reset inside one QEMU process. No capture shows what stock edk2 writes on the port after such a reset, so no signal to re-arm on is measured. issues/build/the-kernel-console-split-does-not-re-arm-across-a-guest-reset.md records this, and KernelConsole's doc points there.
• Arch::firmware and Arch::pflash are deleted. Firmware::drives builds the two -drive values instead.
• CI. The guest containers' apt line (guest, tcg, audio) and src/sourcegate.rs's matching CI_PACKAGES row name ovmf-generic, the package that carries the chosen descriptor, rather than the ovmf metapackage whose amdsev/inteltdx siblings contribute only memory-mapped descriptors this reader skips. No CI job boots AArch64, so qemu-efi-aarch64 is not installed anywhere.
• The instrument line now includes the firmware code image each guest job ran on, and fails when no firmware is declared. ci::qemu_version is now the one place that asks QEMU its version.
• Deleted along with the files:
  • their NOTICE sections and the five COMMITTED_FILES rows;
  • licenses/BSD-2-Clause-Patent-EDK2.txt and licenses/Apache-2.0-OpenSSL.txt, which only those sections cited;
  • the NOTICE sentence and the README clause naming ovmf/;
  • the claim in toyos-acpi/fixtures/ovmf-pure-efi/SOURCE that its firmware is what every guest boots and that NOTICE names it;
  • issues/build/ovmf-s-licence-record-names-no-openssl.md, whose record went with the files;
  • issues/build/no-harness-test-boots-qemus-own-edk2.md. Its exit is met: lan_dhcp_lease and shipped_config_boots, which waits for compositor: ready and netd: ready, pass on QEMU's own edk2 (the 87629411 runs below).
• root_chunk_refused puts its EIO under an NVMe boot disk (the InternalDisk profile) instead of the USB stick. On QEMU's own edk2 the stick's read of that sector did not return, and the 60 s firmware watchdog did not reset the machine (the 572r3 measurement below). The blkdebug drive and the loader's BlockIO read are both unchanged, so the test still makes the same claim: a ROOT chunk the disk will not read refuses the boot, naming the chunk and DEVICE_ERROR.
  • root_chunk_refused_on_a_usb_stick is the same body on the Headless profile's stick. src/redlist.rs disables it behind issues/boot-media/an-unreadable-sector-on-a-usb-boot-stick-hangs-the-loader-past-the-firmware-watchdog.md, which is status: expected-red. The issue's exit is that test green and its row lifted. The issue also carries the former ovmf/ evidence: there the read returned, and then the stick went silent on the loader's next write. Real hardware is unmeasured.
  • BootOptions::stick_read_error is now boot_read_error, because it fails reads of the boot disk on whichever bus the profile puts it.
• issues/build/ftruncate-flush-race-reds-intermittently-and-nothing-says-why.md gains the orchestrator's five solo runs at 9082d6b4. Runs 1 and 3 were red, and in each all 10 attempts missed.

Net lines against ec06384e at this head (git diff --numstat origin/main...HEAD):

• production Rust (src/arch.rs, src/ci.rs, src/firmware.rs and src/kernelconsole.rs less their test modules, src/lib.rs, src/licence.rs, src/qemu.rs, src/redlist.rs, src/sourcegate.rs): +320/−73;
• tests (src/firmware.rs's 137 and src/kernelconsole.rs's 60 test-module lines, tests/common/qemu.rs, tests/common/serial.rs, tests/common/update.rs, tests/common/volumes.rs, tests/toyos.rs): +291/−46;
• NOTICE, README, fixture note, workflow, licence texts and issues: +113/−340, plus the 140,509,184 bytes of binaries git diff --numstat cannot line-count.

CI's firmware is not the Mac's

• Mac: QEMU's own edk2 build (edk2-stable202408-prebuilt.qemu.org). The kernel boots on QEMU's stock edk2, network included: the direct map ends at the last memory, every kernel root slot exists before the first user space, and a BAR's free run is a gap inside its width's space #563 was proven on this one.
• CI: Debian sid's ovmf-generic package, from Debian's edk2 source, in the sid index of 2026-09-17. Debian's qemu-system-x86 1:11.1.1+ds-1 is a repacked source whose Recommends name ovmf, and nothing in this tree has measured it shipping QEMU's own edk2-*.fd, nor whether its build writes to the virtio port.

The next nightly shows which firmware CI booted, on every guest job's instrument line.

Gates

At 4f65191d (logs in the job scratchpad's 572r5/):

gate	exit
cargo test --workspace --exclude toyos-build	0 (198 test result: ok lines, no FAILED)
cargo test -p toyos-build --lib	0 (401 passed, 2 ignored)
cargo test --test toyos-build -- --list	0 (lists root_chunk_refused_on_a_usb_stick and reports it disabled behind its issue)

cargo run -- --clippy, cargo run -- --ci host and cargo run -- --build-only last ran at 9082d6b4, each exit 0. They were not rerun at this head.

Measured against the real installation, without running QEMU (Homebrew QEMU 11.1.1):

• qemu-system-x86_64 -L help / qemu-system-aarch64 -L help: both print .../share/qemu-firmware (does not exist) then .../share/qemu (eight descriptors). x86_64 resolves to 60-edk2-x86_64.json, aarch64 to 60-edk2-aarch64.json.
• Neither /etc/qemu/firmware nor $HOME/.config/qemu/firmware exists on this Mac, so the earlier-precedence entries contribute nothing here; both directories are still read (search_dirs's own test).

The console split, host-tested. kernelconsole::tests feeds the 572r2 boot's firmware prefix and fused line cut at every byte, byte by byte, alone, and a port the firmware left alone. Each of four checked mutations built and turned them red (exit 101 each, reverted, file byte-identical):

• the split removed (pass returns its chunk): the fused-line and firmware-alone tests red, the firmware's bytes passed;
• the split only at a line start: the fused-line test red, the kernel's first record lost;
• no tail held across chunks: the fused-line test red at a cut inside [kernel , and the untouched-port test red;
• the held.drain(..) line deleted, at 4f65191d: nothing_before_the_kernel_passes red on "362 bytes withheld, more than could begin the head".

Guest runs, by the orchestrator

At 87629411 (the branch before the console split), on Homebrew QEMU 11.1.1's own edk2: lan_dhcp_lease exit 0. shipped_config_boots and inspect_reads_its_owners passed in the Fast tier.

At 09804e8d (logs 572r3-* in the job scratchpad's orch-runs/):

• root_named_twice_on_the_boot_disk: exit 0. --nightly c_capture_ignores_daemon_lines: exit 0.
• The harness's split, reverted (the stdio reader passing everything through): c_capture exit 1, on "42 line(s) that no name … accounts for".
• The Fast tier: 395 passed, 1 failed. --nightly: 515 passed, 1 failed. The red in both is root_chunk_refused, "Boot timed out waiting for Slot A: ROOT: the read of".
• root_chunk_refused, with the deadline lifted to 150 s and each 16550 line stamped (572r3-root-chunk-measure.log): exit 1, Boot timed out at 150 s.
  • Firmware watchdog: 60 s came at 2.0 s, and Slot A: signed header … verifies at 3.0 s.
  • The kept 16550 (target/red-run-serial/toyos-tmp-4233-0/lane-0/uart-0.log) ends on that verifies line, and no other byte followed it.
  • With -no-reboot, a watchdog reset would have ended QEMU and the harness would have said QEMU died before. It did not. So the read did not return and the watchdog did not fire.
  • That is why the stimulus moved to NVMe.
• The negative control below: exit 1.

At 9082d6b4 (logs 572r4-*):

• root_chunk_refused on InternalDisk: exit 0, with [root] bad sector 219143: Slot A: ROOT: the read of 2048 blocks at LBA 219136 failed: DEVICE_ERROR, after 3145728 of 6291456 bytes read.
• The Fast tier: exit 0, 394 of 394 passed.
• ftruncate_flush_race alone, five runs, its redlist row lifted by an uncommitted local patch: runs 1 and 3 exit 1, runs 2, 4 and 5 exit 0.

At 4f65191d (logs 572r5-*):

• root_chunk_refused: exit 0.
• The Fast tier: exit 0, 394 of 394 passed.
• --nightly update_boots_the_new_kernel, update_refusals_boot_the_other_slot and update_falls_back_from_a_dying_kernel: exit 0 each.

High-risk: boot path and devices

Negative control, run by the orchestrator. The patch is #563's whole change reverted onto this branch: every file #563 touched except its tracker entries (revert-563.patch in the job scratchpad's firmware/). Run on the Mac, where the x86 guest is TCG qemu64, an AMD vCPU: cargo test --test toyos-build -- lan_dhcp_lease.

• At 09804e8d: exit 1, boot timeout (572r3-control-revert563.log). The kept 16550 (target/red-run-serial/toyos-tmp-24237-0/lane-0/uart-0.log) carries pmm: the firmware map calls 4288393216 bytes usable in 116 entries, and right after it EARLY PANIC: panicked at library/alloc/src/alloc.rs:659:9: memory allocation of 4096 bytes failed.
• That red shows the guest really runs on stock edk2. That edk2 hands the vCPU the HyperTransport reservation, which ovmf/ never named.
• An Intel KVM host has no such reservation, so this arm says nothing there.

Independent oracle: the stock edk2 firmware itself, third-party and unmodified, as QEMU's installation ships it. For the selection rule, QEMU's own descriptors are read by the rule QEMU's interop spec gives. For the console split, the byte stream that firmware put on the virtio port in the 572r2 nightly.

Unsure

• Firmware writes now persist within a guest. A writable store changes what firmware keeps across a reset inside one guest: boot entries and BootNext. The reset tests (update_*, blackbox_*_chain, usb_reset_*) are where that shows. They passed in the 572r2 and 572r3 nightlies.

🤖 Generated with Claude Code

https://claude.ai/code/session_01W6rME2DoqwjcYFStYHHY4j

[Japabu]

CI never ran at head 8a3e1777: the only run is ci 36401352412, where host is SKIPPED (its pull_request event carried draft), and the one run after gh pr ready (36401350032, at dfe61e50) was cancelled by the push, so no required check has a conclusion at this head.

NOT READY FOR REVIEW

[Japabu]

Review of #572 at 8a3e1777. CI host run 36401632873: conclusion success, every step success. Reviewer runs, logs in the review scratchpad: cargo test --lib exit 0 (six firmware::tests ok), cargo test --test toyos-build -- --list exit 0. Net: production Rust +247/−73, tests +128/−18, prose and data −387.

Measured here without booting anything:

• qemu-system-x86_64 -L help and qemu-system-aarch64 -L help both exit 0. Each prints /opt/homebrew/Cellar/qemu/11.1.1/bin/../share/qemu-firmware then .../bin/../share/qemu.
• share/qemu-firmware does not exist. share/qemu/firmware holds eight descriptors.
• Read by select's rule, x86_64 resolves to 60-edk2-x86_64.json (50-edk2-x86_64-secure.json is skipped) and aarch64 resolves to 60-edk2-aarch64.json.
• strings on both Homebrew binaries: the newest compiled-in machine types are pc-q35-11.1-machine and virt-11.1-machine, which is what machine_type("11.1.1") gives.
• Debian, from deb.debian.org: ovmf 2026.05-2 is a metapackage (Depends: ovmf-amdsev, ovmf-generic, ovmf-inteltdx). Its x86_64 descriptors are 40-secure-enrolled, 50-secure, 60-edk2-x86_64-amdsev.json (memory), 60-edk2-x86_64-inteltdx.json (memory) and 60-edk2-x86_64.json. That order resolves to 60-edk2-x86_64.json: /usr/share/OVMF/OVMF_CODE_4M.fd with OVMF_VARS_4M.fd.
• Debian qemu-system-x86 1:11.1.1+ds-1 carries /usr/share/qemu and pc-q35-11.1-machine.
• OVMF_VARS_4M.fd and Homebrew's edk2-i386-vars.fd have identical first 0x70 bytes, including the authenticated-store GUID at 0x48.
• revert-563.patch has the same hunks as git diff -R 51fe14c1^1 51fe14c1 -- . ':!issues'; only the a//b/ header prefixes differ. git apply --check exits 0 at this head, and no file The kernel boots on QEMU's stock edk2, network included: the direct map ends at the last memory, every kernel root slot exists before the first user space, and a BAR's free run is a gap inside its width's space #563 touched has changed since 51fe14c.

BLOCKER

• src/firmware.rs:66-67 — the search path is only -L help's data directories. /etc/qemu/firmware and $XDG_CONFIG_HOME/qemu/firmware (default $HOME/.config) are never read. QEMU 11.1.1's docs/interop/firmware.json requires "a list of files from all three locations", with the more specific directory's file taking effect and an empty one hiding the name. So a sysadmin's or user's override, or an emptied distro descriptor, is silently ignored, while the module header (lines 4-8) and the PR claim to follow that spec. Fix: put $XDG_CONFIG_HOME|$HOME/.config/qemu/firmware and then /etc/qemu/firmware ahead of the -L help directories; descriptors' earlier-wins already gives the spec's precedence. Add a test that goes red when either entry is dropped from the list.

NOTE

• src/firmware.rs:126-128 — no test covers the individual refusals. Each of these patches leaves all six firmware::tests green:

  • - && flash.executable.format == "raw";
  • f == "secure-boot" || f == "requires-smm" → f == "secure-boot";
  • is_none_or(|m| m == "split") → is_none_or(|_| true).

  Fedora-style hosts ship non-secure qcow2 descriptors ahead of the raw ones. Add a qcow2, a requires-smm-only and a "mode":"combined" descriptor ahead of 60-plain.json in the_first_non_secure_uefi_flash_descriptor_for_the_machine_wins.

• src/firmware.rs:148-164 — the multi-* matcher is speculative. All 13 descriptors measured (Homebrew 8, Debian 5) use only a trailing *. A strip-suffix prefix match, refusing any other metacharacter or a non-trailing *, is about 4 lines instead of 17, and the pc-*-11.* case goes.

• src/firmware.rs:103-106 — this is a third per-arch declaration that x86 is q35 and aarch64 is virt, beside src/qemu.rs:292 and tests/common/qemu.rs:4405. src/arch.rs's header says a new machine question is an Arch method.

• src/firmware.rs:34 — std::fs::copy copies the template's mode bits. A read-only template (a 0444 store, as on Nix) gives a per-boot store that readonly=off cannot open, and makes the next copy over target/firmware-vars.fd fail. Unmeasured.

• .github/workflows/nightly.yml:109, src/sourcegate.rs:747 — ovmf is a metapackage. The chosen descriptor belongs to ovmf-generic, and the amdsev/inteltdx packages it drags in contribute only memory-mapped descriptors that are skipped.

• issues/build/no-harness-test-boots-qemus-own-edk2.md (deleted) — this close stands only on the orchestrator's Mac run. It needs lan_dhcp_lease and a compositor-ready boot green, with the firmware at edk2-x86_64-code.fd. The branch itself carries no evidence that meets the exit condition.

• negative control — it is The kernel boots on QEMU's stock edk2, network included: the direct map ends at the last memory, every kernel root slot exists before the first user space, and a BAR's free run is a gap inside its width's space #563 whole, and its expected red is plausible: qemu64 is an AMD-vendor model, and the red is the recorded pmm: death on the HyperTransport reservation. The green arm is main before The kernel boots on QEMU's stock edk2, network included: the direct map ends at the last memory, every kernel root slot exists before the first user space, and a BAR's free run is a gap inside its width's space #563 on ovmf/. The control proves which firmware runs, not the selection rule.

REMOVE

• src/arch.rs:4-5 — "; its firmware is whatever the host's QEMU declares (crate::firmware)" — added narration in a header about Arch; deleting "firmware image," was enough.
• NOTICE:18 — "Every hash is shasum -a 256, taken 2026-08-08." — false: the gbae hashes arrived 2026-09-05 (22c3f04).
• toyos-acpi/fixtures/ovmf-pure-efi/SOURCE:3 — "ovmf/OVMF_CODE-pure-efi.fd," — a path that no longer exists; the sha256 stays.
• issues/kernel/nothing-reds-when-the-bar-survey-drops-an-assigned-bar.md:14 — "and at 0x800200000 on ovmf/" — a citation of the deleted directory.
• PR body "Unsure": the "-L help is unmeasured" and "Debian's descriptors are unmeasured" bullets — both are measured above.
• PR body: "No --weekly tier exists in this tree; …" — not load-bearing.
• PR body: "Two tracker sentences are kept, because neither is shown false." — process narration.

SEND BACK

[Japabu]

Review of #572 at 87629411, round 3. CI host run 36407544818: head 87629411, conclusion success, no step other than success. Guest arms were run by the orchestrator on Homebrew QEMU 11.1.1's own edk2: 572r2-lan_dhcp_lease.log, 572r2-control-revert563.log, 572r2-fast.log and 572r2-nightly.log, plus the kept serial logs under target/red-run-serial/. Reviewer's own run: cargo run -- --known-red <t> exits 0 for all five reds, and each answers "NO, not disabled".

Net (git diff --shortstat origin/main...HEAD): 22 files, +463/−415. Production Rust is +272/−72. That is the numstat of src/ less firmware.rs's 138-line and arch.rs's 6-line test modules. Tests are +184/−23. Prose, data and workflow are +7/−320, plus 140,509,184 bytes of binaries. This round moved production by about +27 lines: firmware.rs went from 203 to 219 production lines, and Arch::machine is +10. The jump from +247 to +416 is the PR body now counting the 138 test lines as production.

Earlier findings

• BLOCKER src/firmware.rs search path — CLOSED. mutA-drop-etc.log and mutB-drop-userconfig.log each red the_users_and_the_systems_directories_come_before_qemus_own.

• NOTE refusals — CLOSED. note1-drop-{format,smm,mode}.log each red the_first_non_secure_uefi_flash_descriptor_for_the_machine_wins, on the descriptor named for the refusal it drops.

• NOTE glob, NOTE Arch::machine, NOTE template mode, NOTE ovmf-generic — CLOSED.

• NOTE negative control — CLOSED, and valid by the named mechanism. The kept 16550 log (red-run-serial/toyos-tmp-80187-0/lane-0/uart-0.log) shows:

  • the kernel starting, then pmm: the firmware map calls 4288393216 bytes usable in 116 entries …;
  • then EARLY PANIC: panicked at library/alloc/src/alloc.rs:659:9: memory allocation of 4096 bytes failed;
  • then panic: holding this panel ….

  The harness reported a timeout for three reasons. The early panic is on the 16550 alone. wait_for_ready (tests/common/qemu.rs:5157) reads the UART file only for a non-default marker. The timeout message quotes stdio alone. That gap is main's.

• The seven REMOVEs — CLOSED.

• NOTE no-harness-test-boots-qemus-own-edk2.md — superseded by the NOTE below.

BLOCKER

• tests/common/qemu.rs:4762, volumes.rs:3404, console.rs:546 — QEMU's edk2 writes its console output to the virtio-serial console, so the harness's stdio now carries firmware and loader output. main's ovmf/ never did: 554m-fast.log has no BdsDxe line.
  • About 42 such lines arrive before the kernel. The last is cut mid-line and fused onto the kernel's first record: Loader log: the kernel handoff begins, so [kernel 0.000 cpu0 boot] black box: … (nightly.log:1189-1231).
  • This reds root_named_twice_on_the_boot_disk: uart_log + boot_log now holds the same ROOT: read into memory line twice.
  • It also reds c_capture_ignores_daemon_lines, whose gate reads every non-kernel stdio line as userland's.
  • Both pass on main: 554m-fast.log has 397 of 397, and 562r2-nightly.log and 562r3-nightly.log pass c_capture.
  • Fix: every reader that takes stdio as the kernel's console starts at the kernel's first record, and a loader line is read from the 16550 file alone. No content dedupe, and nothing that depends on whether a given firmware routes there. Debian's ovmf-generic is unmeasured. Both tests must be green again, or be redlisted, each with its issue.
• tests/common/volumes.rs:3257 root_chunk_refused — on this firmware the loader never says Slot A: ROOT: the read of within the 20 s deadline.
  • The kept red-run-serial/toyos-tmp-95569-0/lane-0/uart-189.log ends at Slot A: signed header … verifies. The firmware's USB read of the EIO sector did not return in 20 s.
  • It passes on main (554m-fast.log: PASS root_chunk_refused (2s)).
  • Measure whether it ever returns before the loader's 60 s watchdog: the orchestrator boots it with the deadline lifted and reads the UART. Then either change the stimulus to one this firmware answers, or redlist it with an issue that records how the firmware behaves on an unreadable ROOT.

NOTE

• Nightly ftruncate_flush_race is main's. It is a VFS lock-timing verdict that firmware does not touch. issues/build/ftruncate-flush-race-reds-intermittently-and-nothing-says-why.md records it as intermittent on main-era trees, and it is not on the redlist. For the orchestrator: disable it with that issue.
• Nightly soundd_log_stall is not this branch's: an audio duration verdict with 1 underrun, which the owner rules metal-only. No QEMU test measures time, and audio is judged on metal only #562, which removes it, is open, and it is not on the redlist.
• issues/build/no-harness-test-boots-qemus-own-edk2.md — delete it in this branch.
  • Its first sentence ("Every harness boot uses the repository's ovmf/") is false once ovmf/ is gone.
  • Its exit condition is met at 87629411: lan_dhcp_lease exits 0 alone and passes in Fast and in the nightly, and shipped_config_boots passes in Fast (fast.log:1659). That test waits for compositor: ready and netd: ready on the --gop shape. inspect_reads_its_owners also passes (fast.log:1031).
  • The firmware is identified by the control's pmm: death and by the BdsDxe lines on stdio.
  • "The release probe" names nothing in the tree.
• src/arch.rs:207 each_arch_names_its_own_qemu_machine — it asserts the two literals the function returns and tests nothing. Delete it.
• src/firmware.rs:24, src/ci.rs:705-707 — Firmware::descriptor exists only to print the JSON path beside the code path, and the code path already names the firmware. Delete the field and "as {} declares it".
• For the orchestrator, outside this branch: a default-marker boot whose kernel dies before its virtio console reports "Boot timed out" and quotes no 16550 line (the control above). File it.

REMOVE

• tests/common/qemu.rs:3808-3810 — "Firmware, the bootloader and the kernel up to the backend switch write here and nowhere else" — false on the firmware this branch boots.
• src/arch.rs:113-115 — "and (with x86_64's PC lineage prefixed pc-) the family a firmware descriptor's machines glob is matched against" — restates machine_type's doc.
• PR body, net lines — "src/firmware.rs's own unit tests are a further 138 lines inside that production file" — misleading: the 138 are inside the +416.
• PR body — "issues/build/no-harness-test-boots-qemus-own-edk2.md stays open. Round 1 closed it …" — review chronology.
• PR body — the "Review r2's findings, checked" section — review chronology in main's record.
• PR body — the "Guest runs owed … (unchanged by round 2 — none of it runs QEMU here)" list — the runs happened; the record needs their exit codes and logs instead.

SEND BACK

[Japabu]

Review, round 4, at 9082d6b

CI host at 9082d6b4: COMPLETED SUCCESS. git merge-tree --write-tree origin/main HEAD exits 0 onto ec06384e. The orchestrator's runs at this head, clean tree (orch-runs/summary.txt, 572r4 lines):

• root_chunk_refused: EXIT=0. The log shows bad sector 219143: Slot A: ROOT: the read of 2048 blocks at LBA 219136 failed: DEVICE_ERROR, after 3145728 of 6291456 bytes read.
• Fast: EXIT=0, with 394 of 394 passed.
• ftruncate_flush_race, alone, 5 runs: runs 1 and 3 EXIT=1, runs 2, 4 and 5 EXIT=0.

Net lines (git diff --shortstat origin/main...HEAD): 26 files, +629/−450. Production Rust is +313/−73, tests +256/−37, and this round added about 40 production lines, most of them src/kernelconsole.rs's 45.

Earlier BLOCKERs

• tests/common/qemu.rs stdio carrying firmware and loader lines — CLOSED. At 09804e8d, 572r3-root_named_twice and 572r3-c_capture each exit 0. 572r3-c_capture-unsplit (the split reverted) exits 1 on "42 line(s) that no name … accounts for". root_named_twice_on_the_boot_disk also passes in 572r4-fast.log.
• tests/common/volumes.rs root_chunk_refused — CLOSED.
  • 572r4-root_chunk_refused.log exits 0. The refusal names the computed bad sector's chunk and DEVICE_ERROR, so the injected EIO reached the loader.
  • The claim is the same: the same Disk::read_root, the same BlockIO read and the same four assertions. Only the transport under them changed.
  • What moved is the transport. On USB the test red as a hang, not as a wrong refusal. That hang now has no test (NOTE below).

BLOCKER
(none)

NOTE

• issues/build/ftruncate-flush-race-reds-intermittently-and-nothing-says-why.md — required in this PR, because it changes the firmware every guest boots.
  • Add a table row: stock edk2 (Every guest boots the UEFI firmware the host's QEMU declares; ovmf/ and aavmf/ go #572 at 9082d6b4), alone, 5 runs, 2 fail (runs 1 and 3), 3 pass.
  • Add the fact the red logs show: in each red run all 10 attempts missed. There are ten STALLED WINDOW HELD lines about 410 ms apart, ten flusher exits, then the panic. The failure is all-or-nothing per boot.
  • This is not a landing precondition. The issue's table already has a main-era red when run alone (1 of 3, reverted arm). 2 of 5 against 1 of 9 is not separable: the hypergeometric two-sided p is 0.51, computed with awk. The test is disabled on main behind an orchestrator-held issue, and it passed in this branch's 09804e8d nightly.
  • The measurement that separates firmware from tree is fb34346e (on ovmf/) run alone 5 times beside this head. That is the orchestrator's to run.
• issues/boot-media/an-unreadable-sector-on-a-usb-boot-stick-hangs-the-loader-past-the-firmware-watchdog.md — it has an owner and a checkable exit, but it omits the tree's own evidence and says nothing about hardware.
  • Missing evidence: the volumes.rs comment this commit deleted recorded that on ovmf/ the stick QEMU failed a read on "answers the loader's next write to loader.log with nothing". So the stick went silent after the EIO under both firmwares. The common factor is QEMU's usb-storage, which bears directly on "does not show which side".
  • Hardware: the measurement is QEMU TCG only, and QEMU is not the hardware. The file must say whether a stick boot on a real machine hangs is unmeasured, instead of letting the title generalise.
• tests/common/volumes.rs:3277 — the USB arm was replaced, not disabled, so nothing reds on the hang. The issue's exit names "a guest test that stages this EIO … on a USB boot stick", and none exists.
  • Keep that arm as a second test over the same body, with the default profile, redlisted behind the issue.
  • The issue then becomes status: expected-red, and its exit is a lifted row.
• tests/common/qemu.rs:2394-2397 — the only caller of stick_read_error is now an NVMe boot disk, but the field name and its doc still say "boot stick". Rename it to the boot disk.
• tests/common/update.rs:284 and tests/common/serial.rs:255 — both still spell the literal "[kernel ". The commit and PR body call kernelconsole::HEAD "the [kernel head's one declaration". Make both read HEAD.
• src/kernelconsole.rs:184 — once held is None, everything passes. After a guest reset inside one QEMU process, the second boot's firmware prelude and its fused Loader log: … so [kernel line reach every stdio reader as kernel console. Nothing is red on it: the 09804e8d nightly passes the reset tests.
• src/kernelconsole.rs:192 — deleting the held.drain(..) line leaves all three tests green, because the output is identical. held then keeps every pre-kernel byte, and each chunk rescans all of them. To make that mutation red, add assert!(console.held.as_ref().unwrap().len() < HEAD.len()) after a firmware-only pass in nothing_before_the_kernel_passes.

REMOVE

• PR body — "At 9082d6b4 (this head), owed:" and its three bullets — the runs happened. The record needs their exits (above), and the USB timeout is not a red arm of the NVMe claim.
• PR body, Unsure — "That edk2's NVMe driver answers the failed read. … has not run yet. …" — false: it ran, EXIT=0.
• issues/boot-media/an-unreadable-sector-on-a-usb-boot-stick-hangs-the-loader-past-the-firmware-watchdog.md:64-65 — "The test was written against the tree's former ovmf/ image, and it asserts DEVICE_ERROR from this same read." — chronology, and it implies the old firmware handled the stick cleanly, which the deleted comment contradicts.

LAND AFTER NAMED CHANGES

[Japabu]

Review, round 5, at 4f65191

CI host at 4f65191d: COMPLETED SUCCESS (run 36448813636). git merge-tree --write-tree origin/main HEAD exits 0 onto ec0a91ad. The orchestrator's runs at this head on a clean tree (orch-runs/summary.txt, 572r5 lines): root_chunk_refused EXIT=0; Fast EXIT=0, 394 of 394; --nightly update_boots_the_new_kernel, update_refusals_boot_the_other_slot and update_falls_back_from_a_dying_kernel EXIT=0 each. 572r5-update3 EXIT=1 is the harness refusing three filters in one run, not a test. root_chunk_refused_on_a_usb_stick is reported as disabled behind its issue in 572r5-update_refusals_boot_the_other_slot.log.

Net lines (git diff --shortstat origin/main...HEAD): 31 files, +724/−459. Production Rust is +320/−73 and tests +291/−46 (numstat, test modules apart). This round (791d2b69..4f65191d) is +113/−27, of which production is 3 doc lines and the 4-line redlist row.

Earlier BLOCKERs: round 4 had none. Round 4's items:

• ftruncate issue row and all-or-nothing fact: CLOSED (issues/build/ftruncate-flush-race-reds-intermittently-and-nothing-says-why.md:23, :30-32).
• USB-hang issue evidence and hardware line: CLOSED. One sentence added with them is REMOVE (below).
• USB arm kept as a redlisted test: CLOSED. root_chunk_refused_on_a_usb_stick is main's test body on Profile::Headless, which is BootOptions::default()'s profile. The redlist row is in place, the issue is status: expected-red, and its exit is that row lifted.
• stick_read_error rename: CLOSED (boot_read_error, with its doc).
• "[kernel " literals in update.rs and serial.rs: CLOSED (is_kernel_line, kernelconsole::HEAD).
• held.drain(..) mutation: CLOSED. The PR body reports exit 101 on "362 bytes withheld". 362 is the byte length of the FIRMWARE fixture (printf … | wc -c = 362), which is what held keeps with no drain, so the reported red is the one this mutation must produce.
• Kernel console reset re-arm, filed rather than fixed: the decision is ACCEPTED.
  • Re-arming needs a signal in the post-reset stream, and no log shows that stream. The implementer cannot run a guest.
  • No consumer decides wrongly on it today. The only virtio-profile boot with takes_the_reset is Rig::boot (tests/common/update.rs:130). Its readers are owed (a substring past an offset), await_machine (byte growth) and loader_said (the 16550). Serial::interleaved is not called on it.
  • The issue has evidence, a checkable exit and an owner. The capture it names is cheap for the orchestrator: one update_boots_the_new_kernel run with an owed needle made absent, so the Err prints the console past the reboot.
• Round 4's three REMOVEs: CLOSED. All three are gone from the PR body and the issue.

BLOCKER
(none)

NOTE

• issues/build/ftruncate-flush-race-reds-intermittently-and-nothing-says-why.md:23 — add the orchestrator's control row beside the stock-edk2 row: cd2e6307, committed ovmf/, alone, 5 runs, 1 fail (run 5), 4 pass (summary.txt ftr-main solo-1..5). This branch added the edk2 row without its control, and on its own that row reads as the firmware being implicated. With the control it is not.

REMOVE

• issues/boot-media/an-unreadable-sector-on-a-usb-boot-stick-hangs-the-loader-past-the-firmware-watchdog.md:36-37 — "The factor common to both is QEMU's usb-storage answer to a failed data phase." — misleading. ovmf/ was an EDK II build too (origin/main:README.md:346), so edk2's USB stack is common to both runs as well. The sentence contradicts the next paragraph's "does not show which side". Round 4's own wording seeded it.
• PR body, Gates — "No guest run has been made at 4f65191d." — false: the orchestrator's 572r5 runs exist.
• PR body, console split — "Before this head's assertion, that mutation left all three tests green." — chronology.
• issues/build/ftruncate-flush-race-reds-intermittently-and-nothing-says-why.md:23 — "a later session" — not load-bearing.
• src/firmware.rs:167-168 — "Every glob measured across Homebrew's and Debian's descriptors is a plain prefix with at most one trailing *;" — where a measurement came from belongs in the commit, not the source. The refusal after it stands alone.

LAND AFTER NAMED CHANGES