Troubleshooting hub

Linux Troubleshooting: Diagnose the Layer Before You Change It

The best Linux troubleshooting habit is to collect evidence before making changes. Identify the failing layer, then use the smallest reversible test that can confirm or reject your hypothesis.

Technical review: 10 September 2026

A repeatable Linux troubleshooting loop

State the symptom precisely. “Wi-Fi is broken” is less useful than “the adapter appears in lspci, but NetworkManager shows it unavailable after this boot.”
Identify context. Distribution, release, kernel, desktop/server, hardware and what changed immediately before the failure.
Check the simplest layer first. Power/radio/cable, device detection, driver, service state, configuration, then application.
Collect evidence before changing state. Logs, service status, device IDs and exact errors.
Make one reversible change. Test the original symptom again. Do not stack five forum fixes and then guess which one mattered.
Document the working state. Keep the command, config diff or package version that resolved the issue.

Safe first commands

Read-only system context and failure evidence

cat /etc/os-release
uname -r
systemctl --failed
journalctl -b -p err
lsblk -f
ip link

Troubleshoot by layer

Layer	Evidence to collect	Common next guide
Boot	Previous/current boot logs; failed units; storage visibility	Read logs with journalctl
Network	Interface presence, radio state, NetworkManager state	Wi-Fi not working
Storage	Block devices, filesystems, free space, mount state	Backup before repair
Permissions	Owner, group, mode, service identity	Linux permissions
Packages	Distribution/release, repositories, first dependency/signature error	Package managers

Useful recovery gear

Official references

For current behavior and version-specific details, use the relevant upstream documentation alongside this guide.

Frequently asked questions

What is the first step in Linux troubleshooting?

Record the exact symptom and system context before changing anything. Then decide whether the failure is primarily hardware, boot, storage, networking, permissions, package management, service state or application behavior.

Why should I avoid trying many fixes at once?

Multiple simultaneous changes destroy diagnostic information because you can no longer tell which change affected the result. Use the smallest reversible test that can confirm or reject one hypothesis.

Useful next steps

Linux Wi-Fi Not Working: Diagnose the Failure in the Right OrderDo not start by reinstalling a random Wi-Fi driver. First find out whether Linux sees the adapter, whether a driver is bound, whether firmware loaded, and whether the failure is actually at the IP or DNS layer.How to Read Linux Logs with journalctlLinux logs are most useful when you ask a narrow question: which boot, which service, which time window and which error priority?Linux Backup: Build a Restore Plan Before You Need RecoveryA backup is only useful if it survives the failure you care about and you can restore it. Test a restore before you trust the process.