Troubleshooting

The “Failed to mount /home” error and a missing UUID

If you boot into a black screen and the kernel spits out

Failed to mount /home

you’re almost certainly dealing with a stale or wrong UUID in /etc/fstab.
Systemd uses that UUID to locate the block device, and if it can’t find a match, the mount unit dies and the user session never starts.

1. Identify the missing UUID

# Show all block devices with their UUIDs
sudo blkid

# Or a tree view
sudo lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,UUID

Look for the entry that should be /home. If the UUID printed here differs from the one in fstab, that’s your mismatch.
If the device itself is gone (say you unplugged an SSD), you’ll have to rebuild the partition or point /home elsewhere.

Introduction to resolvectl

I’ve seen my fair share of DNS issues on Linux, and one of the most powerful tools in my arsenal is resolvectl. Before diving into debugging, you may want to review our guide on DNS configuration and troubleshooting with resolvectl for a broader overview of the tool’s capabilities. This command-line utility is part of the systemd suite and provides a comprehensive way to query and configure DNS settings on your system. In practice, resolvectl can be a lifesaver when dealing with stubborn DNS problems. Here, we’ll dive into how to use resolvectl to debug these issues, exploring its capabilities, and providing practical examples to help you troubleshoot and resolve DNS problems efficiently.

Introduction to resolvectl

I’ve seen many Linux users struggle with DNS configuration and troubleshooting. Editing configuration files like /etc/resolv.conf or /etc/hosts can be a real pain, and it’s easy to make mistakes. That’s why I’m a big fan of resolvectl, a command-line utility provided by systemd. It’s made managing DNS settings a whole lot simpler. In this article, I’ll show you how to use resolvectl to simplify DNS configuration and troubleshooting on Linux.

Introduction to Initramfs Recovery

I’ve seen this go wrong when a simple kernel update causes the initramfs to become outdated or corrupted, leading to a frustrating boot loop. The initramfs is a critical component that loads kernel modules and sets up the system before the root file system is mounted. A broken initramfs can be challenging to recover from, especially for those without extensive experience in low-level system debugging.

Understanding Initramfs

Before diving into recovery methods, it’s essential to understand the role of initramfs in the boot process. The real trick is recognizing that the initramfs is loaded by the bootloader (such as GRUB or systemd-boot) and serves as a temporary file system that allows the kernel to load modules necessary for mounting the root file system. This includes modules for disk controllers, file systems, and network devices, among others. If the initramfs is broken, the system cannot proceed with the boot process.

Introduction to Initramfs Rescue

I’ve seen this go wrong when updates don’t quite go as planned - a broken initramfs can leave your Linux system unbootable. The real trick is understanding how initramfs works, so let’s dive into that before we get into the rescue process. Initramfs, short for initial RAM file system, is a temporary file system used during the boot process. It’s responsible for loading kernel modules, setting up the root file system, and handing over control to the main system. If the initramfs is corrupted or incorrectly configured, your system may fail to boot.

Introduction to Shared Directory Permissions

When setting up a Linux homeserver, I’ve seen many people struggle with configuring shared directories for multiple users. It’s a common task, but permission issues can quickly become a headache if not properly managed. In my experience, understanding the basics of Linux permissions is essential before diving into shared directories.

Understanding Permission Basics

Permission basics are pretty straightforward. Each file and directory has three types of permissions: read (r), write (w), and execute (x). These permissions are applied to three categories: owner, group, and other. The chmod command is used to modify these permissions. For example, to set the permissions of a directory to allow the owner to read, write, and execute, while allowing the group to read and execute, you can use the following command:

Introduction to Rescue Shells and Chroot

I’ve seen my fair share of borked Linux installs over the years, and a rescue shell can be a real lifesaver. This powerful tool lets you access your system’s filesystem and repair or recover data, even when the normal boot process fails. In this article, I’ll walk you through how to use a rescue shell and chroot to recover a damaged Linux install.

Preparing for Recovery

Before you start, make sure you’ve got a backup of your important data - I usually start with rsync or tar to create a backup of critical files. For example:

Introduction to systemd’s Restart Policy

I’ve worked with systemd for years, and one of its most useful features is the ability to automatically restart services that fail or exit unexpectedly. This is all controlled by the restart policy, which can be customized using the Restart directive in systemd service files. However, I’ve seen this go wrong when a service is restarted repeatedly in a short period of time, leading to unintended consequences. To mitigate this, systemd provides two directives: RestartSec and StartLimitBurst.

Introduction to systemd Restart Behavior

When working with Linux systems, you’ve probably encountered services that just won’t stay down. I’ve seen this go wrong when trying to troubleshoot or maintain my system - it’s frustrating, to say the least. The culprit behind this behavior is often systemd, the init system used by most modern Linux distributions. In this article, we’ll explore how to tame its restart behavior.

Understanding systemd Service Units

To grasp how systemd handles service restarts, you need to understand service units. A service unit is a configuration file that defines how systemd should manage a particular service. These files are usually located in /etc/systemd/system/ or /usr/lib/systemd/system/. Service units can contain various directives, such as Restart, which controls the restart behavior of a service.

Introduction to Troubleshooting Linux Boot Issues

When a Linux system fails to boot, it can be a frustrating experience. I’ve seen this go wrong when you’re relying on your system for critical tasks or services. Luckily, with the advancements in Linux and its ecosystem, troubleshooting boot issues has become more streamlined, thanks in part to the features and tools provided by systemd and the Linux kernel itself.

Understanding systemd’s Debug Shell

The real trick is to get insight into what’s going wrong during the boot process. systemd, the system and service manager for Linux, offers a debug shell that can be incredibly useful for this. To access the debug shell, you can modify the kernel parameters during boot. For example, to enable the debug shell, you can append the following to your kernel parameters: