vasilito
715fe8ac59
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent) Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
71 lines
2.8 KiB
Markdown
71 lines
2.8 KiB
Markdown
# redbear-info Runtime Report
|
|
|
|
`redbear-info` is the canonical Red Bear OS runtime integration and debugging command.
|
|
|
|
## Purpose
|
|
|
|
The tool is intentionally passive. It reports what the running system can actually prove through
|
|
read-only runtime surfaces instead of flattening everything into a single “available” bit.
|
|
|
|
It is meant to answer:
|
|
|
|
- what Red Bear integrations are installed,
|
|
- what services or schemes are actually active,
|
|
- what integrations passed a safe read-only runtime probe,
|
|
- whether networking is configured, including IP, DNS, and default route,
|
|
- whether key hardware discovery surfaces (PCI, USB, DRM, RTL8125, VirtIO NICs) are visible.
|
|
|
|
## Output model
|
|
|
|
Each integration is reported with one of these layered states:
|
|
|
|
- `absent` — no artifact or runtime surface was observed
|
|
- `present` — an artifact or config exists, but there is no live runtime proof yet
|
|
- `active` — a live runtime surface exists, but the probe cannot honestly claim full working order
|
|
- `functional` — a safe read-only runtime probe succeeded
|
|
- `unobservable` — no honest runtime proof exists for a deeper claim
|
|
|
|
This distinction matters because some Red Bear integrations compile or package cleanly before they
|
|
are hardware-validated at runtime.
|
|
|
|
## Current sections
|
|
|
|
`redbear-info` reports:
|
|
|
|
- **Identity** — OS name, version, hostname
|
|
- **Networking** — stack state, connected flag, interface, MAC, IP/CIDR, DNS, default route,
|
|
active `netctl` profile, visible `network.*` schemes
|
|
- **Hardware** — PCI device count, USB controller count, DRM card count, RTL8125 PCI visibility
|
|
- **Hardware** — PCI device count, USB controller count, DRM card count, RTL8125 PCI visibility,
|
|
VirtIO NIC visibility for VM baselines
|
|
- **Integrations** — tools, daemons, and integration paths such as `lspci`, `lsusb`, `netctl`,
|
|
`pcid-spawner`, `smolnetd`, `firmware-loader`, `udev-shim`, `evdevd`, `redox-drm`, and the
|
|
native RTL8125 and VirtIO networking paths
|
|
|
|
For Phase 3 runtime validation, `udev-shim` is expected at `/usr/bin/udev-shim` and `evdevd` is
|
|
expected at both `/usr/bin/evdevd` and `/usr/lib/drivers/evdevd` so service execution and runtime
|
|
reporting use the same binary identity.
|
|
|
|
## Commands
|
|
|
|
- `redbear-info` — human-readable report
|
|
- `redbear-info --verbose` — includes evidence and claim limits
|
|
- `redbear-info --json` — structured machine-readable output
|
|
- `redbear-info --test` — suggested follow-up diagnostic commands
|
|
|
|
## Maintenance rule
|
|
|
|
Whenever Red Bear adds or materially changes an integration, update `redbear-info` in the same
|
|
change set.
|
|
|
|
That includes new:
|
|
|
|
- user-facing tools
|
|
- scheme daemons
|
|
- services
|
|
- hardware integration paths
|
|
- configuration layers that users rely on to debug a running image
|
|
|
|
The goal is for `redbear-info` to remain the first command users run when they need to understand
|
|
the state of a Red Bear system.
|