Ubuntu Server Booting Into Emergency Mode: A Step-by-Step Rescue Guide

Your Ubuntu Server restarts after an update or power interruption, then stops at an “Entering emergency mode” prompt. SSH is unavailable, services are down, and the console asks for maintenance. This usually means systemd could not complete a required boot step, often because a filesystem check failed or a required mount could not be found. Treat the message as a clue: identify the failed unit before editing files or running a repair command.

This guide applies to conventional Ubuntu Server installations using systemd. Commands and boot menus can differ on Ubuntu Core, encrypted systems, cloud images, and provider-managed servers. The current Ubuntu manpages describe emergency.target as a minimal shell that does not start normal services or mount ordinary filesystems; depending on how it was reached, the root filesystem can be read-only or read-write. That is why the first steps are inspection and a backup.

1. Read the failure before changing anything

Log in at the local or provider console if prompted. On a physical machine, connect a keyboard and monitor; on a virtual server, use the provider’s serial or recovery console. Photograph or copy the full error, especially a unit name such as systemd-fsck@dev-disk-by-uuid-....service or a mount unit ending in .mount. A missing UUID, failed filesystem check, and broken service need different fixes.

From the emergency shell, inspect failed units and the current boot log:

systemctl --failed
journalctl -xb

Look for the first meaningful error, not just the final “dependency failed” line. If the log identifies a mount, note its mount point and device UUID. If it identifies a service unrelated to storage, do not start changing /etc/fstab at random; inspect that specific unit with systemctl status unit-name and its recent log messages.

2. Check whether the root filesystem allows edits

Before editing a configuration file, see how the root filesystem is mounted:

findmnt /

If the options show ro, the root filesystem is read-only. If the filesystem is otherwise healthy and you need to make a small configuration repair, remount it read-write:

mount -o remount,rw /

Run findmnt / again to confirm the change. If the remount fails, stop and record the error. A read-only root can be a protective response to filesystem trouble; forcing writes or repeatedly retrying a mount can make recovery harder. Use a rescue environment or provider support if the root volume appears damaged.

3. Inspect disks and compare them with /etc/fstab

A common cause is a stale /etc/fstab entry: a disk was removed, a UUID changed, or a mount path was mistyped. First list detected filesystems and their identifiers:

lsblk -f
blkid

Then read the mount table configuration:

cat /etc/fstab

Match each configured UUID with the output from lsblk -f or blkid, and check that the mount point and filesystem type are correct. Do not substitute a device name such as /dev/sdb1 based only on its current letter; device ordering can change. UUIDs are often more stable, but they still need to match the actual filesystem.

The /etc/fstab file is translated into systemd mount units at boot. Its fields and options have specific meanings, so consult the official Ubuntu fstab manual if an entry is unfamiliar.

4. Temporarily bypass an optional missing mount

If the failing entry points to a nonessential data disk that is intentionally absent, back up /etc/fstab, then comment out only that one line by placing # at its beginning. This lets you test whether the missing mount is the boot blocker. Do not comment out the root filesystem, /boot, or an encrypted-volume entry unless you understand the system’s storage layout.

cp -a /etc/fstab /etc/fstab.before-emergency-fix
nano /etc/fstab

Alternatively, if the disk should be optional in normal operation, consider the nofail mount option after verifying the intended behavior. Use it only for a genuinely optional mount: adding it to a required system volume can hide a real storage failure. Network filesystems may need additional systemd-specific options and network dependencies; do not copy options from an unrelated setup.

After editing, ask systemd to reload generated units and test the file:

systemctl daemon-reload
mount -a

Read all output. A clean return does not prove that every application can use the mounted data, but a reported UUID, syntax, or mount error tells you what remains to fix. The systemd-fstab-generator manual explains how systemd converts fstab entries into mount units.

5. Repair a bad UUID, path, or mount option

If the disk is present but its UUID differs, verify that you have identified the correct filesystem before updating the matching UUID=... field. Confirm the mount point directory exists, the filesystem type is accurate, and the options are valid for that filesystem. Correct one entry at a time, then rerun systemctl daemon-reload and mount -a.

For a removable or secondary data disk that is optional, setting an appropriate optional-mount policy may prevent an absent device from blocking boot. For a critical volume, fix the device, cable, encryption mapping, or identifier instead of masking the failure. If the failed unit names a LUKS or LVM device, inspect the related mapping and volume state; do not replace its UUID with a similarly named partition.

6. Run a filesystem check only when the target is unmounted

If the console specifically reports filesystem errors, identify the filesystem type and device before repairing it. Do not run a repair utility against a filesystem that is mounted, especially the active root filesystem. The Ubuntu fsck manual describes the wrapper command; the correct checker and repair options depend on the filesystem.

For an ext2, ext3, or ext4 data partition, first confirm it is not mounted with findmnt. If it is mounted, unmount it before checking. A typical ext4 check from a suitable rescue environment is:

sudo e2fsck -f /dev/DEVICE

Replace /dev/DEVICE only after matching the correct partition from lsblk -f. Read the checker’s questions and status; do not append an automatic “yes to everything” option without understanding the data-loss risk. For a root filesystem that cannot be unmounted from the running emergency shell, boot a live or provider recovery environment and check it while offline. Btrfs, XFS, and other filesystems use different tools and repair procedures. In particular, do not treat a generic fsck command as proof that every filesystem type was repaired.

7. Use GRUB or external recovery only when the shell is unavailable

If the server never reaches an emergency shell, open the GRUB menu and try the distribution’s recovery entry when one is available. On a standard Ubuntu installation, the menu is often reached by holding Shift on legacy BIOS systems or tapping Esc on UEFI systems, but hosted virtual machines can use a different console flow. For a one-time systemd emergency boot, an administrator can edit the selected GRUB entry and add systemd.unit=emergency.target to the Linux kernel command line. The change applies to that boot only; remove it before the next normal boot. See the official GNU GRUB menu reference.

If the boot volume cannot be mounted, use a live Ubuntu environment or the cloud provider’s rescue system to inspect it. Unlock encrypted storage and activate LVM only if that matches the installation. Mounting a server’s root filesystem from recovery has additional risks; avoid writing to it until the disk and filesystem have been identified. Ubuntu Core uses its own recovery workflow and is not repaired by blindly following desktop or conventional Server GRUB steps.

8. Reboot and verify the repair

When the reported cause is corrected and mount tests pass, reboot:

reboot

After startup, verify that the host reaches its usual multi-user target, the expected filesystems are mounted, and the important services are active:

systemctl is-system-running
systemctl --failed
findmnt --target /

Check expected data mount points with findmnt /path/to/mount, and confirm critical services with systemctl status service-name. If emergency mode returns, review the new boot’s first failure again rather than repeating the same repair. A successful rescue means the server completes a normal boot and its required storage and services are available; merely reaching a login prompt is not enough.

For current systemd behavior, see the Ubuntu special units manual. Package versions and recovery menus can vary by Ubuntu release and hosting platform, so use the documentation for the installed release when a command or unit differs.