FSTAB Misconfiguration — Dropped to Emergency Mode on Boot

The Symptom

#

After rebooting, the system failed to start normally and showed:

You are in emergency mode.
Give root password for maintenance.

The boot process stopped before reaching the login screen.

What /etc/fstab Does

#

/etc/fstab defines which filesystems should be mounted during boot.

Each entry tells the system:

• What device to mount
• Where to mount it
• Filesystem type
• Mount options
• Boot order

If an entry is incorrect, systemd may fail to mount it.
When that happens, boot can stop and drop into emergency mode.

What Went Wrong

#

I had manually added a new disk entry in /etc/fstab.

The UUID I entered was incorrect.

During boot, systemd attempted to mount a device that did not exist.
Since the entry was marked as required, the system could not continue.

How I Diagnosed It

#

From emergency mode:

1. Checked block devices: lsblk

   admin@linuxsprout-PC:~$ lsblk

   NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 238.5G 0 disk ├─sda1 8:1 0 47.6G 0 part / ├─sda2 8:2 0 100.8G 0 part /media/linuxsprout/Storage └─sda3 8:3 0 96M 0 part /boot/efi

2. Verified UUIDs blkid

   admin@linuxsprout-PC:~$ blkid

   /dev/sda1: UUID=“fa7xxxxxxxxxx-xxxxx-xxxx-xxxx” BLOCK_SIZE=“4096” TYPE=“ext4” PARTUUID=“9xxxxxx-xxxxxx-xxxxxx-xxxx”

The UUID in /etc/fstab did not match the actual disk UUID. To confirm the issue without rebooting again, I ran:

mount -a

This immediately showed the mounting error.

That confirmed the misconfiguration.

The Fix

#

Original incorrect entry:

UUID=wrong-uuid-value /data ext4 defaults 0 2

Corrected entry:

UUID=correct-uuid-value /data ext4 defaults 0 2

After saving the file, I tested again:

mount -a

No errors were returned. I rebooted, and the system started normally.

What I Learned

#

• Always verify UUIDs using blkid before editing /etc/fstab
• Test changes with mount -a before rebooting
• Use the nofail option for non-critical secondary drives
• A single incorrect line in /etc/fstab can stop the entire boot process

Boot failures often look complicated, but in this case the root cause was a simple configuration mistake.

Understanding how /etc/fstab interacts with systemd makes recovery straightforward.