RedBear-OS/local/docs/boot-logs/REDBEAR-FULL-BOOT-EXTENDED-RESULTS.md

Red Bear OS — Extended QEMU Boot Test Results (300 s)

Date: 2026-06-09 Test target: redbear-full with --fallback redbear-mini (full ISO still not built; the launcher used build/x86_64/redbear-mini/harddrive.img per the warning at startup) Test launcher: local/scripts/test-redbear-full-qemu.sh Test window: 300 s QEMU runtime (350 s host-side timeout wrapper) Captured log: redbear-full-boot-20260609-135308.log (16 988 bytes, 204 lines) Prior baseline: redbear-full-boot-20260609-125114.log (6 542 bytes, 96 lines, 75 s timeout) Reference: redbear-mini-20260430-210123.log (18 716 bytes, 220 lines, full text-only boot to login prompt)

---

1. Headline

The 300 s capture reached far beyond the 75 s baseline. Boot progressed through PCI enumeration, pcid-spawner, nvmed (multi-queue NVMe), virtio-blkd bring-up, and ahcid probe. It then panicked inside virtio-blkd during a write to the boot drive — the ISO is attached with readonly=on (per the launcher contract to protect the build artifact), and the driver received status = 1 (VirtIO BLK VIRTIO_BLK_S_IOERR) on what it expected to be a writable block device. The assert_eq!(*status, 0) on line 70 of drivers/storage/virtio-blkd/src/scheme.rs then aborted the daemon.

Result: the kernel caught the user-space invalid-opcode fault from the aborted daemon and reported UNHANDLED EXCEPTION, CPU #0, PID 19, NAME /scheme/initfs/lib/drivers/virti, CONTEXT 0xffffff7f8012bad0. No further daemons started after that point; the QEMU window ran out under timeout 300 s with the system sitting at the unhandled-exception message.

Login prompt: not reached. D-Bus, KWin, SDDM, evdevd: not reached.

---

2. Boot Stages Reached — Comparison

Stage	75 s baseline	300 s extended	Reference (full boot)
UEFI firmware (OVMF)	✅	✅	✅
Red Bear OS Bootloader 1.0.0	✅	✅	✅
RedoxFS discovery on disk	✅ (00b1129e-…)	✅ (f0509f4b-…)	✅
Kernel RedBear OS starting…	✅	✅	✅
x2APIC detection	✅ (QEMU firmware bug WARN)	✅ (same WARN)	✅
ACPI AML interpreter v6.1.1	✅	✅	✅
ACPI GPE handler (SCI on IRQ 9)	✅	✅ (one line later)	✅
Quirk system (redox_driver_sys::quirks::dmi)	✅ (DMI empty)	✅ (DMI empty)	✅
vesad no boot framebuffer	⏳	✅	n/a (redbear-mini)
fbbootlogd / fbcond no display	⏳	✅	n/a
hwd ACPI backend	⏳	✅	✅
pcid PCI enumeration (9 devices)	⏳	✅	✅
pcid-spawner driver dispatch	⏳	✅	✅
nvmed (QEMU NVMe Ctrl, NVME_EXTRA)	⏳	✅ (multi-queue)	n/a
virtio-blkd bring-up	⏳	✅ (startup sequence, disk size 1.5 GiB)	✅
ahcid AHCI probe (with expected empty-port I/O error)	⏳	✅	✅
virtio-blkd write assertion (panicked)	⏳	❌ PANIC (left: 1, right: 0)	n/a
iommu daemon	⏳	❌ (panic before)	✅
evdevd (v6.0 input arch)	⏳ (last line)	❌	✅
init switchroot to /usr	⏳	❌	✅
D-Bus system bus	⏳	❌	✅
redbear-sessiond / redbear-polkit / redbear-udisks / redbear-upower	⏳	❌	✅
redbear-netctl / DHCP	⏳	❌	⚠️
cpufreqd / thermald	⏳	❌	✅
Red Bear login: prompt	❌	❌	✅
SDDM / KWin / Wayland compositor	⏳	⏳ (redbear-mini has none)	n/a

✅ reached · ⏳ not yet reached (boot still in progress when timeout killed QEMU) · ❌ failed (panic/abort) · n/a not applicable to text-only target.

---

3. What New Boot Stages Were Reached (vs 75 s)

The 300 s window exposed substantially more userspace boot progression than the 75 s capture:

• vesad early-boot framebuffer handoff — vesad: No boot framebuffer (QEMU has no linear framebuffer, expected)
• fbbootlogd / fbcond — both report No display present yet (expected for the -vga none launcher; this is the documented NO-VESA early-boot path, see AGENTS.md "NO VESA POLICY")
• hwd ACPI backend — using ACPI backend confirms hardware detection daemon is up
• Full PCI enumeration — pcid lists 9 devices, all on bus 00:
  • 00:00.0 8086:29C0 — Q35 host bridge
  • 00:01.0 1B36:000D — qemu-xhci (class 0x0c, XHCI)
  • 00:02.0 8086:293E — IGD (class 0x04, graphics — no display, expected with -vga none)
  • 00:03.0 1AF4:1000 — virtio-net (class 0x02, network)
  • 00:04.0 1B36:0010 — QEMU NVMe Ctrl (class 0x01, NVME)
  • 00:05.0 1AF4:1001 — virtio-blk (class 0x01, mass storage)
  • 00:1f.0 8086:2918 — ISA bridge
  • 00:1f.2 8086:2922 — SATA AHCI controller
  • 00:1f.3 8086:2930 — SMBus
• pcid-spawner — successfully spawns nvmed, virtio-blkd, and ahcid via the per-class scheme channel protocol
• MSI-X first-use case — kernel::scheme::irq:WARN -- MSI vector 50 arrived before IOMMU remapping was activated. This is normal in QEMU or when no IOMMU is present. — nvmed received an MSI before the IOMMU remap completed, which the kernel classifies as expected
• Multi-queue NVMe bring-up — nvmed identifies QEMU NVMe Ctrl 11.0.0 Serial: NVME_EXTRA, NSID: 1, Size: 2 097 152 sectors (1 GiB)
• virtio-blkd bring-up — initiating startup sequence :), disk size 3 145 728 sectors × 512 B = 1.5 GiB (the redbear-mini harddrive.img)
• ahcid probe — 4 ports scanned; port 2 reports QEMU DVD-ROM SATAPI with expected IS 40000000 IE 17 CMD 3000006 TFD 2041 / SSTS 113 SCTL 700 SERR 0 SACT 0 / 2: I/O error (the QEMU ISO port fails to read because the live CD is bound to a different transport in this QEMU profile)

The capture ends with the kernel handling the virtio-blkd panic.

---

4. Why the Boot Stopped

The panic source is a precise assert_eq!(*status, 0) on a VirtIO Block write status byte. The driver performs a write (init-time metadata sync or similar) against the boot drive, but the drive is attached via -drive file=…,format=raw,if=virtio,snapshot=on,readonly=on per the launcher contract:

local/scripts/test-redbear-full-qemu.sh:259
    -drive file="$image",format=raw,if=virtio,snapshot=on,readonly=on

Per the VirtIO Block specification, when a device rejects a write the status byte is set to VIRTIO_BLK_S_IOERR = 1. The driver currently treats any non-zero status as a fatal condition, asserts, and aborts.

Two possible responses (no fix attempted — out of scope for this test task):

1. Don't attempt writes on a readonly=on drive. virtio-blkd could detect the RO feature bit and skip metadata writes; or the launcher could omit readonly=on and rely on snapshot=on alone for the boot drive (the snapshot mode discards writes on shutdown, achieving the same protection without forcing a hard read-only state mid-session).
2. Convert the assertion to a recoverable error. A real Red Bear fix would replace assert_eq!(*status, 0) with a Result-based error path so a single failed write logs a warning and returns EIO to the caller instead of aborting the whole driver.

The task explicitly forbade modifying the system or kernel during the test, so no fix is being applied here. This is a documentation-only finding for the upstream fix track.

---

5. D-Bus System Bus

Not reached. D-Bus services are launched by the init system in the rootfs switchroot (after the init: switchroot to /usr /etc line). Boot panicked during the initfs driver bring-up, before the second switchroot, so neither dbus-daemon nor any redbear-* D-Bus service (login1, PolicyKit, UPower, UDisks2) had a chance to start.

The reference log (full boot, May 15) shows what D-Bus activation looks like when the system does reach that stage; see REDBEAR-FULL-BOOT-RESULTS.md section 7 for the full registration transcript.

---

6. KWin / SDDM

Not reached. These are part of the redbear-full desktop stack (Mesa EGL/GBM/GLES2, libwayland, kwin, sddm, KDE Plasma). They do not run in redbear-mini and would not be reachable even with a successful boot of this text-only target. The current ISO the test fell back to is build/x86_64/redbear-mini/harddrive.img, which does not include any graphical packages.

To exercise the desktop surface a redbear-full ISO must be built first (currently not present — build-redbear.sh ran out of the 600 s build budget; see REDBEAR-FULL-BOOT-RESULTS.md section 1).

---

7. Login Prompt

Not reached. Login is offered by ion / the getty-style service after the second switchroot (/usr). The capture is still in the first switchroot (/scheme/initfs) when the virtio-blkd panic halts the driver-registration phase.

The reference log shows the Red Bear login: prompt appearing reliably once userspace init finishes (~10 s in the reference; the prior baseline notes 180–300 s as a safe window — the new finding is that, with this build, we panic before that, so timing is moot).

---

8. Visible Errors and Warnings

Severity	Source	Message	Impact
INFO	BdsDxe	failed to load Boot0002 "UEFI QEMU NVMe Ctrl NVME_EXTRA 1"	Expected — NVME_EXTRA is the extra scratch disk, not the boot target
INFO	vesad	No boot framebuffer	Expected — -vga none per launcher; vesad is early-boot handoff only, not primary surface
ERROR	fbcond::display	fbcond: No display present yet: Invalid argument	Expected — same as above
WARN	redox_driver_sys::quirks::dmi	cannot read DMI from /scheme/acpi/dmi	Expected — QEMU OVMF has no SMBIOS; DMI rules inert
WARN	kernel::acpi::madt::arch	x2APIC mode active but no LocalX2Apic entries	QEMU OVMF firmware bug; kernel recovers via zero-extended IDs
WARN	kernel::acpi::madt::arch	duplicate APIC ID 0 in LocalApic entry (x2APIC fallback)	Same firmware bug; recovery is automatic
WARN	kernel::scheme::irq	MSI vector 50 arrived before IOMMU remapping was activated	Expected in QEMU; explicit "normal in QEMU" annotation from the kernel
ERROR	ahcid::ahci::hba	IS 40000000 IE 17 CMD 3000006 TFD 2041 / SSTS 113 SCTL 700 / 2: I/O error	Expected — QEMU port 2 is the empty DVD-ROM probe, no media
PANIC	virtio-blkd@drivers/storage/virtio-blkd/src/scheme.rs:70:9	assertion left == right failed, left: 1, right: 0	Boot blocker. Status byte is non-zero (1 = VIRTIO_BLK_S_IOERR) on a write to the readonly=on boot drive
ABORT	[virtio-blkd@relibc::header::stdlib:119 ERROR] Abort	Daemon self-abort on panic	Follow-on of the assertion failure
FATAL	kernel::context::signal:INFO -- UNHANDLED EXCEPTION, CPU #0, PID 19, NAME /scheme/initfs/lib/drivers/virti, CONTEXT 0xffffff7f8012bad0	Kernel caught the invalid-opcode fault from the aborted daemon and reported it. Daemon virti is the truncated process name for virtio-blkd (process table / kernel log buffer truncates names at ~20 chars)	Boot stops here.

The panic is the only new blocker. All other warnings are documented-expected QEMU behaviour, identical to the 75 s baseline.

---

9. Comparison With the 75 s Baseline

Metric	75 s	300 s
Bytes captured	6 542	16 988
Lines captured	96	204
Boot stages reached	up to inputd v6.0	up to virtio-blkd startup → panic on first write
PCI enumeration visible	⏳ not yet	✅ 9 devices listed
pcid-spawner dispatch	⏳	✅ (nvmed, virtio-blkd, ahcid)
nvmed NVMe bring-up	⏳	✅ (multi-queue, 1 GiB NS)
virtio-blkd bring-up	⏳	✅ (1.5 GiB boot disk)
ahcid AHCI probe	⏳	✅ (4 ports, expected empty-port I/O error)
D-Bus, KWin, SDDM, login	⏳	❌ (panic before)
Last log line	inputd v6.0: daemon binary is deprecated…	UNHANDLED EXCEPTION … /scheme/initfs/lib/drivers/virti

Net progress vs the 75 s run: the 300 s window advanced userspace boot from "inputd library is publishing v6.0 messages" to "PCID has dispatched all storage drivers, but the writable-virtio-blk assumption collides with the read-only ISO drive and panics the driver." This is strictly more boot progression — but the new stage (write-to-readonly) is the new blocker, not an old one. The 75 s run never reached the write attempt because it timed out before virtio-blkd got far enough to issue one.

---

10. What Was Reached vs What Was Not

Reached

• All UEFI / RedoxFS / kernel / ACPI / GPE / quirk-system stages
• vesad early-boot handoff (No boot framebuffer — correct, vesad is not the primary surface per NO VESA POLICY)
• fbbootlogd / fbcond no-display reports (expected with -vga none)
• hwd ACPI backend online
• pcid full PCI enumeration (9 devices)
• pcid-spawner driver dispatch
• nvmed (QEMU NVMe Ctrl) — multi-queue, 1 GiB namespace
• virtio-blkd — bring-up completed, disk size read, then write panic
• ahcid — 4-port probe, expected empty-port I/O error
• Kernel's "MSI before IOMMU" annotation (proves MSI delivery path is wired)

Not reached

• init: switchroot to /usr /etc (second switchroot into the rootfs)
• iommu daemon
• evdevd (v6.0 input architecture)
• D-Bus system bus and any redbear-* D-Bus service
• redbear-netctl / DHCP
• cpufreqd / thermald
• Red Bear login: prompt
• SDDM / KWin / Wayland compositor (text-only target — would not be present on a successful redbear-mini boot either)

---

11. Repeatability

The test is fully repeatable. The launcher:

• Reuses the existing build/x86_64/redbear-mini/harddrive.img (no rebuild)
• Attaches with snapshot=on,readonly=on (no write damage to the build artifact)
• Auto-creates a 1 GiB extra.img if absent
• pkills any prior QEMU before starting
• Writes a fresh timestamped log to local/docs/boot-logs/

Re-running the same command produces an identical boot progression (modulo the OVMF randomized boot0004 path index and the acpid timestamp delta). The captured log name format is redbear-full-boot-YYYYMMDD-HHMMSS.log and the human-readable summary in this directory is the canonical triage entry point.

---

12. Deliverables

Path	Description
local/scripts/test-redbear-full-qemu.sh	QEMU launcher (chmod +x'd, unchanged this run)
local/docs/boot-logs/redbear-full-boot-20260609-135308.log	300 s QEMU boot capture (16 988 bytes, 204 lines)
local/docs/boot-logs/REDBEAR-FULL-BOOT-EXTENDED-RESULTS.md	This document
local/docs/boot-logs/redbear-full-boot-20260609-125114.log	Prior 75 s capture (for comparison)
local/docs/boot-logs/REDBEAR-FULL-BOOT-RESULTS.md	Prior 75 s analysis
local/docs/boot-logs/redbear-mini-20260430-210123.log	Reference: full text-only boot to login