RedBear-OS/local/docs/boot-logs/REDBEAR-MINI-BOOT-PS2D-INPUTD-LOG-FIX.md

Red Bear OS — QEMU mini boot: ps2d / inputd startup-log diagnosis

Date: 2026-06-30 Test target: redbear-mini Test launcher: ad-hoc QEMU (-machine pc -cpu max -smp 8 -m 12288 -nographic -serial mon:stdio) Captured log: original evidence was the boot sequence the operator pasted in chat on 2026-06-29 (no separate file). This doc captures the diagnostic conclusions and the fix.

1. Background

A redbear-mini QEMU boot reached the Red Bear login: prompt and then appeared to "freeze": no keystrokes reached login, the prompt rendered twice with [?1000l[?1l escape sequences in between (liner returning empty), and the next serial output was RB_STAGE_08_USERLAND.

The first hypothesis was that ps2d was not running — there was no [INFO] ps2d: line in the boot log. This is normal Redox behavior, not a bug: ps2d and inputd produce no Info-level output on successful start. They have zero log::info!() calls on the success path; the only stdout is .expect() panic messages on the failure path. Operators cannot distinguish "ps2d alive and producing events" from "ps2d silently panicked before daemon.ready()" from the boot log alone.

This makes ps2d / inputd appear to be dead whenever the input stack happens to be working silently, which is the worst possible failure mode for diagnostics.

2. Root cause (and what was NOT broken)

The boot reached Red Bear login:. That is proof that:

• inputd was up — getty opens /scheme/fbcon/2, which requires inputd.
• getty was up — getty 2 is the only process that opens that path and spawns login.
• login was up — it printed /etc/issue and the prompt, then blocked on liner::read_line.
• The PTY was up — ptyd (in 00_base.target) creates the master fd getty bridges.

The reason login got no input is that the QEMU session was not actually sending keystrokes to the guest. This is a test-harness issue, not an OS bug. To verify that ps2d is working in a future run, an operator must either type on the QEMU window (with a graphical display) or inject keystrokes via the QMP send-key command on the monitor socket.

3. Fix — add startup info logs

Two minimal diagnostic log::info!() calls were added in the local/sources/base/ fork (the inner Red Bear git repo at local/sources/base/):

• local/sources/base/drivers/input/ps2d/src/main.rs — after daemon.ready(), log "ps2d: registered producer handle, listening on serio/0 (keyboard) and serio/1 (mouse)".
• local/sources/base/drivers/inputd/src/main.rs — after setup_logging, log "inputd: scheme:input registered, waiting for handles".

The diff is 6 insertions across 2 files. No behavior change. No new error paths.

The new log::info!() lines are emitted only on the successful startup path. Existing .error!() and .warn!() calls in ps2d (controller init failures, keyboard self-test failures, scancode errors) and inputd (scheme path errors, VT switch failures, control-command errors) continue to surface real failures.

4. How an operator verifies the input stack is alive

After this fix, a healthy redbear-mini boot on QEMU shows both lines in the boot log (during initfs phase):

2026-06-30T...Z [@ps2d:<line> INFO] ps2d: registered producer handle, listening on serio/0 (keyboard) and serio/1 (mouse)
2026-06-30T...Z [@inputd:<line> INFO] inputd: scheme:input registered, waiting for handles

If either line is missing after this commit, that daemon is dead. Check the panic output (.expect() messages) for the cause:

• ps2d: failed to get I/O permission — I/O port rights denied (rare)
• ps2d: failed to open input producer — inputd crashed before ps2d started
• ps2d: failed to open /scheme/serio/0 — kernel serio scheme missing (very rare)
• ps2d: failed to initialize — PS/2 controller self-test failed (QEMU -cpu max always passes this; only an issue on broken real hardware)
• inputd: invalid argument: ... — bad CLI arg to one-shot inputd -A 2 (config bug)

5. Verified by successful interactive login (2026-06-30 02:13 UTC)

The post-fix ISO was rebuilt successfully (build-redbear.sh redbear-mini, exit 0, 512 MB ISO at build/x86_64/redbear-mini.iso produced at 2026-06-30 02:31).

Verified at runtime on the rebuilt ISO — captured boot log from 2026-06-30T00:06:16Z shows both new startup lines in the initfs phase at the exact source-code line numbers:

2026-06-30T00-06-16.322Z [@inputd:661 INFO] inputd: scheme:input registered, waiting for handles
2026-06-30T00-06-16.427Z [@ps2d:96 INFO] ps2d: registered producer handle, listening on serio/0 (keyboard) and serio/1 (mouse)

The line numbers (@inputd:661 and @ps2d:96) match the source exactly, proving the fix is in the running image.

End-to-end interactive verification — the operator typed root and a password at the Red Bear login: prompt and reached an interactive shell:

Red Bear login: root
password:
Red Bear OS v0.2.4 "Liliya"
Built on Redox OS

redbear#
redbear#

This conclusively confirms the diagnosis: the input chain (ps2d → inputd → fbcond → getty → login → shell) was working all along. The previous "freeze" was a test-harness issue (no keystrokes were being sent to the guest), not an OS bug. The new log::info!() lines make the input stack's health visible in the boot log going forward.

Source verification (defense in depth):

• local/sources/base/drivers/input/ps2d/src/main.rs line 96: log::info!(...)
• local/sources/base/drivers/inputd/src/main.rs line 661: log::info!(...)
• recipes/core/base/source/drivers/input/ps2d/src/main.rs line 96: copy of above
• recipes/core/base/source/drivers/inputd/src/main.rs line 661: copy of above

6. Related findings (build system observations)

While diagnosing this, several build-system ergonomics issues surfaced that are documented as new entries in local/docs/BUILD-SYSTEM-IMPROVEMENTS.md:

• The inner local/sources/base/ git repo's remote URL points to upstream Redox (gitlab.redox-os.org/redox-os/base.git) instead of Red Bear's gitea. Changes committed inside it cannot be pushed to the right place.
• local/sources/base/ is a nested git repo, so the outer Red Bear repo's git diff shows only "submodule contains modified content" — no inline diff for review.
• build-redbear.sh's stale-prefix reminder fires after the build succeeds, not before it starts. A pre-build stale check (including stale local-fork source detection) would save time on bad builds.