Skip to content

Rescue and Emergency Mode

When a server fails to boot — say, an error in /etc/fstab, or a critical systemd unit failing — fixing the problem first requires getting into the system in some form. systemd provides two special, minimal targets for exactly this purpose: rescue.target and emergency.target.

This article brings together The Boot Process and GRUB and systemd troubleshooting — showing a practical recovery path for when the problem is specifically at the boot stage.

What You Will Learn

By the end of this article you will be able to:

  • explain the difference between rescue.target and emergency.target;
  • enter either mode through GRUB;
  • recover a forgotten root password;
  • fix a system that fails to boot because of an /etc/fstab error;
  • check whether the filesystem is currently read-only or read-write in emergency mode.

The Difference Between rescue.target and emergency.target

Target Filesystems Networking and other services When it's used
rescue.target Mounted normally (per /etc/fstab) Most services don't start, but the base system is ready Password recovery, fixing a simple configuration error
emergency.target Only root (/) is mounted, often read-only Almost nothing starts /etc/fstab is broken, or there's a problem mounting a filesystem

emergency.target is the most minimal state possible: if even rescue.target can't fully start (for example, because of an fstab error specifically), emergency.target usually still works, since it doesn't depend on other mounts.

Entering Rescue or Emergency Mode via GRUB

The temporary-parameter technique from The Boot Process and GRUB applies here directly:

  1. While the server is rebooting and the GRUB menu appears, interrupt it with Shift/Esc.
  2. Select the entry and press e.
  3. Append the target you need to the end of the line starting with linux:

For rescue mode:

linux   /boot/vmlinuz-... root=UUID=... ro   systemd.unit=rescue.target

For emergency mode:

linux   /boot/vmlinuz-... root=UUID=... ro   systemd.unit=emergency.target
  1. Boot with this state using Ctrl+X or F10.

This parameter applies only to the current boot — after a reboot, the system returns to its normal target.

Info

Some older documentation mentions a single or 1 parameter — this is a holdover from the SysV init era and corresponds to systemd.unit=rescue.target on a systemd system.

Recovering a Root Password

Once in rescue mode, most distributions either open a root shell automatically or prompt for the root password. If the root password itself is unknown, the following general approach applies:

  1. After entering via emergency.target or rescue.target, the root filesystem may be read-only — enable write access first:
mount -o remount,rw /
  1. Set a new password:
passwd root
  1. Reboot properly to make sure the change is correctly written to disk:
systemctl reboot

Danger

This method lets anyone with physical or console access (KVM/iLO/hypervisor console) reset the root password — this is a deliberate feature of Linux, not a vulnerability. Precisely because of this, controlling physical and console access (server room access, hypervisor permissions) is an integral part of password security.

When Rescue Mode Itself Asks for the Password You Lost

There is a catch: on most distributions rescue.target prompts for the root password before giving you a shell — useless when the root password is exactly what you've forgotten. The way around it is to bypass systemd entirely and have the kernel start a shell as PID 1, which no password guards:

  • Ubuntu/Debian — in the GRUB entry editor (e), find the linux line and replace ro quiet splash with rw init=/bin/bash, then boot with Ctrl+X. The kernel drops straight to a root shell with / already writable, so passwd root works immediately. Because normal shutdown isn't running, reboot afterward with exec /sbin/init or a forced reboot -f.
  • RHEL/Rocky/Fedora — append rd.break instead. This stops in the initramfs with the real root mounted read-only at /sysroot; remount it (mount -o remount,rw /sysroot), chroot /sysroot, run passwd, and — because SELinux is enforcing — touch /.autorelabel so the changed shadow file is relabelled on the next boot.

Danger

init=/bin/bash skips the entire service and mount stack, so tools normally taken for granted (logging, networking, a clean shutdown) are not running — do only the password reset and get back to a normal boot. Do not use this shell for general repair work; for that, boot into rescue.target (or emergency.target) properly instead.

Fixing a System That Won't Boot Because of an /etc/fstab Error

An incorrect UUID or a nonexistent mount point in fstab usually drops the system into emergency mode automatically and shows the cause on the terminal.

  1. Read the error message — it usually points to the problematic line or device.
  2. Make the filesystem writable if needed:
mount -o remount,rw /
  1. Edit fstab:
nano /etc/fstab
  1. Fix the problematic line, or comment it out temporarily (starting the line with #), then save.
  2. Verify the change without rebooting yet:
findmnt --verify
  1. Once confirmed clean:
systemctl reboot

This process complements the pre-flight check with findmnt --verify --tab-file covered in fstab — there it's used with a temporary test file, here in an actual recovery scenario.

Checking the Current State

Confirming which target is active in rescue or emergency mode:

systemctl get-default
systemctl list-units --type=target

Checking whether the filesystem is read-only or read-write:

findmnt -no OPTIONS /

The result shows either ro or rw.

Common Mistakes

Trying to Edit a File Without Remounting First

Root is often read-only under emergency.target. Without first running mount -o remount,rw /, saving fstab or any other file fails with a "Read-only file system" error.

Rebooting After Fixing fstab Without Verifying First

If a new error was introduced, the system drops back into emergency mode again. Checking with findmnt --verify beforehand avoids this cycle.

Treating Rescue and Emergency Mode as the Same Thing

Rescue mode mounts most filesystems and starts some services; emergency mode starts almost nothing. Picking the wrong mode for the situation can mean a needed tool (such as networking) simply isn't available.

Exercises

  1. In a disposable VM, enter rescue.target through GRUB and check which targets are active with systemctl list-units --type=target.
  2. In the same VM, enter emergency.target and compare the result of findmnt -no OPTIONS / with what you saw in rescue mode.
  3. In a test VM, add a deliberately broken line to /etc/fstab (for example, a nonexistent UUID), reboot, and observe the system dropping into emergency mode, then fix it following the process shown above.
  4. In rescue mode, change a test user's password with passwd and confirm the new password works after a normal reboot.

Verification criterion: given a boot failure caused by a bad fstab entry, you should be able to describe the full sequence from entering emergency mode to a clean reboot, without missing the remount step.

Summary

rescue.target and emergency.target are systemd's most minimal startup states, selected temporarily through GRUB with the systemd.unit= parameter. Rescue mode mounts more filesystems and services, while emergency mode opens only the root filesystem, often read-only. Both are used to recover a root password or fix configuration errors like /etc/fstab without a full reboot cycle — but the filesystem must first be reopened for writing with remount,rw.

References