Boot RHEL, Rocky and AlmaLinux into Rescue or Emergency Mode

A server that dies during boot leaves you exactly one tool: the console. When a bad /etc/fstab entry, a failed disk or a broken update stops the system short of a login prompt, systemd gives you two maintenance targets to get in and fix it. Rescue mode brings up a root shell with your filesystems mounted. Emergency mode gives you a root shell and almost nothing else. Knowing which one to ask for, and how to actually reach it from the GRUB menu, is the difference between a five minute fix and a bare metal reinstall.

Original content from computingforgeeks.com - post 47346

This guide shows how to boot RHEL into rescue mode or emergency mode from GRUB, the same steps on Rocky Linux, AlmaLinux, CentOS Stream and Fedora, plus the legacy single user mode shortcut and the systemctl commands that drop a running system into either target without touching the bootloader. Everything below was run on a Rocky Linux 10.1 console (systemd 257, GRUB 2.12) in August 2026, and the behavior is identical across the supported RHEL releases and their rebuilds.

Rescue Mode vs Emergency Mode

Rescue mode (rescue.target) boots the base system: systemd mounts every local filesystem from /etc/fstab, runs the early sysinit services, then hands you a root shell. It is the direct successor of single user mode, and the old runlevel 1 maps onto it. Emergency mode (emergency.target) skips all of that. The root filesystem stays exactly as the kernel left it, which on the RHEL family means read-only because the shipped kernel command line carries ro and the remount service never runs in this target. Nothing else gets mounted, no services start beyond the journal, and you get a shell on the console. The systemd.special documentation defines both targets.

The practical split, from the test box:

Item	Rescue mode	Emergency mode
Kernel parameter	systemd.unit=rescue.target	systemd.unit=emergency.target
Root filesystem	Mounted read-write	Mounted read-only
Other fstab mounts	All mounted (/boot, /boot/efi, data volumes)	None
Services	sysinit basics, udev, journal	Journal only
Network / SSH	Down, sshd inactive	Down
Legacy equivalent	Single user mode, runlevel 1	None
Use it for	Package rollbacks, chasing a failed service, filesystem repair on data volumes	Broken /etc/fstab, corrupt root filesystem, anything that must run before mounts

Neither mode brings up networking. SSH is dead in both, so you need physical console access, an out-of-band controller like iDRAC or iLO, or the virtual console of your hypervisor. Plan for that before the day you need it.

Set a Root Password Before You Need One

Both targets authenticate through sulogin, which asks for the root password. Cloud images and many kickstart builds ship with the root account locked, and a locked root turns both maintenance modes into a dead end. This catches people out at the worst possible moment. Check now, on a healthy system:

sudo passwd -S root

An L in the second column means locked. Set a password and store it in your password manager:

sudo passwd root

Boot into Emergency Mode from the GRUB Menu

Reboot the machine and watch for the boot menu. Press any key except Enter during the countdown to freeze it. On servers where the menu asks for credentials because you protected the GRUB bootloader, unlock it first.

With the default kernel highlighted, press e to edit the entry. Arrow down to the line that starts with linux, press Ctrl+e or End to jump to the end of it, and append the target:

systemd.unit=emergency.target

The edited line wraps on screen, which is normal. One space between the existing arguments and the new one is all it needs:

Press Ctrl+x or F10 to boot the edited entry. The edit is one-shot. It changes nothing on disk, so the next reboot comes up normally. A few seconds later the console reaches emergency mode and prints:

You are in emergency mode. After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, or "exit"
to continue bootup.
Give root password for maintenance
(or press Control-D to continue):

Type the root password and you are in.

Error: “Cannot open access to console, the root account is locked”

If root has no password, sulogin cannot authenticate anyone and the console prints this instead of a login prompt:

Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.

Press Enter to continue.

This is the exact screen on our test console:

Pressing Enter abandons the maintenance shell and continues a normal boot. If the system still boots, log in over SSH, run sudo passwd root and try again. If it no longer boots at all, the way in is rd.break, which stops inside the initramfs before any password check. That flow is covered step by step in our guide to reset the root password on RHEL, Rocky and AlmaLinux.

Work Inside the Emergency Shell

The first thing to know about the emergency shell: the root filesystem is read-only. Any attempt to edit /etc/fstab or move files fails until you remount it. Confirm the state:

mount | grep -w /

The ro flag in the output is the tell:

/dev/vda4 on / type xfs (ro,relatime,seclabel,attr2,inode64,logbufs=8,logbufsize=32k,noquota)

Remount it read-write and the shell becomes useful:

mount -o remount,rw /

The command returns silently on success. Checking the flags again shows the flip from ro to rw:

From here the usual repair moves apply. Read the boot log to see what failed:

journalctl -xb

Fix the broken fstab line, run a filesystem check on an unmounted volume, or comment out whatever unit dragged the boot down. Three ways out when you are done: exit continues the interrupted bootup, systemctl default starts the default target, and systemctl reboot starts clean. All three worked as advertised in this lab.

Boot into Rescue Mode

The GRUB flow is the same, only the parameter changes. Interrupt the menu, press e, and append this to the linux line:

systemd.unit=rescue.target

Boot with Ctrl+x and watch the difference on the console. Rescue mode mounts /boot and /boot/efi, reaches local-fs.target and sysinit.target, starts udev and the journal, then drops to the maintenance prompt:

After logging in with the root password, the environment is a small but complete system. The root filesystem is already read-write, every fstab volume is mounted, and tools that need /boot (kernel updates, GRUB repairs, initramfs rebuilds) work directly. Networking stays down:

df -h -t xfs
ip -br addr
systemctl is-active sshd

On the test box that returned both mounts, an interface in DOWN state and an inactive sshd:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda4        19G  1.4G   18G   8% /
/dev/vda3       936M  273M  664M  30% /boot
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens18            DOWN
inactive

Captured live during the rescue session:

Rescue mode is the right place to repair ext4 and XFS file systems on data volumes, downgrade a package that broke a service, or rebuild an initramfs. The same exits apply: exit, systemctl default or systemctl reboot.

Use the Legacy Single User Mode Shortcut

Old habits from the SysV era still work. Appending a bare 1 to the linux line boots straight into rescue.target, verified on this lab. systemd also accepts single, s and S as the same alias, and emergency as shorthand for the emergency target. Once inside, systemd is explicit about what happened:

systemctl get-default

With the alias on the kernel command line, the answer comes with a footnote:

multi-user.target
Note: found "1" on the kernel command line, which overrides the default unit.

The runlevel command keeps translating too. After moving from the alias boot back to a full boot it printed 1 3, previous runlevel one, current runlevel three. If you ever need a kernel argument to survive reboots rather than a one-shot GRUB edit, set it permanently with grubby instead of editing menu entries by hand.

Drop a Running System into Rescue or Emergency Mode

No reboot is required when the system is still up. systemd switches targets live:

sudo systemctl rescue

Or for the minimal environment:

sudo systemctl emergency

Both are wrappers around systemctl isolate rescue.target and systemctl isolate emergency.target. Be clear about what you are signing up for: the moment either command runs, networking stops and your SSH session dies mid-keystroke. Both times we ran it from an SSH session, the connection dropped and the maintenance prompt appeared on the virtual console only. Never run these on a remote machine unless a console path exists, because the console is the only way back. systemctl default from the console returns the system to normal operation.

The 0-rescue GRUB Entry Is Not Rescue Mode

The boot menu on nearly every RHEL family system carries an entry with 0-rescue and a machine ID in its name (it comes from the dracut-config-rescue package, so minimal and cloud images sometimes lack it), and it misleads people constantly. That entry has nothing to do with rescue.target. It is a fallback kernel paired with a fat initramfs built at install time, one that includes every driver instead of only the hardware-specific set. You boot it when the regular kernel or its initramfs is broken, and it starts the system to the normal default target. Booting the 0-rescue entry lands you at the standard login prompt, not a maintenance shell. To reach rescue mode from it, edit its linux line exactly as above.

Which Mode to Reach For

Root filesystem damaged or fstab broken: emergency mode, remount read-write, fix, reboot. Service or package broke the boot but the filesystems are fine: rescue mode, where mounts and journalctl are already waiting. Root password lost: neither works, go through rd.break and the initramfs. Kernel or initramfs will not boot at all: the 0-rescue GRUB entry, then rebuild the broken one. Whichever you pick, the two minutes it takes to set a root password and test console access on a healthy system is what makes any of them usable on a broken one.