Troubleshooting Failed Mounts at Boot Time with systemd and fstab -

Introduction to Troubleshooting Failed Mounts

When I’m dealing with a Linux system that won’t boot properly, one of the first things I check is the mount points. systemd and the /etc/fstab file are crucial in this process, but issues can still arise, leading to failed mounts and potential system instability. In this article, I’ll walk you through practical steps to troubleshoot and resolve failed mounts at boot time, focusing on systemd and fstab configurations.

Understanding fstab and systemd

To troubleshoot failed mounts, you need to understand how fstab and systemd interact. The /etc/fstab file contains information about filesystems, including their mount points, file systems types, and options. systemd uses this information to manage mount points during boot. I’ve seen this go wrong when the fstab file is not properly formatted or when systemd is not configured correctly.

fstab Format

The fstab file follows a specific format:

UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /mnt/data ext4 defaults 0 2

In this example, the UUID is the filesystem’s unique identifier, /mnt/data is the mount point, ext4 is the filesystem type, defaults specifies the mount options, 0 indicates that the filesystem should not be backed up by dump, and 2 specifies the filesystem check order. Don’t bother with the dump and fsck options unless you have a specific reason to do so.

systemd Mount Units

systemd creates mount units based on fstab entries. These units are responsible for mounting filesystems during boot. You can list all mount units with:

systemctl list-units --type=mount

This command will display all active mount units, including their current state. I usually start with this command to see which mounts are failing.

Troubleshooting Failed Mounts

To troubleshoot failed mounts, follow these steps:

Check systemd logs: Inspect systemd logs to identify errors related to mount failures:

journalctl -u systemd

Look for messages indicating mount failures or errors. This is where people usually get burned - they don’t check the logs and end up spending hours debugging.

Verify fstab entries: Ensure that fstab entries are correct and consistent. Use blkid to verify filesystem UUIDs and types:

blkid

Compare the output with your fstab entries to ensure accuracy. In practice, this is one of the most common issues I see.

Check mount options: Review mount options in fstab to ensure they are correct and compatible with the filesystem type. For example, using defaults with an ext4 filesystem is common, but you may need to specify additional options for other filesystem types.
Test mounts manually: Use the mount command to test mounts manually:

mount -a

This command will attempt to mount all filesystems specified in fstab. If a mount fails, the error message will indicate the cause.

Common Issues and Solutions

Some common issues that can cause failed mounts include:

Incorrect UUIDs: Ensure that UUIDs in fstab match the actual filesystem UUIDs.
Filesystem errors: Run fsck to check and repair filesystems:

fsck /dev/sda1

Replace /dev/sda1 with the actual device name. The real trick is to run fsck before trying to mount the filesystem.

Mount point issues: Verify that mount points exist and have the correct permissions.

Security Considerations

When troubleshooting failed mounts, it’s essential to consider security implications. For example, if a mount fails due to a permissions issue, it may indicate a security vulnerability. Ensure that mount points and filesystems have appropriate permissions and access controls.

Additional Resources

For more information on systemd and fstab, refer to the official systemd documentation and the kernel.org website.