🚨 Linux Error Guide: 'You are in emergency mode' — Repair a Broken /etc/fstab Boot

Overview

When systemd cannot satisfy a required mount at boot, it stops the normal startup and drops you to a rescue shell with this banner:

You are in emergency mode. After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or "exit"
to boot into default mode.

Cannot open access to console, the root account is locked.
Give root password for maintenance
(or press Control-D to continue):

The trigger is almost always a local-fs.target dependency that failed — most often an /etc/fstab entry pointing at a disk, UUID, or network share that no longer exists or cannot be mounted.

Symptoms

• Boot halts at Give root password for maintenance (emergency) or an earlier rescue shell.
• systemctl --failed lists a *.mount unit or local-fs.target as failed.
• journalctl -b contains Dependency failed for /mnt/data and Timed out waiting for device.
• The system booted fine yesterday and only broke after editing fstab, cloning a disk, or removing an external drive.
• Pressing Ctrl-D repeatedly loops back to emergency mode instead of continuing.

Common Root Causes

• Stale UUID or device path in fstab — a disk was reformatted, replaced, or cloned, so the UUID= no longer matches; systemd waits, times out, and fails.
• Removed or unplugged drive — an external/USB or secondary disk listed without nofail is simply gone.
• Typo in fstab — a misspelled mount point, filesystem type, or option makes the entry unmountable.
• Unreachable network mount — an NFS/CIFS entry without nofail/_netdev blocks local-fs.target when the server is down.
• Filesystem corruption — the target device exists but fails fsck, so the mount is refused.
• Wrong filesystem type — ext4 declared for an xfs volume (or vice versa) fails at mount time.

Diagnostic Workflow

Log in with the root/maintenance password, then read this boot’s log to find the failed unit — this is the single most useful step:

journalctl -b --no-pager | grep -iE 'fail|timed out|fstab|mount'
systemctl --failed

The root filesystem is usually mounted read-only in emergency mode; remount it read-write so you can edit files:

mount -o remount,rw /

Inspect the offending fstab entry and confirm the device actually exists and its real UUID/type:

cat /etc/fstab
lsblk -f
blkid

Validate that fstab would mount cleanly without rebooting — this is the safe way to test a fix:

findmnt --verify --verbose
mount -a          # attempts all fstab mounts; reports the exact failure

If a specific device is suspected corrupt, check it:

fsck -n /dev/sdXN     # read-only check first

Example Root Cause Analysis

After adding a second data disk, a server reboots straight into emergency mode. Logging in and running journalctl -b | grep -i fail shows Timed out waiting for device /dev/disk/by-uuid/8f3c... and Dependency failed for /mnt/data. The admin remounts root read-write with mount -o remount,rw /, then compares /etc/fstab against blkid: the fstab line uses UUID 8f3c..., but blkid reports the new disk’s actual UUID as b17e.... The disk had been reformatted after the fstab line was written, changing its UUID.

The fix was to correct the UUID and make the non-critical mount non-blocking:

# /etc/fstab
UUID=b17e-...  /mnt/data  ext4  defaults,nofail,x-systemd.device-timeout=10s  0  2

Running mount -a then succeeded with no reboot, and findmnt --verify reported clean. The takeaway: nofail (plus a short x-systemd.device-timeout) turns a missing or wrong data mount into a logged warning instead of a boot-stopping failure — reserve strict blocking behavior for filesystems the system genuinely cannot run without.

Prevention Best Practices

• Always run findmnt --verify (or mount -a on a spare login) after editing /etc/fstab, before rebooting.
• Add nofail to every non-root, non-essential mount so a missing disk logs a warning instead of dropping to emergency mode.
• Add _netdev and nofail to network mounts (NFS/CIFS) so they wait for the network and never block local boot.
• Reference filesystems by UUID= (stable across reordering) rather than /dev/sdX (which can renumber).
• Set x-systemd.device-timeout= to a few seconds so absent devices fail fast instead of hanging at boot.
• Keep console/serial access or a live-USB recovery plan for headless servers where you cannot type a maintenance password remotely.

Quick Command Reference

journalctl -b | grep -iE 'fail|timed out|mount'   # what failed this boot
systemctl --failed                                # failed units
mount -o remount,rw /                             # make root writable to edit fstab
lsblk -f; blkid                                   # real device UUIDs/types
findmnt --verify --verbose                        # validate fstab safely
mount -a                                          # apply fstab without reboot
# add to a risky fstab line: defaults,nofail,x-systemd.device-timeout=10s
systemctl default                                 # continue booting after fix

Conclusion

Emergency mode is systemd protecting you: a required mount from /etc/fstab failed, so it stopped rather than boot into a half-broken state. The repair loop is always the same — log in, journalctl -b to find the failed *.mount, remount root read-write, correct the fstab entry against real blkid/lsblk data, then prove the fix with findmnt --verify and mount -a before rebooting. Going forward, add nofail and sensible device timeouts to every non-essential mount so one missing disk never again holds the whole system hostage.