vasilito
d7ee730975
Reference analysis for Red Bear OS integration based on running the latest CachyOS desktop ISO (28 Jun 2026) under QEMU/KVM. Documents the hardware-enumeration and kernel-init sequences a reference Linux distro produces on the i440FX + PIIX machine type that Red Bear OS also targets, with line-by-line mapping to Red Bear OS subsystems (pcid, ided, e1000d, vesad, xhcid, hwd/acpid). - local/docs/CACHYOS-INTEGRATION.md: Cross-cutting analysis (executive summary, hardware inventory, ACPI table coverage, PCI quirks, boot-phase ordering, init system comparison, action items). - local/docs/boot-logs/cachyos-kernel-20260629-0520.log: Captured 441-line dmesg-grade log from the CachyOS kernel boot (SeaBIOS handover through ACPI, PCI, USB, ATA, network enumeration and up to a rootfs shell prompt). - local/docs/boot-logs/cachyos-boot-20260629-0520.md: Pointer document with the capture command and the rationale for the indirect-kernel invocation (the QEMU + CachyOS + KVM boot stalled at the ISOLINUX EDD probe when run from CD; bypassing with -kernel/-initrd and an explicit console=ttyS0 earlyprintk command line recovered the full log). Sources used: https://cachyos.org/ (release info) and the on-disk ISOLINUX + archiso boot path extracted from cachyos-desktop-linux-260628.iso.
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