When an acceptance check fails, scripts/qemu_session.py now prints the serial log where the check looked, into the job's output: the lines after the first match of an anchor the check names, else the log's last lines. Control characters are shown as escapes (\x1b[...), so a stray byte or terminal sequence inside a line is visible instead of only failing a match. The boot-disk checks anchor on Boot successful!.
Run 197's riscv64 failure (#131) could only be read from the run's logs artifact, which Gitea's API does not list; the next failure explains itself in the log.
Also (171b3947): the demo -- two guests of 384 MiB (#116: v4 boots from 256 MiB, refuses at 128), and a visitor over the limit gets "Every StarshipOS machine is busy right now ... Try back in a few minutes." in the terminal, not a dead connection (start-session.sh slot locks; the service: DEMO_MAX_GUESTS=2, RuntimeDirectory, --max-clients 6). Takes effect when the demo is deployed (#115).
Acceptance
The Acceptance check runs on this pull request -- also the first full run with both wikis up (alpha.4's first server test).
Logs committed: a riscv64 acceptance here with the new script, passing and printing as before; excerpt() run against a real riscv64 serial log, with an anchor and without
Hardware this was tried on, if any: none
The record
docs/fabric/FABRIC-3.md -- not design work
CHANGELOG.md -- not a milestone
Nothing in this PR is a fix nobody asked for (.claude/CLAUDE.md, Hard Rules) -- #136, asked for 2026-11-07
## What and why
When an acceptance check fails, `scripts/qemu_session.py` now prints **the serial log where the check looked**, into the job's output: the lines after the first match of an anchor the check names, else the log's last lines. Control characters are shown as escapes (`\x1b[...`), so a stray byte or terminal sequence inside a line is visible instead of only failing a match. The boot-disk checks anchor on `Boot successful!`.
Run 197's riscv64 failure (#131) could only be read from the run's `logs` artifact, which Gitea's API does not list; the next failure explains itself in the log.
Closes #136. Part of #131.
**Also (171b3947): the demo** -- two guests of 384 MiB (#116: v4 boots from 256 MiB, refuses at 128), and a visitor over the limit gets "Every StarshipOS machine is busy right now ... Try back in a few minutes." in the terminal, not a dead connection (start-session.sh slot locks; the service: DEMO_MAX_GUESTS=2, RuntimeDirectory, --max-clients 6). Takes effect when the demo is deployed (#115).
## Acceptance
The **Acceptance** check runs on this pull request -- also the first full run with both wikis up (alpha.4's first server test).
- [x] Logs committed: a riscv64 acceptance here with the new script, passing and printing as before; `excerpt()` run against a real riscv64 serial log, with an anchor and without
- [ ] Hardware this was tried on, if any: none
## The record
- [ ] `docs/fabric/FABRIC-3.md` -- not design work
- [ ] `CHANGELOG.md` -- not a milestone
- [x] Nothing in this PR is a fix nobody asked for (`.claude/CLAUDE.md`, Hard Rules) -- #136, asked for 2026-11-07
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
rajames
added this to the v4.0.0-alpha.4 milestone 2026-11-07 22:49:18 +00:00
Run 197's riscv64 failure (#131) could only be read from the run's logs
artifact, which Gitea's API does not list. qemu_session.py's check() now
prints, on a FAIL, the serial lines after the first match of an anchor the
check names, or the log's last lines; control characters as escapes, so a
stray byte or terminal sequence in a line shows instead of only failing a
match. The boot-disk checks anchor on 'Boot successful!'. A passing run
prints as before (riscv64 here, logs/ committed).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Captain Bob, 2026-11-07: 'Limit guests and have a Busy, try back in a few
minutes.' start-session.sh takes one of DEMO_MAX_GUESTS slots (default 2),
a lock it holds for the session's life (flock -n: two visitors cannot both
take the last one; QEMU and the bridge are started without its descriptor);
with every slot taken, the visitor's terminal says every machine is busy and
to try back in a few minutes, and the session ends without a machine. The
service: DEMO_MAX_GUESTS=2, RuntimeDirectory for the locks, ttyd's
--max-clients 6 so a visitor over the limit reaches the message. The guest:
384 MiB (v4 boots from 256 MiB, refuses at 128; measured, #116). Tested
here: every slot held -> the busy message; slot 1 held -> slot 2 taken.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
rajames
changed title from acceptance: a failed check prints the serial log where it looked (#136) to acceptance prints the serial log of a failed check (#136); the demo limits its guests (#116)2026-11-07 23:18:50 +00:00
Today's rulings and work since XLVII.6, kept at the pace of the work
(Captain Bob, 2026-11-07: 'the book of fabric needs to keep pace'): the
alpha.4 list (#147) and what is in it, the developer protocol (#135), the
Book of Fabric (#138), the SDK milestone with the capsule repository (#149)
and the latency DoE (#150), #136 and the demo's guests and busy message,
with what was measured.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
rajames
merged commit 6bbf4b1afd into master2026-11-08 00:07:46 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
What and why
When an acceptance check fails,
scripts/qemu_session.pynow prints the serial log where the check looked, into the job's output: the lines after the first match of an anchor the check names, else the log's last lines. Control characters are shown as escapes (\x1b[...), so a stray byte or terminal sequence inside a line is visible instead of only failing a match. The boot-disk checks anchor onBoot successful!.Run 197's riscv64 failure (#131) could only be read from the run's
logsartifact, which Gitea's API does not list; the next failure explains itself in the log.Closes #136. Part of #131.
Also (
171b3947): the demo -- two guests of 384 MiB (#116: v4 boots from 256 MiB, refuses at 128), and a visitor over the limit gets "Every StarshipOS machine is busy right now ... Try back in a few minutes." in the terminal, not a dead connection (start-session.sh slot locks; the service: DEMO_MAX_GUESTS=2, RuntimeDirectory, --max-clients 6). Takes effect when the demo is deployed (#115).Acceptance
The Acceptance check runs on this pull request -- also the first full run with both wikis up (alpha.4's first server test).
excerpt()run against a real riscv64 serial log, with an anchor and withoutThe record
docs/fabric/FABRIC-3.md-- not design workCHANGELOG.md-- not a milestone.claude/CLAUDE.md, Hard Rules) -- #136, asked for 2026-11-07🤖 Generated with Claude Code
https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
acceptance: a failed check prints the serial log where it looked (#136)to acceptance prints the serial log of a failed check (#136); the demo limits its guests (#116)