Fix "You are in emergency mode" at Linux boot

journalctl -xb -p err
systemctl --failed
mount -o remount,rw /
nano /etc/fstab        # fix or comment out the bad line, or add nofail
systemctl daemon-reload
mount -a               # no output = fstab is valid
systemctl reboot

The full message systemd prints:

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.
Give root password for maintenance
(or press Control-D to continue):

What the error means

systemd could not reach local-fs.target or sysinit.target, so instead of a half-working system it started emergency.target: a root shell with the root filesystem mounted (often read-only) and almost no services. It is not a crash. The system is telling you something required at boot failed, and the journal says exactly what. Unlike a kernel panic about the root fs, the kernel did find and mount your root filesystem.

Step 1: find what failed

systemctl --failed
journalctl -xb -p err

Example output:

  UNIT                     LOAD   ACTIVE SUB    DESCRIPTION
● dev-disk-by\x2duuid-6f1c...device loaded failed failed /dev/disk/by-uuid/6f1c...
● mnt-data.mount           loaded failed failed /mnt/data

systemd[1]: Timed out waiting for device /dev/disk/by-uuid/6f1c2a7e-...
systemd[1]: Dependency failed for /mnt/data.
systemd[1]: Dependency failed for Local File Systems.

The .mount unit name maps to a path (mnt-data.mount is /mnt/data), and that path is a line in /etc/fstab. The journalctl cheat sheet has more filters if the output is long.

Cause 1: an fstab entry points to a missing or renamed disk

The most common cause: you removed or reformatted a disk, unplugged a USB drive listed in fstab, or reformatting changed its UUID. Compare fstab with what exists:

cat /etc/fstab
lsblk -f

Then make / writable and fix the line:

mount -o remount,rw /
nano /etc/fstab

• Disk is gone for good: comment out the line with #.
• UUID changed: replace it with the new UUID from lsblk -f or blkid.
• Disk is optional (USB, NAS, second drive): add nofail to the options, e.g. UUID=... /mnt/data ext4 defaults,nofail,x-systemd.device-timeout=10s 0 2.

Test before rebooting, because a mistake drops you right back here:

systemctl daemon-reload
mount -a
findmnt --verify

findmnt --verify catches typos, unknown filesystem types and missing devices. When it prints nothing alarming, run systemctl reboot.

Cause 2: the filesystem needs a manual fsck

If the journal says systemd-fsck failed, or shows UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY, repair it. For a non-root filesystem, unmount and check it right here:

umount /dev/sdb1
fsck -y /dev/sdb1

For the root filesystem, do not run fsck while it is mounted. Either reboot with fsck.mode=force fsck.repair=yes added to the kernel line in GRUB (press e at the menu; see kernel parameters), or boot a live USB and run sudo fsck -f /dev/nvme0n1p2 from there. If fsck reports errors repeatedly, check the drive's health as described in Read-only file system.

Cause 3: a typo or wrong option in fstab

A missing field, a wrong filesystem type (ext4 for a vfat partition), or an option the filesystem does not understand all fail the mount. The journal shows lines like wrong fs type, bad option, bad superblock or unknown filesystem type 'ntfs-3g'. Each fstab line needs six fields: device, mount point, type, options, dump, pass. For an NTFS partition use ntfs3 (kernel driver) or install ntfs-3g; for the EFI partition use vfat.

Cause 4: the root account is locked

On Ubuntu and other systems where root has no password, you get Cannot open access to console, the root account is locked and cannot log in. Get a shell another way:

1. Reboot and hold Shift (BIOS) or press Esc (UEFI) to show GRUB.
2. Press e on the default entry and append systemd.unit=rescue.target to the line starting with linux, or, if that also asks for a password, init=/bin/bash.
3. Press Ctrl+X to boot, then mount -o remount,rw / and fix fstab as above.
4. With init=/bin/bash there is no systemd, so reboot with sync followed by reboot -f.

A live USB works too: mount your root partition and edit /mnt/etc/fstab. If GRUB itself does not appear, see grub rescue fix.

Cause 5: a failed service or encrypted volume

Less often, a unit with OnFailure=emergency.target, a broken /etc/crypttab entry (a LUKS volume whose UUID changed) or a missing LVM volume triggers emergency mode. The journal names it. For crypttab, check UUIDs with blkid and add nofail for non-essential volumes. Run systemctl default to continue booting once the cause is fixed.

Distro-specific notes

• Ubuntu and Mint: root is locked by default, so use the GRUB edit trick above or the "Advanced options" recovery entry, choosing "root" from the menu. Ubuntu 26.04 builds its initramfs with Dracut; if you changed crypttab, regenerate it with sudo dracut --force (Ubuntu 24.04 and Debian use sudo update-initramfs -u).
• Debian: root usually has a password set during install; log in directly.
• Fedora: root is locked unless you enabled it in the installer. Use rd.break or a live USB; after editing files from rd.break run touch /.autorelabel so SELinux labels are restored.
• Arch: regenerate fstab from a live USB with genfstab -U /mnt > /mnt/etc/fstab after mounting everything, then review it.

How to prevent it

• Always add nofail to removable, network and secondary disks in fstab.
• Use UUID= rather than /dev/sdX, which can change between boots.
• After editing fstab, run sudo findmnt --verify and sudo mount -a before rebooting.
• Network shares need _netdev. The disk management guide explains fstab fields in full.

Frequently asked questions