DEV Community

Cover image for How to Boot into rescue mode in RHEL 7 / CENTOS 7
FlatlinerAtheist | CLI-NERDS
FlatlinerAtheist | CLI-NERDS

Posted on Originally published at clinerds.com

How to Boot into rescue mode in RHEL 7 / CENTOS 7

Rescue mode provides a convenient single-user environment and allows you to repair your system in situations when it is unable to complete a normal booting process. In rescue mode, the system attempts to mount all local file systems and start some important system services, but it does not activate network interfaces or allow more users to be logged into the system at the same time. In Red Hat Enterprise Linux 7, rescue mode is equivalent to single user mode and requires the root password.

If you are already logged in as root at a local console, you can enter emergency mode directly. Use the console rather than SSH because emergency mode deactivates network interfaces:

[root@linuxlab01 ~]# systemctl emergency
Enter fullscreen mode Exit fullscreen mode

To enter rescue mode during boot instead, select a kernel on the GRUB 2 screen and press e to edit. Find the line starting with linux16 and append systemd.unit=rescue.target, then press Ctrl+X to boot.

When prompted, enter the root password. You can then perform maintenance tasks such as inspecting disks, editing files with vi, or checking an unmounted filesystem.

Rescue mode vs emergency mode vs single-user mode

These three get mixed up constantly, so it helps to know which one you actually want before you are staring at a broken boot:

  • Rescue mode (rescue.target) mounts your filesystems and starts basic services, but no networking. Use this when the system boots partially and you need to repair config files, reset a password, or run fsck.
  • Emergency mode (emergency.target) is even more minimal: only the root filesystem is mounted, and read-only at that. Use this when rescue mode itself will not start — for example when a bad fstab entry stops the boot.
  • Single-user mode is the older SysV term; on RHEL 7 and later, rescue mode is its systemd equivalent.

Booting into rescue mode from GRUB, step by step

  1. Reboot and wait for the GRUB menu. If it does not appear, hold Shift (BIOS) or tap Esc (UEFI) during boot.
  2. Highlight your normal kernel and press e to edit — this does not change anything permanently, only this one boot.
  3. Find the line starting with linux16 (or linux on newer releases) and add systemd.unit=rescue.target at the end, separated by a space.
  4. Press Ctrl+X to boot with that temporary parameter.

When prompted, enter the root password. You land in a root shell where you can edit files, check logs with journalctl -xb, or run filesystem checks.

The mistakes that cost people an hour

Forgetting to remount read-write. In emergency mode the root filesystem is read-only, so every edit fails until you run:

mount -o remount,rw /
Enter fullscreen mode Exit fullscreen mode

A broken fstab is the most common reason you are here. If boot fails right after you edited mounts, comment out the new line in /etc/fstab instead of debugging anything else first. Adding nofail to non-essential mounts (USB drives, secondary disks) prevents this entire class of boot failure.

No networking in rescue mode is normal. ping will not work, and that is expected, not a new problem. If you need the network to download a package, boot normally with a working kernel instead.

Inspect the failure before changing anything

Start with evidence instead of running several repair commands and hoping one works:

systemctl --failed
journalctl -xb --no-pager
lsblk -f
findmnt
Enter fullscreen mode Exit fullscreen mode

The first two commands show failed units and detailed boot messages. lsblk -f identifies block devices and filesystem types, while findmnt shows what is actually mounted. Before editing a configuration file, keep a backup, for example cp -a /etc/fstab /etc/fstab.before-rescue.

After changing /etc/fstab, run systemctl daemon-reload, then mount -a to test the entries. Read any error carefully; do not assume the repair worked just because a prompt returned.

Check filesystems safely

Never run a repair utility on a mounted filesystem. For a non-root ext4 filesystem, unmount it first and substitute the device name shown by lsblk:

umount /dev/sdb1
fsck /dev/sdb1
Enter fullscreen mode Exit fullscreen mode

RHEL 7 and CentOS 7 commonly use XFS. For an unmounted XFS filesystem, use xfs_repair /dev/sdb1 instead of fsck. Do not use xfs_repair -L merely to bypass a log-related error; zeroing the log can cause data loss and should be a last resort after exhausting safer options.

You cannot unmount the root filesystem while running from it. To repair root, boot the matching installation media and enter its rescue shell without mounting the installed system. This installer rescue environment is separate from systemd's rescue.target.

Rebuild initramfs only when it is relevant

If boot messages point to missing storage drivers or LVM support after a kernel or storage change, regenerate the image for the kernel currently running in rescue mode:

dracut --force /boot/initramfs-$(uname -r).img $(uname -r)
Enter fullscreen mode Exit fullscreen mode

This overwrites that kernel's image, so verify the version first and retain a backup when possible. It does not repair every installed kernel.

A rescue shell has unrestricted root privileges. Use trusted consoles and boot media, and do not treat disabling SELinux or running chmod -R 777 as a repair. Those actions can create a second, security-sensitive problem while hiding the original one.

Getting back out

When repairs are done, simply:

exit
# or, to force a full restart:
reboot
Enter fullscreen mode Exit fullscreen mode

Because the GRUB edit was temporary, the next boot uses your normal kernel parameters automatically. If the system comes up clean, consider making the fix permanent where appropriate (correcting fstab, rebuilding initramfs with dracut, or restoring a config you changed) — and take a snapshot or backup before the next experiment.

Top comments (0)