Acceptance: riscv64 intermittently misses 'Boot disk: not a StarshipOS stick' (run 197) #131

New Issue

2026-11-07T19:15:36Z

rajames commented

2026-11-07 19:15:36 +00:00

What happened

Acceptance run 197 (PR #130, cabe9748, v4.0.0-alpha.2) failed one check on riscv64:

PASS: POST: PASSED
FAIL: Boot disk: not a StarshipOS stick (an ISO or ESP boot)
PASS: Zuse: identity confirmed
PASS: [zuse@Hera] ok>
PASS: 7  ok, and a prompt

Everything the boot is for passed; one line the check expects was not in the serial log. The gate (acceptance.yml) refused the PR on it.

Evidence so far

The kernel prints that line, one way or the other, on every boot (kernel/src/kernel_main.c:629): it was either not captured, garbled, or it said "a StarshipOS stick".
Not the firmware booting the Zuse stick: the stick is made with --esp-mib 0 (kernel/Makefile, zusestick) -- it has no ESP to boot.
The loader's probe (uefi_loader.c, the LoadedImage's device path) is not order-dependent.
The same tree boots and passes here 4 of 4 (logs/20261107-184616, -190906, -191105, -191304), each printing the line.
Left: the serial capture losing or interleaving bytes under load on the server (TCG, slow box). To check against run 197's own serial log (its logs artifact: logs/20261107-190612/riscv64/qemu-riscv64-20261107-190612.log).

Why it matters

A gate that fails at random either blocks good changes or teaches us to re-run until green. Captain Bob, 2026-11-07: "I think we make that a priority issue too."

Done when

Run 197's serial log read: what is where the line should be
The cause found and fixed -- in the capture (scripts/qemu_session.py), the serial setup, or the kernel -- not by loosening the check
The riscv64 acceptance passes repeatedly on the server (several runs) with the line present

Area

CI, acceptance (scripts/qemu_session.py), riscv64

🤖 Filed with Claude Code

### What happened Acceptance run **197** (PR #130, `cabe9748`, `v4.0.0-alpha.2`) failed one check on riscv64: ``` PASS: POST: PASSED FAIL: Boot disk: not a StarshipOS stick (an ISO or ESP boot) PASS: Zuse: identity confirmed PASS: [zuse@Hera] ok> PASS: 7 ok, and a prompt ``` Everything the boot is for passed; one line the check expects was not in the serial log. The gate (`acceptance.yml`) refused the PR on it. ### Evidence so far - The kernel prints that line, one way or the other, on **every** boot (`kernel/src/kernel_main.c:629`): it was either not captured, garbled, or it said "a StarshipOS stick". - Not the firmware booting the Zuse stick: the stick is made with `--esp-mib 0` (`kernel/Makefile`, `zusestick`) -- it has no ESP to boot. - The loader's probe (`uefi_loader.c`, the LoadedImage's device path) is not order-dependent. - The same tree boots and passes here **4 of 4** (`logs/20261107-184616`, `-190906`, `-191105`, `-191304`), each printing the line. - Left: the serial capture losing or interleaving bytes under load on the server (TCG, slow box). To check against run 197's own serial log (its `logs` artifact: `logs/20261107-190612/riscv64/qemu-riscv64-20261107-190612.log`). ### Why it matters A gate that fails at random either blocks good changes or teaches us to re-run until green. Captain Bob, 2026-11-07: "I think we make that a priority issue too." ### Done when - [ ] Run 197's serial log read: what is where the line should be - [ ] The cause found and fixed -- in the capture (`scripts/qemu_session.py`), the serial setup, or the kernel -- not by loosening the check - [ ] The riscv64 acceptance passes repeatedly on the server (several runs) with the line present ### Area CI, acceptance (`scripts/qemu_session.py`), riscv64 🤖 Filed with [Claude Code](https://claude.com/claude-code)

rajames added the

labels 2026-11-07 19:15:36 +00:00

rajames referenced this issue

2026-11-07 20:15:20 +00:00

CI: when an acceptance check fails, print the serial log around it #136

rajames added this to the v4.0.0-alpha.4 milestone 2026-11-07 20:16:00 +00:00