Every Linux user hits the same wall eventually: something that worked yesterday is broken today, and the screen isn't saying why. This track turns that panic into method. The system is almost always telling you what happened — in journalctl, in dmesg, in the output apt hands back when a package won't install. Learn to read those signals and most "mystery" failures stop being mysteries: a broken dependency, a missing kernel module, a mount that references a disk by the wrong name, a boot that stalls before you ever see a login. We cover how to find the one line that matters and turn it into a fix.
Dedicated logging and recovery guides are being written. Until then, these two cover the identifiers and shell skills you'll lean on in almost every fix.
Many "won't boot" and "device not ready" failures come down to an /etc/fstab pointing at a stale disk name. Reading the real UUID is step one of the fix.
Tailing logs, piping to grep, editing a config in an emergency shell — troubleshooting is command-line work. Build the terminal fluency the rest of this track assumes.
journalctl & dmesgThe kernel ring buffer and the systemd journal record what actually happened. Learn to filter them by priority, service and boot so the signal rises above the noise.
read the guide →journalctl -p err -b and dmesg by priority and boot to find the one line that explains the failure.apt --fix-broken install and dpkg — without nuking the system.lsmod, modprobe and dmesg./etc/fstab, and get back to a login prompt when the machine stalls on startup.Two habits separate people who fix Linux quickly from people who reinstall — and both start with looking closely before touching anything.
A failed upgrade can leave packages half-configured and apt refusing to do anything else. The fix is rarely dramatic: sudo apt --fix-broken install to resolve the chain, sudo dpkg --configure -a to finish interrupted setups, and reading the error to see which package actually broke first.
When hardware "isn't detected" or the boot hangs, the kernel usually logged why. Check dmesg for the failing driver, confirm the module with lsmod, and load it with sudo modprobe <name>. For boot stalls, an incorrect UUID in /etc/fstab is a classic cause — which is exactly why the disk-identifier guide above is here.
-b to journalctl to scope logs to the current boot, and -b -1 for the previous one. Comparing "last good boot" against "the boot that failed" is often the fastest way to spot what changed.