Every Linux user, from beginners to advanced users, will eventually face issues on their system. The ability to troubleshoot independently is an invaluable skill. This chapter discusses troubleshooting methodology in Linux, how to read error messages, system log locations, solutions to common problems, and effective ways to find help on the internet.
42.1 Troubleshooting Methodology in Linux
Good troubleshooting is not done randomly; rather, it follows a systematic process. This principle applies equally whether a Sysadmin is managing a production server or a User is simply fixing a personal laptop. The general sequence is as follows.
- Reproduce the issue. Ensure that you can reproduce the problem and understand when it occurs.
- Check error messages. Read the error messages that appear, both on the screen and in the logs.
- Identify the root cause. Determine which component is likely the source of the issue.
- Apply solutions one at a time. Change only one thing at a time so you know what actually resolved the issue.
- Document the solution. Keep notes so similar problems can be resolved faster in the future.
42.2 Reading Error Messages Effectively
Error messages are not just random text. They frequently contain hints pointing to the root cause. Pay attention to the following details.
- Program name that generated the error.
- Error type, such as permission denied or no such file or directory.
- File location or associated configuration.
- Last error line, as this line is often the most relevant.
Accustoming yourself to reading error messages carefully will save a lot of time compared to blind guessing.
42.3 Important System Log Locations
Linux logs system activity in log files, which are extremely helpful when diagnosing issues.
42.3.1 /var/log/: Log Directory
Most file-based logs are stored in the /var/log/ directory. Note that log locations differ between distributions: in Ubuntu, the rsyslog service remains active by default, so general system logs can still be read directly from /var/log/syslog and authentication logs from /var/log/auth.log. In Fedora Workstation, rsyslog has not been installed by default for several recent releases, meaning the /var/log/messages file formerly common in classic RHEL/Fedora is typically absent on default installations; practically all logs are stored exclusively in the systemd journal and can only be accessed via journalctl.
42.3.2 journalctl: systemd Journal Logs
On systems with systemd, centralized logs can be accessed using journalctl. To view logs since the last boot along with error messages, use:
journalctl -b -p errMeanwhile, to follow logs in real time, use:
journalctl -fIf the problem occurred on a previous boot (for instance, if the system suddenly restarted or froze), view the logs from the boot prior to the latest one using:
journalctl -b -1This command is very useful because logs from a problematic session usually no longer appear on the screen after a reboot.
42.4 Common Issues and Solutions
Here are several frequently encountered problems along with their troubleshooting steps.
42.4.1 System Fails to Boot
If the system fails to boot, try entering via the Advanced options for Ubuntu/recovery mode option available in the GRUB boot menu (hold the Shift key during boot if the menu does not appear automatically). From there, you can inspect logs, repair the filesystem with fsck, or fix broken packages. Run fsck only on partitions that are not actively mounted (recovery mode usually handles this as read-only automatically), because running it on an actively used filesystem risks worsening data corruption. In many cases, a failed kernel or driver update is the primary cause of such boot issues; if so, select a previous kernel version from the GRUB menu as a temporary measure.
Specifically for Ubuntu 26.04 LTS, which natively supports TPM-based (Trusted Platform Module) full disk encryption, boot failures can sometimes occur because the TPM fails to verify system status, such as after a UEFI firmware update, prompting the system for a recovery key instead of automatically unlocking the disk. Keep this recovery key in a secure place from initial installation, as without it the encrypted disk cannot be unlocked at all.
42.4.2 Software Cannot Be Installed (Dependency Conflict)
Dependency conflicts usually arise when a package requires a library version that is unavailable. On Ubuntu, run sudo apt update followed by sudo apt --fix-broken install to repair broken dependencies; if the installation process was interrupted mid-way, run sudo dpkg --configure -a to complete pending package configurations. On Fedora, use sudo dnf upgrade --refresh to synchronize package versions, or sudo dnf distro-sync if packages are out of sync with active repositories; the sudo dnf check command can be used to detect dependency issues without making any changes. If the issue involves a Flatpak application, attempt to repair its installation using flatpak repair.
42.4.3 Network Connection Issues
Check connection status with ip addr, then test connectivity using ping. If DNS is failing, try testing with ping 8.8.8.8; if the IP address is reachable but domain names are not, the issue likely lies with the DNS resolver, which can be checked using resolvectl status. NetworkManager logs can also be inspected with journalctl -u NetworkManager.
42.4.4 Disk Full
Use df -h to view disk usage. If a partition is full, find the largest directories with du -sh and clean up unnecessary files, such as old caches and log files. A frequently overlooked cause of a full disk is an ever-expanding systemd journal; check its size with journalctl --disk-usage, then cap it using:
sudo journalctl --vacuum-size=200MThe command above permanently deletes older log entries until the total journal size does not exceed 200 MB, so make sure no essential logs are needed before running it.
42.4.5 File Permission Denied
Permission denied errors occur when you lack the required access permissions. Check permissions with ls -l, then modify ownership using chown or permissions using chmod. To access system-owned files, use sudo. Sysadmins frequently encounter this when an automated script runs under the wrong user, or when files are moved between directories, causing ownership to change.
On Fedora, SELinux is active by default in Enforcing mode, so permission denied errors may appear even when ls -l permissions look correct. This usually occurs because the SELinux security context on the file is incorrect, such as after moving a file from another location. Check SELinux status with getenforce, and if suspected as the cause, restore the default security context for the file or directory using:
sudo restorecon -Rv /path/to/file42.5 Finding Online Solutions Effectively
The internet is an incredible source of help, provided you know how to search.
42.5.1 What to Include When Asking Questions
When asking a question, include complete information so others can assist effectively. State the distribution and its version, the exact command executed, full error messages, and the steps you have already tried. This principle applies whether you are a Developer debugging an environment or a beginner User using Linux for the first time.
42.5.2 Linux Forums and Communities
Great places to ask include Ask Ubuntu for Ubuntu users, Unix & Linux Stack Exchange for general questions, and the official Fedora Discussion forum. The official Ubuntu community itself is now centered at Ubuntu Community Hub (Discourse-based) for in-depth discussions, and on Matrix for quick or real-time chats. There are also active Indonesian Linux communities across various platforms. Before asking, perform a search first, as it is highly likely your issue has already been discussed.
Troubleshooting is a skill that develops with experience. Through a systematic methodology, the ability to read error messages, and effective utilization of logs and communities, you will become increasingly confident in resolving issues on Linux. In the final chapter, we will summarize our learning journey and explore the next steps for continuous growth.