Your Linux server won’t boot. The screen hangs, or you see a blinking cursor. Maybe it drops to a rescue shell. Panic sets in, but there is no need to reach for the recovery USB just yet. Every boot failure leaves a trail of clues inside systemd’s journal. With the right commands, you can find the exact cause and get your system back online fast.

Diagnose the Boot Process with systemd-analyze

Before you dig into logs, get a high level view of what happened during the last startup. The systemd-analyze tool gives you a timeline of where the boot spent time.

• Run systemd-analyze blame to see which services took the longest to start.
• Run systemd-analyze critical-chain to see the dependency chain that might have stalled.
• Run systemd-analyze plot > boot.svg to create a visual timeline of the entire boot sequence.

If the boot stopped completely before the login prompt, you want the chain that shows the last unit that failed to activate. The critical chain highlights the single point of failure.

Use journalctl to Read Boot Logs

The journal contains logs from every boot, organized by boot ID. To troubleshoot linux boot issues systemd journalctl is your best friend. Follow these steps:

1. List all available boots with journalctl --list-boots. Each entry shows a numeric offset and the boot ID.
2. View the logs from the most recent failed boot: journalctl -b -1. The -1 means one boot ago. If you rebooted after the failure, the current boot may be clean, so use -1 or -2.
3. Add the -p err flag to show only error level messages: journalctl -b -1 -p err.
4. Filter by service name: journalctl -b -1 -u sshd.service for example.
5. Look for the kernel messages too: journalctl -b -1 -k.

A common mistake is to run journalctl without any boot selection. That shows the current boot, which is useless if your system already rebooted. Always specify -b with the correct offset.

Expert advice: Before you make any changes, save the journal from the broken boot. Run journalctl -b -1 --no-pager > bootfail-journal.txt. That way you have a snapshot to reference in case your fix makes things worse.

Isolate Failed Systemd Units

When a service fails during boot, systemd records it with a clear status. Use systemctl --failed to list all units that ended in a failed state. This command works even if the system is running in rescue mode.

• The output shows the unit name and the unit type (service, mount, timer, etc.).
• To see the full error for one unit, run systemctl status <unit>.
• The status output includes the last few log lines from the journal, so you don’t often need to switch between tools.

If no units appear as failed, the problem may be earlier in the boot sequence, before systemd started most services. In that case, focus on kernel messages.

Interpret Common Boot Failure Patterns

Kernel Panic or Oops

A kernel panic causes the screen to freeze with a long trace. You can capture the exact message by using a serial console or by taking a photo. The key line contains the function that crashed, often related to a driver or filesystem. Common fixes include blacklisting a specific kernel module or booting from an older kernel.

Stuck at “Reached target Basic System”

This target comes after the filesystems are mounted but before network and user login. If the boot hangs here, one of the local filesystems might be missing a required mount point or a device that doesn’t respond. Check mount and lsblk from the rescue shell.

Filesystem Errors

A dirty filesystem causes systemd to wait for a repair prompt. The boot may pause at a message like “A stop job is running for /dev/sda1”. Use fsck /dev/sda1 from a recovery environment. If you cannot boot at all, add fsck.mode=force to the kernel command line to force a check.

Fix Boot Issues Step by Step

Follow this numbered process when you suspect a service is the cause.

1. Boot into the system, even if it lands in rescue mode or a broken shell.
2. Run systemctl --failed and note each unit.
3. For each failed unit, run systemctl status <unit> and read the last 10 lines.
4. If the error mentions a missing executable, reinstall the package or restore the binary.
5. If the error says “dependency failed”, trace the dependency chain with systemctl list-dependencies <unit>.
6. Once you understand the problem, either disable the unit with systemctl disable <unit> or fix the underlying configuration.
7. Test your fix by rebooting: systemctl reboot.

If you cannot reach a shell at all, append systemd.unit=emergency.target to the kernel command line at the GRUB menu. That boots into a minimal environment where you can access a root shell and run the same diagnostic commands.

When All Else Fails: Emergency and Rescue Modes

Sometimes the journal itself is corrupted or the root filesystem cannot be mounted read-write. In that case, you need to break out the big tools.

• From the GRUB menu, edit the kernel line and add systemd.unit=rescue.target or systemd.unit=emergency.target.
• Rescue mode gives you a single user shell with essential services. Emergency mode gives you a bare shell without mounting most filesystems.
• Once in the shell, you can run journalctl --file /var/log/journal/<machine-id>/system.journal if the journal file is readable.

If even emergency mode fails, boot from a live USB, mount your root partition, and examine the journal offline. This is rare with modern hardware, but it happens.

Build Your Boot Debugging Toolkit

Troubleshooting boot problems gets easier the more you practice. Start by reading the journal of a healthy boot to see what normal looks like. Run journalctl -b 0 --no-pager | less and scroll through the timeline. Notice the order of services, the mount points, and the kernel messages. When a real failure occurs, you will spot the difference quickly.

Set up a habit of running journalctl --verify once a week to check the journal’s integrity. A corrupted journal can hide the very error you need. Also keep a backup of the kernel you are booting. Most package managers keep at least one old kernel around, so you can select it from GRUB if a new update breaks the boot.

The combination of systemd-analyze, journalctl, and systemctl gives you complete visibility into the boot sequence. Use these tools every time you fix a boot problem, and you will reduce downtime from hours to minutes. Your future self will thank you when a routine update goes sideways.

Now go and debug that broken boot. You have everything you need.