Use journalctl, dmesg and systemctl to find what failed during boot and why. 02.12.2025 | reading time: 3 min When a Linux machine stumbles at startup, the fastest route to the root cause is the boot log; this short guide shows how to extract errors and pinpoint the failing unit with concrete commands. A concrete case: failed SSH daemon at boot Reproduce the investigation by running these commands and reading the output: ```bash journalctl -b -p err --no-pager -- Logs begin at Mon 2025-11-30 10:00:00 UTC, end at Tue 2025-12-02 09:12:34 UTC Dec 02 09:05:01 hostname systemd[1]: Failed to start OpenSSH Daemon. Dec 02 09:05:01 hostname sshd[1234]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key systemctl --failed UNIT LOAD ACTIVE SUB DESCRIPTION sshd.service loaded failed failed OpenSSH Daemon journalctl -u sshd -b --no-pager Dec 02 09:05:01 hostname sshd[1234]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key Dec 02 09:05:01 hostname sshd[1234]: Fatal: No host keys available -- exiting. ``` What to try next when you see errors If a unit failed, inspect its unit logs with `journalctl -u <unit> -b`, then start it manually with `systemctl start <unit>` and watch `journalctl -f` for live output; check kernel-level problems with `dmesg` or `journalctl -k`, and view older boots with `journalctl --list-boots` and `journalctl -b -1` to compare behavior across reboots. Important journalctl options to remember Use `-b` to scope to a boot, `-p` to filter by priority, `-u` for a unit, `-k` for kernel messages, `--since`/`--until` for time ranges and `--no-pager` to capture output in scripts; enable persistent logging by ensuring `/var/log/journal` exists so old boot logs survive reboots. Other log stores and edge cases On systems without systemd, check /var/log/boot.log or syslog files; when logs are missing, confirm disk space and permissions, verify that the journal is not volatile only, and remember that early initramfs failures may only appear in the kernel ring buffer and require `dmesg` examination. Wrap-up and next steps Boot log inspection usually yields the culprit quickly: a missing key, a misconfigured service, or a failing driver; practice by simulating failures and using the filters shown here, then deepen knowledge through targeted study and certification preparation at bitsandbytes.academy for CompTIA Linux+ or LPIC-1. Join Bits & Bytes Academy First class LINUX exam preparation. boot-process troubleshooting utilities processes