$linuxjunkies
>

How to Recover a Forgotten Root Password

Forgot the Linux root password? Boot into single-user mode or use rd.break to reset it safely, with steps for Debian, Fedora/RHEL, and Arch.

IntermediateUbuntuDebianFedoraArch7 min readUpdated June 7, 2026

Before you start

  • ▸Physical or console access to the machine (SSH is not sufficient)
  • ▸LUKS passphrase if the root partition is encrypted
  • ▸Secure Boot disabled in firmware if your distro enforces signed kernels
  • ▸Basic familiarity with the GRUB boot menu and a text editor

Forgetting the root password is not the disaster it sounds like. Linux gives you legitimate, local-only mechanisms to reset it without reinstalling or wiping data. The two dominant approaches are booting into single-user mode (common on Debian-family systems) and using rd.break to interrupt the initramfs early (standard on Fedora/RHEL family). Both require physical or console access to the machine — that access requirement is the security model, so protect your boot loader accordingly.

Before You Start

The steps below require you to edit kernel boot parameters at the GRUB menu. On UEFI systems with Secure Boot enabled, some distributions will refuse to allow arbitrary kernel arguments. Disable Secure Boot in firmware settings first, or use your distro's signed rescue media. Also note: if the disk is encrypted with LUKS, you will need the LUKS passphrase before any of the following will work — the root password reset happens after the volume is unlocked.

Method 1: Single-User Mode (Debian / Ubuntu / Mint)

Debian-family systems boot to a minimal root shell when you pass single or init=/bin/bash as a kernel parameter. The init=/bin/bash approach is more reliable across versions because it bypasses PAM and getty entirely.

Step 1 — Enter the GRUB menu

Reboot the machine. Hold Shift (BIOS/MBR) or tap Esc (UEFI) immediately after the firmware screen to force the GRUB menu to appear. If the timeout is zero, you may need to hold the key from power-on.

Step 2 — Edit the boot entry

Highlight the default boot entry and press e to edit it. Find the line that begins with linux and ends with something like ro quiet splash. Move to the end of that line.

Step 3 — Append the recovery parameter

Delete quiet splash if present, then add:

rw init=/bin/bash

Change ro to rw on the same line so the root filesystem mounts read-write immediately. Press Ctrl+X or F10 to boot.

Step 4 — Reset the password

You will land at a root bash prompt. The filesystem is already mounted read-write. Run:

passwd root

Enter and confirm the new password. Then reboot cleanly:

exec /sbin/init

If exec /sbin/init hangs, a hard reboot is safe here because no writes are in flight after passwd completes.

Method 2: rd.break (Fedora / RHEL / Rocky / AlmaLinux)

Red Hat-family initramfs uses rd.break to drop into a debug shell before handing off to systemd. The root filesystem is mounted read-only under /sysroot, so there are a few extra steps compared to the Debian method.

Step 1 — Enter the GRUB menu

Reboot and press Esc or hold Shift to reach the GRUB menu. On systems where GRUB timeout is hidden, you can also hold any key during POST — the exact key varies by firmware.

Step 2 — Edit the boot entry

Press e on the default entry. Find the line starting with linux. Locate ro and change it to rw. At the end of that line, append:

rd.break enforcing=0

enforcing=0 puts SELinux into permissive mode for this boot, which avoids a context mismatch that would prevent the new password hash from being read. Press Ctrl+X to boot.

Step 3 — Remount and chroot

The initramfs shell shows a switch_root:/# prompt. The real root filesystem is at /sysroot and may still be read-only. Remount it and chroot:

mount -o remount,rw /sysroot
chroot /sysroot

Step 4 — Reset the password

passwd root

After setting the password, tell SELinux to relabel the filesystem on next boot (required even in permissive mode to fix the shadow file context):

touch /.autorelabel

Step 5 — Exit and reboot

exit
exit

The first exit leaves the chroot; the second exits the initramfs shell and continues the normal boot sequence. The autorelabel pass runs and the system reboots a second time automatically — this is expected and takes a couple of minutes.

Method 3: Arch Linux

Arch uses the same GRUB editing workflow, but there is no SELinux concern by default. Append rw init=/bin/bash to the linux line, boot, run passwd, then exec /sbin/init or reboot. Alternatively, boot from the Arch ISO, mount the installed root partition, and use arch-chroot:

mount /dev/sdXn /mnt
arch-chroot /mnt
passwd root

Replace /dev/sdXn with the actual root partition. Use lsblk to identify it.

Verification

After a normal reboot, log in directly as root (at a TTY, not through SSH — root SSH login is typically disabled in sshd_config):

su -
# or at login prompt, username: root

Confirm the account is unlocked and the hash is not prefixed with ! or *:

grep ^root /etc/shadow

A locked account shows root:!$.... A normal account shows root:$y$... or root:$6$... depending on the hash algorithm configured.

Troubleshooting

passwd says "Authentication token manipulation error"

The filesystem is still mounted read-only. Confirm with mount | grep ' / '. If it shows ro, run mount -o remount,rw / and retry.

The GRUB menu never appears

GRUB timeout may be set to 0. If you can boot from a live USB, mount the EFI or boot partition and edit /etc/default/grub — set GRUB_TIMEOUT=5 — then regenerate GRUB config:

# Debian/Ubuntu
update-grub

# Fedora/RHEL
grub2-mkconfig -o /boot/grub2/grub.cfg

SELinux blocks login even after autorelabel

Boot with enforcing=0 again temporarily, then check the context on /etc/shadow:

ls -Z /etc/shadow
restorecon /etc/shadow

Then reboot normally.

System boots to emergency target instead of root shell

If you see systemd messages and an emergency prompt, you are in systemd emergency mode, not the initramfs shell. Type the current root password (or try an empty password) to get a shell, fix the problem, then run systemctl default to try a normal boot.

Hardening Against Unauthorized Password Resets

Because this entire process requires only physical access and no credentials, protect GRUB with a password for any machine that must resist physical tampering. Set a GRUB superuser password in /etc/grub.d/40_custom and regenerate the config. Also consider enabling UEFI Secure Boot and a firmware password. These steps raise the bar significantly but do not replace full-disk encryption for sensitive data at rest.

tested on:Ubuntu 24.04Debian 12Fedora 40Rocky 9

Frequently asked questions

Does this work if the disk is encrypted with LUKS?
You still need the LUKS passphrase to unlock the volume before the root shell appears. Once unlocked, the password reset steps are identical. Without the LUKS passphrase, there is no local recovery path.
Why does RHEL/Fedora require 'touch /.autorelabel' but Debian does not?
Fedora and RHEL ship with SELinux enforcing by default. Changing /etc/shadow while SELinux is in permissive mode can leave the file with a mismatched security context, causing login failures. The autorelabel flag tells SELinux to relabel the entire filesystem on next boot.
Can I do this remotely over SSH?
No. All of these methods require console or physical access to interrupt the boot process. That restriction is intentional — it is the security boundary that makes the mechanism safe to have.
Is it possible to prevent others from using rd.break or init=/bin/bash to compromise my server?
Yes. Set a GRUB bootloader password to restrict editing of boot entries, enable a UEFI firmware password, and use full-disk encryption with LUKS. Together these make unauthorized password resets impractical without the LUKS passphrase.
What if I want to reset a non-root user's password instead?
Follow the same steps to get a root shell, then run 'passwd username' replacing username with the target account. The process is identical; you just specify a different account name.

Related guides