General Troubleshooting

Every Linux user, from beginners to experts, has definitely encountered problems with their system. The ability to troubleshoot on your own is an invaluable skill. This chapter discusses Linux troubleshooting methodology, how to read error messages, system log locations, solutions to common problems, and how to search for help effectively on the internet.

Linux Troubleshooting Methodology

Good troubleshooting is not done randomly, but follows a systematic approach. The general sequence is as follows.

1. Reproduce the problem. Make sure you can repeat the problem and understand when it occurs.
2. Check the error message. Read the error message that appears, both on screen and in the logs.
3. Identify the cause. Determine which component is likely the source of the problem.
4. Apply solutions one at a time. Change only one thing at a time, so you know what actually fixed the problem.
5. Document the solution. Keep records so that similar problems can be resolved faster in the future.

Reading Error Messages Effectively

Error messages are not just random text. They often contain clues about the cause of the problem. Pay attention to the following.

• The program name that generated the error.
• The error type, for example permission denied or no such file or directory.
• The file or configuration location involved.
• The last error line, because this line is often the most relevant.

Getting into the habit of reading error messages carefully will save a lot of time compared to guessing right away.

Important System Log Locations

Linux stores system activity records in log files, which are very helpful when diagnosing problems.

/var/log/: Log Directory

Most file-based logs are stored in the /var/log/ directory. Note that log locations differ between the two distros: on 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. On Fedora Workstation, rsyslog is not installed by default since several recent releases, so the /var/log/messages file that used to be common in classic RHEL/Fedora is usually not present in a default installation; practically all logs are only stored in the systemd journal and can only be accessed via journalctl.

journalctl: systemd 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 err

To follow logs in real-time, use:

journalctl -f

If the problem occurred on a previous boot (for example, the system suddenly restarted or froze), you can view logs from the boot before the last one with:

journalctl -b -1

This command is very useful because logs from the problematic session are usually no longer on screen after the system restarts.

Common Problems and Their Solutions

Here are some frequently encountered problems and their handling steps.

System Fails to Boot

If the system fails to boot, try entering via the Advanced options for Ubuntu/recovery mode available in the GRUB boot menu (hold the Shift key while booting if the menu does not appear automatically). From there you can check logs, repair the filesystem with fsck, or recover broken packages. In many cases, boot problems are caused by a failed kernel or driver update; if so, select a previous kernel version from the GRUB menu as a temporary workaround.

Specifically for Ubuntu 26.04 LTS which already stably supports full-disk encryption based on TPM, boot failures are sometimes also caused by the TPM failing to verify the system state (for example after a UEFI firmware update) thus prompting for a recovery key instead of automatically unlocking the disk; keep this recovery key in a safe place from the initial installation.

Software Cannot Be Installed (Dependency Conflict)

Dependency conflicts usually arise when a package requires a library version that is not available. On Ubuntu, run sudo apt update then sudo apt --fix-broken install to fix broken dependencies; if the installation process stopped midway, also run sudo dpkg --configure -a to complete the configuration of pending packages. On Fedora, use sudo dnf upgrade --refresh to sync package versions, or sudo dnf distro-sync if there are packages not synchronized with the active repository; the sudo dnf check command can be used to detect dependency problems without changing anything. If the problem appears with Flatpak applications, try repairing the installation with flatpak repair.

Network Connection Issues

Check connection status with ip addr, then test connectivity with ping. If DNS is problematic, try testing with ping 8.8.8.8; if the IP address is reachable but the domain name is not, the problem is most likely with the DNS resolver, and you can check it with resolvectl status. You can also check NetworkManager logs with journalctl -u NetworkManager.

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 caches and old logs. One cause of a full disk that often goes unnoticed is the systemd journal which keeps growing in size; check its size with journalctl --disk-usage, then limit it with:

sudo journalctl --vacuum-size=200M

The above command will trim old logs until the total journal size is no more than 200 MB.

File Permission Denied

A permission denied error occurs when you do not have the right access permissions. Check permissions with ls -l, then change ownership with chown or permissions with chmod. To access system files, use sudo.

On Fedora, SELinux is active by default in Enforcing mode, so sometimes permission denied can appear even when the permissions from ls -l look correct. This usually happens because the SELinux security context on the file is incorrect, for example after moving the file from another location. Check SELinux status with getenforce, and if suspected as the cause, restore the default file/directory context with:

sudo restorecon -Rv /path/to/file

Searching for Solutions Online Effectively

The internet is a tremendous source of help, as long as you know how to search.

What to Include When Asking

When asking a question, include complete information so others can assist. Mention the distribution and its version, the commands you ran, the full error message that appeared, and the steps you have already tried.

Linux Forums and Communities

Some good places to ask are 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 more centered on the Ubuntu Community Hub (based on Discourse) for in-depth discussions, and on Matrix for quick/real-time chats. There are also active Indonesian Linux communities on various platforms. Before asking, do a search first because chances are your problem has already been discussed.

Troubleshooting is a skill that develops with experience. Through systematic methodology, the ability to read error messages, and the use of logs and communities, you will become more confident in solving problems on Linux. In the final chapter, you will summarize your learning journey and see the next steps to continue growing.