vasilito
41045fd2f1
Two documentation changes:
1. New file local/docs/boot-logs/REDBEAR-MINI-BOOT-PS2D-INPUTD-LOG-FIX.md
captures the 2026-06-30 diagnosis of why the mini boot appeared to
freeze at the login prompt. Records:
- The actual root cause (test harness not injecting keystrokes, not
an OS bug — ps2d/inputd were working silently).
- The committed fix (de9d1f4 in local/sources/base/ adds two
log::info!() startup messages so operators can verify the input
stack is alive from the boot log).
- The expected post-fix boot log lines and how to interpret them.
- Verification status (source-inspected; clean post-fix QEMU boot
pending due to slow bootloader streaming under -nographic).
2. Addendum appended to local/docs/BUILD-SYSTEM-IMPROVEMENTS.md
documenting four build-system ergonomics issues observed during
the diagnosis session:
- #11: local/sources/base/ inner git repo origin points to
upstream Redox instead of Red Bear gitea.
- #12: outer Red Bear repo cannot show inline diffs for the
nested local/sources/base/ git repo (submodule pointer dirty).
- #13: no preflight warning for stale local-fork source (a
4-line edit caused a 30+ min rebuild with no advance notice).
- #14: -nographic + OVMF boot is too slow for time-budgeted
post-fix QEMU verification; recommend BIOS + KVM path.
Both items are S-sized and could be picked up in any future hardening
session. No code changes in this commit.
Red Bear OS QEMU Boot Logs
This directory contains frozen QEMU boot evidence captured during validation runs of
the Red Bear OS desktop target (redbear-full). The files here are point-in-time
records and must not be edited to "update" build commands or package versions —
doing so would invalidate them as historical evidence.
What lives here
| File | What it captures |
|---|---|
REDBEAR-FULL-BOOT-RESULTS.md |
Reference QEMU boot capture (2026-06-09) |
REDBEAR-FULL-BOOT-EXTENDED-RESULTS.md |
Extended QEMU boot capture |
REDBEAR-FULL-BOOT-POST-VIRTIO-BLKD-FIX-RESULTS.md |
Post-virtio-blk fix boot capture (before/after record) |
Why these are frozen
These files are the project's ground-truth evidence that a specific Red Bear build booted, reached specific init stages, and exposed specific subsystem states at a specific commit. They are the only place where "this is what we saw" is preserved verbatim. Editing them retroactively — even to fix typos — would compromise the evidentiary value.
If a build command in here looks wrong
If a build command in one of these files looks outdated, the fix is not to edit the log. The correct action is one of:
- The command is still correct as-written. It was the right command at the time. Leave the log alone.
- The command is outdated and the corresponding validation is being re-run.
Write a NEW log file (e.g.
REDBEAR-FULL-BOOT-POST-QEMU-XYZ-FIX-RESULTS.md) with the new run's evidence. Do not edit the old one. - The command is wrong and no new validation is planned. Add a one-line
note at the bottom of the file: "Note: command X is now deprecated, see
local/docs/BUILD-SYSTEM-IMPROVEMENTS.mdfor current usage." Do not rewrite the original line.
Building the current redbear-full target
The canonical v6.0 build command is:
./local/scripts/build-redbear.sh redbear-full
This script enforces the v6.0 policies (local-over-WIP recipe priority, overlay
integrity, submodule hygiene, firmware presence warning) that bare make all /
make live invocations from older logs do not enforce.
QEMU boot
make qemu CONFIG_NAME=redbear-mini # Boot the latest built image in QEMU