This post focuses on manually repairing the file-system configuration or corruption issues that stop the boot process.
Diagnosing and fixing file system issues
Errors in /etc/fstab and corrupt file systems can stop a system from booting. In most cases, systemd drops to an emergency repair shell that requires the root password. The following table lists some common errors and their results.
Common File System Issues
| PROBLEM | RESULT |
|---|---|
| Corrupt file system | systemd attempts to repair the file system. If the problem is too severe for an automatic fix, the system drops the user to an emergency shell. |
| Nonexistent device or UUID referenced in /etc/fstab | systemd waits for a set amount of time, waiting for the device to become available. If the device does not become available, the system drops the user to an emergency shell after the timeout. |
| Nonexistent mount point in /etc/fstab | The system drops the user to an emergency shell. |
| Incorrect mount option specified in /etc/fstab | The system drops the user to an emergency shell. |
In all cases, administrators can also use the emergency target to diagnose and fix the issue, because no file systems are mounted before the emergency shell is displayed.
CentOS / RHEL 7 : How to boot into emergency or multi-user mode from GRUB2
CentOS / RHEL 7 : How to boot into Rescue Mode or Emergency Mode
The nofail option in an entry in the /etc/fstab file permits the system to boot even if the mount of that file system is not successful. Do not use this option under normal circumstances. With nofail, an application can start with its storage missing, with possibly severe consequences.