Introduction to Emergency Mode
I’ve seen my fair share of Linux systems dropping into emergency mode, and it’s usually due to a critical issue during boot. This mode provides a minimal environment for troubleshooting and repair, which can be a lifesaver. One common issue that can lead to emergency mode is a failed mount. In this article, I’ll walk you through how to troubleshoot failed mounts in emergency mode with systemd.
Understanding Emergency Mode
Emergency mode is a special mode in systemd that gives you access to a minimal shell environment when the system can’t boot normally. This can happen due to a variety of reasons, including failed mounts, corrupted file systems, or misconfigured system services. When in emergency mode, you’ll have limited access to system resources, but you can still perform basic troubleshooting and repair tasks. Don’t bother with trying to fix everything at once - just focus on getting the system stable enough to boot normally.
Identifying Failed Mounts
To identify failed mounts, you can check the systemd journal logs. In emergency mode, you can use the journalctl command to view the logs:
journalctl -xb
This command will show you the boot logs, including any error messages related to failed mounts. Look for messages that indicate a mount failure, such as “Mounting /mnt/data failed” or “Error mounting /dev/sdb1”. I usually start with this command to get an idea of what went wrong.
Troubleshooting Failed Mounts
Once you’ve identified the failed mount, you can start troubleshooting. Here are some common issues that can cause mount failures:
- File system errors: If the file system is corrupted, you may need to run a file system check (fsck) to repair it. You can use the
fsckcommand to check and repair the file system:
fsck /dev/sdb1
Be careful when running fsck, as it can potentially cause data loss if not used correctly.
- Incorrect mount options: If the mount options are incorrect, you may need to adjust them. You can check the current mount options using the
mountcommand:
mount | grep /mnt/data
- Device issues: If the device is faulty or not properly connected, you may need to check the device status using the
lsblkcommand:
lsblk
This command will show you the device status, including any errors or warnings. The real trick is to identify the root cause of the issue, rather than just treating the symptoms.
Repairing Failed Mounts
If you’ve identified the issue, you can try to repair the failed mount. Here are some common repair steps:
- Remounting the file system: If the file system is corrupted, you may need to remount it after running fsck. You can use the
mountcommand to remount the file system:
mount -o remount /mnt/data
- Adjusting mount options: If the mount options are incorrect, you can adjust them using the
mountcommand:
mount -o noatime /mnt/data
- Replacing a faulty device: If the device is faulty, you may need to replace it. Make sure to backup any important data before replacing the device. This is where people usually get burned - don’t forget to backup your data before making any changes.
Rebooting the System
Once you’ve repaired the failed mount, you can try to reboot the system. Use the reboot command to restart the system:
reboot
If the system boots normally, you’ve successfully repaired the failed mount. If the system still drops into emergency mode, you may need to continue troubleshooting. In practice, it’s not always easy to identify the root cause of the issue, so be patient and don’t be afraid to try different approaches.
Additional Resources
For more information on troubleshooting failed mounts, you can check the systemd documentation. Additionally, you can check the kernel documentation for more information on file systems and device management. These resources can be a bit overwhelming, but they’re definitely worth checking out if you want to dive deeper into the world of Linux troubleshooting.
See also
- Recovering from a Failed Borg Backup Repository: Lessons Learned from a Homelab Mishap
- Troubleshooting Podman Container Networking Issues with rootless Containers and FirewallD
- Taming Systemd Services that Refuse to Die: How I Learned to Stop Worrying and Love the `--no-block` Option
- Taming systemd Service Restart Behavior with StartLimitBurst and StartLimitInterval
- Taming System Load Spikes with nice, ionice, and cgroups on a Home Server