BiteSizedChunks.comLearn one small thing at a time.
Course contentsShow
← Linux
Lesson 615 of 1,8196. Systemd Internals and Unit OrchestrationFree lesson

Analyzing Boot Failure Reports

Interpret the kernel ring buffer and systemd logs to diagnose early boot failures.

In this lesson, you will learn how to reconstruct the events of a system crash by interpreting the kernel ring buffer and systemd journal logs.

When a machine fails to reach the login prompt, the "boot report" is essentially a reconstruction of the handoff between the hardware, the kernel, and the systemd init process. To diagnose these failures, we must look at two primary sources of truth: the kernel ring buffer and the system journal.

The Kernel Ring Buffer (dmesg)

Before systemd even starts, the kernel is busy initializing hardware. If a system hangs during early boot, the kernel's internal circular buffer often contains the last words of the hardware drivers. You can inspect this log using:

dmesg -k

Look for lines prefixed with [ X.XXXXXX] followed by error, failed, or panic. If you see hardware timeout errors or firmware loading failures here, your systemd units likely never got the chance to execute.

The Systemd Journal

Once the kernel hands control to systemd, the journal becomes your primary investigation tool. Because the system didn't finish booting, you cannot simply run journalctl. Instead, you must query the logs from the previous boot to see where the dependency tree collapsed:

journalctl -b -1 -p 3
  • -b -1 tells the journal to look at the logs from the boot session immediately preceding the current one.
  • -p 3 filters for "err" level messages and higher.

Putting It Together

Often, a boot failure isn't a crash, but a "dependency loop" or a service that refuses to start, causing systemd to hang while waiting for a timeout. When examining the output of your -b -1 query, search for the Reached target messages. If the logs stop abruptly after a specific target (like network-online.target), you know exactly which phase of the boot process failed. By matching these timestamps against the systemd unit states you learned to inspect in previous lessons, you can pinpoint whether the issue is a misconfigured unit, a missing mount, or a service conflict.

Key Takeaway: Use dmesg to verify hardware initialization and journalctl -b -1 to identify which specific service or target failed to initialize during the last failed boot attempt.