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.