vms-dec: kill boot-console newline spam (operator's echoed RETURNs) + type-during-boot regression gate

[baron-3dl]

The bug (operator-reported, x86_64 + VAX)

The boot-to-login console showed obnoxious blank-line newline spam scattered through the boot output. Root cause is not the software emitting newlines — the boot output is clean. It is the operator's own RETURN keystrokes echoing.

tools/vms_login.c console_login() has an OPA0: "wake-on-RETURN" (vms-2213): it prints nothing and blocks until the operator presses RETURN before showing Username:. During the slow boot no prompt is visible, so an operator naturally mashes RETURN several times. The console tty is cooked/ECHO, so the kernel echoes each RETURN at type-time as a blank line, mixed into the boot narration. The existing tcflush() discards the leftover keystrokes but cannot un-print the blank lines the tty already echoed.

Why the "obvious" fix (ECHO-off in LOGINOUT) is insufficient — proven interactively

I first scoped ECHO-off to console_login()'s wake window. Interactive proof showed it caught almost none of the spam: the console log proves JOB_CONTROL forks LOGINOUT only at STARTUP.COM's tail (the final %RUN-S-PROC_ID line), so by the time console_login() runs the operator has already mashed RETURN throughout the long boot and the tty has already echoed every one. Longest echoed blank-line run: 16 before, still 8 with LOGINOUT-only ECHO-off.

PID 1 owns the console for the entire boot, so the echo must be silenced there. boot_console_disable_echo() (src/ovmx_init/ovmx_init.c) clears ECHO on /dev/console at the start of the flagless boot (and, on the conversational path, right after SYSBOOT> hands over — SYSBOOT> itself must keep echoing). termios is per-tty device state shared across the exec/fork chain to the same console, so it persists until LOGINOUT re-enables ECHO right before Username: (console_login() now forces ECHO on at the prompt). ECHO gates input echo only; boot output is untouched.

Also removes a redundant $ SHOW TIME from STARTUP.COM (it emitted a stray bare date line mid-boot; the banner already prints the date; the oracle boot capture shows none).

Interactive proof (x86_64, real vms.ko over qemu-system-x86_64), 15 RETURNs mashed during boot

BEFORE (origin/main) — longest blank-line run = 16:

%OVMX-I-MOUNTED, system disk DKA0: mounted
                       <-- 8 echoed blank lines here
%OVMX-I-SCSNODE, node name OVMX set from SYS$SYSTEM:OVMXVMSSYS.PAR
%STDRV-I-STARTUP, OpenVMX startup begun at 28-AUG-2026 16:26:37.01
                       <-- more echoed blanks
%OVMX-I-EXEC, system identity SYSTEM [1,4] established by the executive
                       <-- more echoed blanks
  28-AUG-2026 16:26:38.73        <-- stray SHOW TIME date line
The OVMX system is now executing the site-specific startup commands.
...
Username: SYSTEM

AFTER (this PR) — longest blank-line run = 1 (the two legit boot blanks), despite the same 15 RETURNs:

%OVMX-I-EXEC, VMS executive attached on /dev/vms

    OpenVMX V0.5-7 - OpenVMS-compatible
    28-AUG-2026 16:34:18.48

%OVMX-I-SYSDISK, mounting system disk DKA0:
%OVMX-I-MOUNTED, system disk DKA0: mounted
%OVMX-I-SCSNODE, node name OVMX set from SYS$SYSTEM:OVMXVMSSYS.PAR
%STDRV-I-STARTUP, OpenVMX startup begun at 28-AUG-2026 16:34:20.69
%OVMX-I-EXEC, system identity SYSTEM [1,4] established by the executive
The OVMX system is now executing the site-specific startup commands.
%INSTALL-I-ADDED, DECC$SHR.EXE installed
... (INSTALL lines) ...
%RUN-S-PROC_ID, identification of created process is 10000003
Username: SYSTEM

No echoed blank lines; no stray date line; Username: clean; SYSTEM logs in and the typed username echoes (ECHO restored).

Regression coverage CI structurally lacked

Every existing boot harness waits for Username: and only then feeds input, so none provokes the echo. New tests/qemu/test_console_boot_no_newline_spam.sh boots the real runtime, types RETURNs DURING the boot (before the prompt), and asserts no run of echoed blank lines precedes Username: while login still works. It measures the longest consecutive blank-line run in the pre-Username: segment:

• BEFORE (origin/main): run=16 -> RED
• LOGINOUT-only ECHO-off: run=8 -> RED (correctly still red; partial fix)
• This PR: run=1 -> GREEN (6/6)

Wired as ctest console_boot_no_newline_spam_e2e and a ci.yml console-newline-spam-e2e job (same OVMX_QEMU_FULL_E2E=1 opt-in convention as dcl-acceptance-e2e; SKIP treated as hard failure).

Both arches

The fix is entirely in shared userland: VAX LOGINOUT cross-compiles from the same tools/vms_login.c (tools/cross-vax/build-loginout-vax.sh) and VAX STARTUP.EXE/PID 1 from the same src/ovmx_init/ovmx_init.c (tools/cross-vax/build-ovmx-init-vax.sh). open("/dev/console") + termios ECHO are POSIX, available under NetBSD-vax. No new TU, so no VAX build-enum updates. x86_64 verified interactively; VAX applies identically by construction.

Regression check

test_job_control_console.sh on the fixed image: login + every console-behavior assertion passes (36/1). The one failure (OPERATOR.LOG missing '^%OVMX-I-VMSFS, ') is identical on origin/main (verified) — a pre-existing, unrelated kmsg-bridge/VMSFS assertion (likely stale post vms-165 vmsfs retirement), not touched by this change.

Follow-up (noted, not shipped here)

Removing the wake entirely (faithful oracle behavior: straight to Username:) risks a Username:/STARTUP.COM-tail interleave and re-exposing the empty-username machine-gun the tcflush guards. Left as a follow-up rung; this PR keeps the wake and kills the spam.

🤖 Generated with Claude Code