2026-04-02Debugging5 min read

QEMU Debugging Notes

A field note on why QEMU makes OS dev approachable, why serial logs matter, and why a blank screen can have many causes.

QEMU makes OS development approachable because it gives fast iteration without rebooting real hardware. It also makes it easy to fool yourself when there is no output.

What I was trying to do

I was trying to separate boot image issues, target configuration problems, framebuffer failures, and kernel panics that all looked like the same blank screen.

What I learned

A blank screen does not point to one specific bug.
Serial logs are critical because graphics initialization can fail silently.
QEMU flags, boot image layout, panic behavior, and target setup all affect the first visible signal.
The fastest debugging path is to create a known-good minimal output path before adding visual complexity.

Technical notes

Start with serial output before relying on framebuffer rendering.
Confirm the boot image is being loaded before debugging kernel code.
Treat panic handlers as part of the debugging interface.
Keep QEMU launch commands reproducible so configuration does not become hidden state.

Open questions

Which QEMU flags should become the default development profile?
How much debug output belongs in normal boot logs?
Should debug output be separated into levels this early?

Next steps

Create a minimal smoke test for serial output.
Document the QEMU command used for each milestone.
Add clearer panic output before expanding keyboard or shell features.