[Linux] Emergency Mode and /etc/fstab

Matthew Estes
Matthew Estes
  • Updated

Document Scope

This article will discuss why your system might enter emergency mode on boot and how to resolve it by editing your drives being mounted at boot.

What is Emergency Mode?

'Emergency mode' is typically triggered by discrepancies in the 'fstab' file, which is the list of partitions expected to mount when the system boots. While this isn't the ONLY reason you might see emergency mode at boot, it tends to be the most frequent and also, luckily, fairly easy to resolve.

Reasons a drive may not be read as expected include failed drives or perhaps just a drive that has jostled loose in shipping. Before delving into system file edits, it's advisable to re-seat all drives (SATA, M.2's, U.2's, SAS) to check if an improper physical connection is causing the problem.

Another reason for a failed boot to emergency mode is that someone has edited /etc/fstab incorrectly and the system has a syntax error. In addition to reseating drives, we recommend checking with any other users about any recent drive additions or removals. Users might have added drives to existing RAID mounts but omitted updating the 'fstab' file or used an alternative 'mount' method without following proper procedures. If all else fails, you can use the below steps to try and visually identify the drive that is causing the problem.

Step 1: Abnormal Boot loads to 'Emergency Mode'

The last thing we want to see on a boot is that it doesn't boot as expected. In the below screenshot, the system has booted to emergency mode to indicate SOME kind of problem. If you drive/partition mounts encounter issues, you are likely to end up here. Avoid using 'Control-D' to exit and instead, gather and provide logs as this method of resolving the issue is essentially an extended way of indicating that something crucial is missing.

Screenshot 2024-03-14 at 1.27.18 AM.png

Step 2: Access the Command Prompt by Entering the Root Password

Depending on your OS, you will either be asked for a root password to enter maintenance or you will simply be prompted to press enter (as in the above screenshot). Follow the instructions and you should now have a root prompt.

Step 3: Gather Expected UUIDs

Execute the Command 'cat /etc/fstab':

Screenshot 2024-03-14 at 1.23.48 AM.png

This file, /etc/fstab, is the list of drives/partitions that your system expects to mount when it boots. If one of these can't be found, you'll find yourself in emergency mode. In addition to the system partitions you can see we've added 4 drives that mount at /data1 - /data4.

Make note of these IDs as we will be comparing them to the UUIDs your system can ACTUALLY see shortly. To get that list, we'll now run blkid.

Step 4: Identify the Missing Mount UUID using blkid and lsblk

Using a combination of the lsblk and blkid commands, you can determine the mounts and UUIDs the system can see, and comparing that to the above /etc/fstab output will let you hopefully determine what's missing.

Screenshot 2024-03-14 at 1.56.10 AM.png

Screenshot 2024-03-14 at 1.55.44 AM.png

In these examples we purposefully removed /dev/sde1 which mounts at /data4.

Step 5: Comment Out the Missing UUID in 'fstab'

Use your favorite text editor to modify /etc/fstab and comment out the offending drive with a '#'. In thebelow screenshot we've used vi and you can see the final line is now all teal, indicating it will be ignored the next time the system boots.

Screenshot 2024-03-14 at 1.35.59 AM.png

Step 6: Reboot the System to Verify Changes

Execute the 'reboot' command and if all has been done correctly, you should now see a login screen!

Screenshot 2024-03-14 at 1.41.33 AM.png

Was this article helpful?

0 out of 0 found this helpful

Have more questions? Submit a request

Comments

0 comments

Please sign in to leave a comment.