Recovering from emergency mode after a bad /etc/fstab entry on Ubuntu 24.04: a single‑command root shell solution

 Posted on 23 October 2026  |  3 minutes  |  433 words  |  Carla Brown

A One‑Command Escape from Emergency Mode

When a typo in /etc/fstab stops the root filesystem from mounting, Ubuntu 24.04 drops straight into emergency mode. You get a read‑only root shell, but that’s not useful because you can’t edit the offending line—root is already mounted read‑only. The usual fix is to reboot, pull out a live USB, and patch the file from there.
There’s a much quicker way that keeps you on the same machine, preserves the state, and lets you fix the problem in place.

The trick: systemctl rescue

systemctl rescue pulls the system into the rescue target, a stripped‑down version of emergency mode that remounts the root filesystem read‑write and gives you a normal root prompt. Just run:

sudo systemctl rescue

Systemd stops all units, remounts / read‑write, and starts rescue.target. The prompt changes to:

root@hostname:#

Now you have a fully functional shell with the same privileges as a normal boot, so you can edit /etc/fstab right away.

Security note – The rescue target runs with the same privileges as the normal system. Don’t run untrusted code here. If you suspect the machine is compromised, boot from a trusted live image instead.

Fixing the entry

  1. Open the file with whatever editor is available (nano, vi, etc.):

    nano /etc/fstab

  2. Find the bad line. A common slip is a missing UUID= or a wrong mount point:

    - /dev/sda2 /data ext4 defaults 0 2
+ UUID=1234-5678 /data ext4 defaults 0 2

  3. Save and exit.

  4. Reboot into normal mode:

    reboot

The system should now start up normally.

Why this works

  • systemctl rescue sidesteps the normal boot sequence that would try to mount all filesystems listed in /etc/fstab.
  • The root filesystem is remounted read‑write, so you can edit it in place.
  • No external media or network access is needed, keeping the attack surface low.

Trade‑offs and cautions

Situation Recommendation
Multiple broken mounts Use systemctl rescue and comment out the problematic lines instead of editing them immediately.
Encrypted root Rescue mode won’t decrypt the root partition. Boot from a live image or unlock it with cryptsetup first.
Systemd disabled On very old systems (pre‑systemd) this method won’t work; use a rescue ISO.
Persistent issues After fixing, run systemd-analyze blame to make sure no other units are failing.

Quick checklist before reboot

# Verify the fstab syntax
sudo mount -a -v

# Spot typos
grep -v '^#' /etc/fstab | grep -v '^$'

# Make sure UUIDs match the actual devices
sudo blkid

If mount -a still reports errors, the problem isn’t solved. Fix it again and try a fresh reboot.

  • systemd.io – rescue.target
  • kernel.org – systemd documentation
linux  systemd  troubleshooting 

See also