builder: test the guest console for kernel output rather than a version string - #63
Conversation
…on string The console discriminator matched `gnumach|mach operating system|mach N.N`, and a measured transcript of a guest booted with console=com0 carries that string exactly once, in the /etc/issue login banner a getty writes; no kernel line carries it. A serial port that reaches a getty while the kernel writes to VGA therefore produced a version string and no kernel message, which is the arrangement the falsifier exists to exclude, so the check would have reported an unobserved falsifier as an observable one. The pattern now matches lines only the kernel writes -- the APIC entries, the IOAPIC GSI configuration, the IRQ overrides, the RTC time, the timer calibration, and the multiboot module echo -- and it is anchored past the carriage return a CRLF serial console leaves at the start of every line, without which a column-zero anchor matches nothing in a transcript full of kernel output. It finds 22 lines in the measured transcript, zero in a firmware-only one, and zero in a login-banner-only one. The probe that measured this also settles how to reach the observation: GRUB_CMDLINE_GNUMACH="console=com0" plus update-grub inside a disposable overlay writes console=com0 onto all three generated multiboot lines, the guest answers SSH 40 seconds after the reboot, and the transcript grows from 338 to 18796 bytes. The base is untouched, so roadmap 73b needs no re-cut and no rebinding of the lock. Assisted-by: Claude Code (claude-opus-5[1m])
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
📝 WalkthroughMechanism
Behavioral effect
Evidence and validation
Risk and reviewer focus
WalkthroughThe change tightens serial-console validation. The executor now requires GNU Mach kernel markers, tolerates CRLF and indentation, rejects login-banner-only transcripts, and tests the behavior with a getty-console scenario. Roadmap and evidence documentation describe the validation procedure. ChangesSerial console kernel-output validation
Estimated code review effort: 2 (Simple) | ~10 minutes Poem
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
A correction to my own PR #59, found by probing the mechanism instead of reasoning about it.
The defect
PR #59 added a discriminator so that zero Mach matches in a transcript could not be read as zero Mach errors. It tested for
gnumach|mach operating system|mach [0-9]+\.[0-9].I booted the base on a disposable overlay with
console=com0and measured what actually arrives. The version string appears exactly once in 18796 bytes — in the/etc/issuelogin banner a getty writes:No kernel line carries it. Kernel output looks like this:
So a serial port that reaches a getty while the kernel writes to VGA yields a version string and no kernel message — exactly the arrangement the falsifier exists to exclude. The check would have called that console observable.
Second defect in the same line
A serial console terminates lines with CRLF, so every line after the first begins with the previous line's carriage return. My first corrected pattern anchored at column zero and found 0 matches in a transcript containing 22 such lines. The anchor now absorbs the leading carriage return and the ACPI report's indentation.
console=com0bootWhat the probe settled for ROADMAP 73b
Falsification criteria were stated before the run:
update-grubwritesconsole=com0onto the multiboot lineserial.logThe change lives in the disposable overlay, so 73b needs no re-cut of the base and no rebinding of the lock, its status, or its closure. The Hurd's
/usr/bin/consoledoes report a timeout oncecom0owns the console; the boot continues through runlevel 2 andsshdstarts.An unrelated finding the probe surfaced
The first probe run produced no
serial.logat all. Cause: the localgnu-hurd-docker:latestimage was built 2026-07-26 and its entrypoint contains zero occurrences ofQEMU_SERIAL_LOGagainst 6 in the working tree — it predates PR #59 entirely, and the probe silently ran a stale entrypoint.That is the hazard PR #62's
builder_containerblock exists to make visible, now demonstrated as live rather than hypothetical. It also means the next real build run must verify the image matches the tree before drawing conclusions from it.Evidence
tests/builder-batches/executor-selftest.pygains a login-banner-only transcript case; it fails against the previous pattern.lint,validate,links(426/0), all three batch selftests,build-run-postconditions,builder-lock-selftest,builder-batch-evidence-check.evidence/builder-batches/README.mdand ROADMAP 73b record the measurement.Assisted-by: Claude Code (claude-opus-5[1m])