Reset a forgotten root password (GRUB, rescue mode, cloud)

Updated November 2026

If another account has sudo rights, just run sudo passwd root. If not, you need console access. Interrupt the boot in GRUB (rd.break on RHEL, init=/bin/bash or recovery mode on Debian/Ubuntu), or boot a rescue system, then run passwd. The steps below take about 10 minutes, plus an SELinux relabel on RHEL.

Do this first.

  1. Try every admin account. If one has sudo rights, sudo passwd root fixes this without a reboot.
  2. Open the console (KVM, IPMI, or your provider's web or serial console). Every method below reboots the server.
  3. If you didn't lose the password but it stopped working, someone may have changed it. Treat that as a break-in, see Leaked credentials.

Symptoms

Note: a freshly installed system may simply have root login disabled. In that case an admin user can enable it with sudo passwd root.

Reach the GRUB menu

Reboot from the console. On Ubuntu the menu is often hidden: hold Shift while booting (BIOS), or press Esc, possibly several times (UEFI). Select the entry you normally boot and press e to edit it. Find the line that starts with linux. If GRUB asks for a username and password, the boot menu is locked, and you need a rescue system instead (see below).

RHEL 9 and 10, AlmaLinux, Rocky: rd.break

Red Hat documents this procedure for RHEL 9. RHEL 10 uses the same dracut initramfs, and the same steps generally apply. Check Red Hat's documentation for your exact release.

  1. At the end of the linux line, add rd.break. Press Ctrl+x to boot.
  2. At the switch_root:/# prompt, run the following (the real root file system is mounted read-only at /sysroot):
mount -o remount,rw /sysroot
chroot /sysroot
passwd
touch /.autorelabel
exit
exit

The first exit leaves the chroot. The second one continues the boot. The /.autorelabel file is important. passwd writes a new /etc/shadow while SELinux policy isn't loaded, so the file gets the wrong label. Without a relabel, logins can fail even with the correct new password. The relabel runs on the next boot, can take a long time on large disks, and reboots the machine on its own when it finishes. Don't interrupt it.

If the root disk is encrypted with LUKS, you will be asked for the passphrase before the switch_root prompt appears.

Debian and Ubuntu: init=/bin/bash

This works on both distributions, even when the root account has no password at all:

  1. At the end of the linux line, add init=/bin/bash. Press Ctrl+x or F10.
  2. You get a root shell with no login. Systemd is not running and the root file system is read-only.
mount -o remount,rw /
passwd root        # or: passwd alice
sync
reboot -f

reboot -f is needed because there is no init system to ask for a normal reboot. Run sync first so that the new password reaches the disk.

Ubuntu recovery mode

From the GRUB menu, choose Advanced options, then the entry ending in (recovery mode), then root: Drop to root shell prompt. Then run:

mount -o remount,rw /
passwd alice
sync
reboot

On Debian, recovery mode normally asks for the root password before it gives you a shell, so it doesn't help when that password is the problem. Use init=/bin/bash instead. If the screen stays blank after you boot with init=/bin/bash, edit the entry again and also remove quiet and splash from the linux line.

Cloud servers and rescue systems

When you can't edit GRUB, boot a separate rescue system, mount the server's disk and change the password in a chroot.

Hetzner dedicated servers (rescue system)

In Robot, activate the rescue system under Servers, Rescue, then reboot or reset the server within 60 minutes. Log in as root with the password shown at activation. Then:

lsblk                    # find the root partition (software RAID: cat /proc/mdstat)
mount /dev/md2 /mnt      # example; LVM: mount /dev/mapper/vg0-root /mnt
chroot-prepare /mnt
chroot /mnt
passwd
exit

If the installed system uses SELinux (the RHEL family), run touch /mnt/.autorelabel before you reboot. The rescue system can't set SELinux labels.

AWS, Google Cloud and Azure

On cloud VMs, root SSH logins are usually meant to stay disabled. Set a password so that you can log in at the console, and keep using a normal user with sudo for SSH.

Confirm it is fixed

Prevent it next time

When to call your host or a professional

Ask your provider if the server has no console you can reach, if it doesn't boot after these steps (Kernel boot failure may help), or if the disk is encrypted and the passphrase is also lost. In that last case, the data can't be recovered without the passphrase. If you suspect someone else changed the password, change every credential as described in Leaked credentials, and follow Incident response.

Sources