Boot Log Analyzer (serial-analyze)

What is it?

serial-analyze is a planned host tool that reads a serial boot log and reports where the boot time went, which warnings and errors appeared, and what changed between two boots, as terminal text or an HTML report. None of its five sections has been built. Two pieces already cover part of the job: an offline renderer for the kernel's boot-timeline file, and the smoke test's log handling.

How does it work?

What the kernel prints today. Every serial log line from the kernel logger has the same shape, which the tool will parse:

[  4.250] [cpu:0] [ OK ] BOOT: --- Boot step timing (45 steps, base=step0) ---
[  4.250] [cpu:0] [ OK ] BOOT:   [PHASE0] +0ms 0x0011 SERIAL
[  4.260] [cpu:0] [ OK ] BOOT:   [PHASE0] +14ms 0x0026 BOOT_INFO

That is a timestamp in seconds, the CPU (absent on the earliest lines), a level tag ([INFO] for debug, [ OK ] for info, [WARN], [FAIL] for errors, or [CRIT] for a fatal error that halts the machine), the subsystem and the message. The boot-step block above comes from boot_timing_print_steps() in src/kernel/boot_timing.c: one line per step with its phase, offset from the first step in milliseconds, POST code and name. It is printed once, after the Boot complete in N.NNNs line. Earlier, each step also prints a bare [PHASEn] NAME (0xNNNN) progress line with no timestamp.

What exists on the host today.

• tools/boot-timeline/boot_timeline.py renders the kernel's X:\Perf\boot-timeline.json artifact, not the serial log: svg draws a Gantt chart and trace writes Chrome Trace Event JSON for chrome://tracing or Perfetto. Its format is documented in the boot timeline schema.
• scripts/test-smoke.sh strips ANSI colour codes into build/smoke-test.stripped.log and checks the log for its pass and fail markers.
• The repository's diagnose-serial-log skill reads a log with an agent, looking for crashes, races, leaks, policy breaches and regressions against a baseline log.

Planned design.

1. Parse each line into timestamp, level, subsystem and message; pick out phase transitions, POST codes and the boot-step block; strip ANSI codes from VirtualBox logs.
2. Timing: totals per phase, the five slowest subsystems, anything over 2 seconds, and the timer calibration tier.
3. Highlight warnings and errors, grouped as hardware, firmware, driver or subsystem, with counts.
4. Compare two logs: per-phase and per-subsystem deltas (flagging slowdowns over 20%), new warnings, and subsystems that disappeared.
5. Report: an ASCII waterfall in the terminal and an HTML report with --html.

flowchart LR
    L[serial.log] --> P[parse lines and boot-step block]
    P --> T[timing per phase and subsystem]
    P --> W[warnings and errors]
    T --> C[compare with a second log]
    T & W & C --> R[terminal or HTML report]

What are its interfaces?

How do I use it?

Until the tool exists, the same questions can be answered with standard tools:

bash scripts/test-smoke.sh
grep -A50 'Boot step timing' build/smoke-test.stripped.log
grep -E '\[(WARN|FAIL|CRIT)\]' build/smoke-test.stripped.log
python3 tools/boot-timeline/boot_timeline.py svg boot-timeline.json -o boot.svg

In the smoke run of 2026-09-30 the stripped log had 421 [ OK ], 130 [INFO], 35 [WARN] and 1 [FAIL] line; the [FAIL] is a boot-time budget report, not a crash. The boot-timeline.json input comes from the BlackBox partition (see BlackBox Log Extractor).

What is not implemented yet?

• Log Parser
• Timing Analysis
• Warning/Error Highlighter
• Boot Comparison
• HTML Report

The parser has to treat [CRIT] as the most severe tag: a fatal error prints it just before the machine halts, and the smoke test fails on sight of it. The roadmap's per-subsystem timings and boot comparison overlap the shipped timeline renderer and the planned blackbox boot --compare in the BlackBox extractor roadmap, which compares the same steps from two captured boot-timeline.json files; section 4 now plans one comparison engine for both.

How does it compare with Windows 11 and Linux?

Windows records boot performance with the Windows Performance Recorder and shows it in Windows Performance Analyzer; Linux has systemd-analyze blame, critical-chain and plot, and dmesg with levels. Both work from structured data the OS records, which is what the timeline renderer already does here. serial-analyze adds analysis of the plain serial text, which is the only record left when a boot never reaches the disk.

See also

• Boot log analyzer roadmap
• Boot Timeline Schema
• Boot Performance and Health Observability
• Serial Log Cleanliness
• Crash Decoder