Linux Troubleshooting: Fix Common Linux Problems Step by Step
Start with the symptom and work through practical Linux fixes for boot, Wi-Fi, audio, graphics, Bluetooth and storage problems.
Linux is often easier to repair than it first appears. The difficulty is usually not the lack of tools—it is knowing which part of the system is actually failing.
A machine that will not boot needs a different approach from a desktop with broken Wi-Fi. A black screen after login is not the same problem as GRUB rescue. “No sound” might be nothing more than the wrong output device, while a missing disk could point to storage hardware, a filesystem, or a mount configuration.
The most reliable way to troubleshoot Linux is to start with the symptom, gather a small amount of evidence, and make the smallest change that matches what you found.
This page is the starting point for TechRefreshing’s Linux troubleshooting guides. Choose the problem area below, or use the diagnostic workflow if you are not yet sure where the fault lies.
A useful rule: Do not begin with reinstalling Linux, deleting configuration folders, or pasting long command sequences from an old forum post. First establish what changed, what still works, and where the failure begins.
Fedora boots to GRUB, starts the kernel, and then shows a black screen.
Or:
Wi-Fi connects to the router, but DNS names do not resolve.
Or:
PipeWire detects the speakers, but the desktop selected HDMI as the default output.
That level of detail immediately narrows the problem.
Before changing anything, write down:
what you expected to happen;
what actually happened;
the last thing that still worked;
when the problem started;
whether you installed an update, driver, application, or hardware device immediately beforehand.
That small timeline often provides the best clue in the entire troubleshooting process.
2. Check Whether the Problem Affects the Whole System
Try to separate a system-wide problem from an application-specific one.
For example:
If every application has no sound, investigate the audio stack.
If only one browser tab has no sound, check the browser first.
If Ethernet works but Wi-Fi does not, the entire network stack is not broken.
If an older kernel boots normally, the disk and bootloader may be fine.
If a live USB sees the disk but the installed system does not mount it, focus on the installed configuration.
This prevents broad repairs for narrow problems.
3. Check What Changed
Linux systems are predictable when nothing changes. Many failures begin immediately after something specific.
Common triggers include:
a kernel update;
a distribution upgrade;
a graphics driver update;
new firmware;
a new monitor or dock;
a USB peripheral;
editing /etc/fstab;
changing GRUB settings;
installing a third-party package;
changing network configuration;
suspend/resume;
running out of disk space.
If you can connect the failure to one change, test that hypothesis before touching unrelated parts of the system.
4. Check Basic System Health
When Linux still boots, a few commands can quickly show whether the machine has an obvious resource or storage problem.
Check disk usage:
df -h
A root filesystem at or near 100% usage can cause package updates, desktop sessions, logs, and applications to fail in surprising ways.
Check memory:
free -h
Check failed services on systemd systems:
systemctl --failed
Check the current kernel:
uname -r
Check recent high-priority messages:
journalctl -b -p warning
Do not treat every warning as a fault. Look for messages that correspond to the symptom and timing you are investigating.
5. Use the Logs, but Read Them With a Question
Linux logs are most useful when you already know what you are looking for.
For the current boot:
journalctl -b
For the previous boot:
journalctl -b -1
For kernel messages:
dmesg
For one service:
journalctl -u SERVICE_NAME
Instead of reading thousands of lines from top to bottom, search for the hardware, driver, service, or error connected with the problem.
Examples:
journalctl -b | grep -i bluetooth
dmesg | grep -iE 'nvme|ata|error'
journalctl -u NetworkManager --since today
A repeated, time-correlated error is much more useful than a random warning that has existed for months.
6. Separate Hardware Detection From Software Configuration
One of the most important Linux troubleshooting habits is to ask:
Can the operating system see the hardware at all?
For PCI/PCIe devices:
lspci -k
For USB devices:
lsusb
For disks and filesystems:
lsblk -f
For network devices:
nmcli device status
For audio devices on PipeWire systems:
wpctl status
For Bluetooth:
bluetoothctl show
If the hardware is missing at the lowest relevant level, changing a desktop setting is unlikely to solve the problem.
If the hardware is visible but an application cannot use it, move upward toward services, profiles, permissions, or application configuration.
7. If the Problem Began After a Kernel Update
The Linux kernel includes drivers for storage, networking, graphics, audio, USB, and many other devices.
If a problem starts immediately after installing a new kernel, testing the previous kernel can be a very useful comparison.
Do not assume the new kernel is at fault simply because the timing is close. Confirm that:
the older kernel works;
the new kernel reliably reproduces the problem;
the same hardware and configuration are being used.
If that comparison is clear, check your distribution’s bug tracker and update channels before making permanent changes.
8. If the Problem Began After a Distribution Upgrade
A distribution upgrade can change several layers at once:
kernel;
firmware;
system libraries;
desktop environment;
bootloader;
PipeWire/WirePlumber;
NetworkManager;
graphics drivers;
package configuration.
Old manual tweaks can also become incompatible.
After an upgrade, pay particular attention to configuration files you edited yourself. A workaround that was necessary two years ago may conflict with the current default behavior.
9. Do Not Ignore Disk Space
Low disk space causes more Linux problems than it gets credit for.
Check:
df -h
Also check inodes:
df -i
A filesystem can have free gigabytes and still fail to create new files if it has exhausted its available inodes.
Common symptoms of a full root filesystem include:
package updates failing;
desktop login loops;
applications refusing to start;
databases failing;
logs behaving strangely;
temporary files not being created.
Free space first, then reassess the original problem.
10. Use a Live USB to Separate Hardware From the Installed System
A current Linux live USB is an excellent diagnostic tool.
If the same Wi-Fi, graphics, audio, or storage hardware works normally in the live environment, the installed system’s configuration or package state becomes more suspicious.
If the hardware also fails in the live environment, investigate:
hardware;
firmware;
BIOS/UEFI settings;
kernel support;
a broader compatibility issue.
A live environment is also useful for copying important files before a risky boot or filesystem repair.
11. Avoid Making Five Changes at Once
Troubleshooting becomes difficult when you cannot tell which action affected the result.
Avoid doing this:
reinstall a driver;
delete configuration;
change the kernel;
disable Secure Boot;
edit GRUB;
reboot.
If the machine works afterward, you still do not know why.
A better pattern is:
collect evidence;
make one reversible change;
test;
record the result;
continue only if necessary.
That is slower for five minutes and much faster over an hour.
12. Know When a Command Is Risky
Many Linux diagnostic commands are safe because they only display information.
Examples include:
lsblk -f
lspci -k
nmcli device status
wpctl status
Other commands can modify disks, filesystems, bootloaders, firewall rules, permissions, or package state.
Before using a destructive or difficult-to-reverse command:
understand what it changes;
verify device names;
back up important data;
use distribution-specific documentation.
Never assume /dev/sda or /dev/nvme0n1 refers to the same disk as it did in somebody else’s tutorial.
13. Know When Reinstallation Is Reasonable
Reinstalling Linux is not always wrong. It is simply overused as a first response.
A clean reinstall may be reasonable when:
the system has years of unknown manual changes;
critical packages are extensively damaged;
you intentionally want to change distributions or disk layout;
restoring a known backup is faster and safer;
troubleshooting time is more valuable than preserving the current installation.
It is usually unnecessary when:
one driver fails;
one application is broken;
DNS is wrong;
GRUB is missing;
PipeWire selected the wrong device;
a Bluetooth profile is stuck;
a filesystem mount entry is incorrect.
Repair the smallest broken component when practical.
14. Keep a Few Recovery Tools Ready
Before you need them, it is worth having:
a current Linux live USB;
an external backup;
access to another internet-connected device;
your disk-encryption recovery information where applicable;
a record of important partition layouts;
a known working kernel installed.
The worst time to discover that your recovery USB no longer boots is after the installed system fails.
A Practical Linux Troubleshooting Workflow
When you are not sure what is wrong, follow this order:
Describe the exact symptom.
Identify when it started.
Check whether the problem is system-wide or application-specific.
Check disk space and failed services.
Confirm the relevant hardware is detected.
Read logs connected to the symptom.
Compare an older kernel if the timing points to a kernel update.
Use a live USB when you need to separate hardware from the installed system.
Make one reversible change at a time.
Use the dedicated troubleshooting guide for the failing subsystem.
The goal is not to collect clever commands. It is to reduce uncertainty until the cause is narrow enough to fix safely.
Browse TechRefreshing’s Linux Troubleshooting Guides
Browse TechRefreshing’s Linux Troubleshooting Guides
Use the Linux Wi-Fi Troubleshooting guide when adapters are missing, radios are blocked, connections drop, DNS fails, or Linux says it is connected without internet access.
Use the Linux Storage Troubleshooting guide for disks that are not detected, partitions that will not mount, GPT/MBR errors, filesystem problems, and full disks.
Official References Worth Using
For technical repairs, prefer current primary documentation from:
Linux changes steadily, so package names and recommended recovery steps can differ between distributions and releases.
Good troubleshooting is less about memorizing commands and more about asking the right question at each layer. Find the boundary between what works and what does not, then repair that boundary rather than rebuilding the entire system.
