Reset Root Password with a Rescue ISO and chroot

There is a special kind of silence when you type the root password, press Enter and get “Login incorrect” for the third time. Maybe the password lived in a note that no longer exists, maybe a colleague changed it and left the company, maybe the server does not even boot far enough to let you try. The classic trick of editing the GRUB menu and booting with init=/bin/bash is useless when GRUB is password protected or when the system crashes before it reaches a shell. What still works, every single time, is the oldest recovery move in the Linux book: boot the machine from a different operating system, open the installed disk as if it were a USB stick, and step inside it with chroot.

In this guide we do exactly that on a KVM VPS. We boot a rescue ISO from the control panel, find the system disk, activate LVM (and unlock LUKS if the disk is encrypted), mount everything, chroot in and set a new password. It takes about 15 minutes, it does not touch your data, and once you have done it once, a forgotten password stops being an emergency and becomes a routine chore.

Why the rescue ISO method works when everything else fails

To understand why this method is so reliable, it helps to look at how a server boots. When the VPS starts, the virtual firmware (BIOS or UEFI) looks for something bootable, in the order you configured. Normally that is the system disk, where GRUB (the bootloader) loads the Linux kernel, which then starts the rest of your system. The root password is not stored “in” any of these programs. It lives as a hash (a one way scrambled version of the password) in a plain text file on the disk: /etc/shadow.

That gives us a simple observation: anyone who can boot the machine from another operating system can read and modify that file. A GRUB password only protects the GRUB menu. If the firmware boots a CD image before it ever reaches GRUB, the GRUB password is never asked for. That is why the rescue ISO is the universal fallback: it does not care whether GRUB is locked, misconfigured, or whether the kernel on disk panics at boot.

Key concepts in plain words

Before we start typing, let’s define the handful of terms that show up in every step:

• Rescue or live ISO: an image of a complete Linux system that runs entirely from the virtual CD and RAM, without installing anything. Your real disk stays untouched until you decide to mount it.
• Partition and filesystem: a disk is split into partitions (slices), and each partition usually holds a filesystem such as ext4 or vfat, which is the structure that organizes files and folders.
• Mounting: attaching a filesystem to a folder so you can browse it. If we mount your system partition on /mnt, then your server’s /etc/shadow becomes visible as /mnt/etc/shadow.
• LVM (Logical Volume Manager): a layer between partitions and filesystems that lets you resize and combine storage. A partition becomes a “physical volume” (PV), PVs form a “volume group” (VG), and the VG is carved into “logical volumes” (LVs) that hold the actual filesystems. Debian and Ubuntu both offer LVM in the installer, and many people choose it.
• LUKS: Linux disk encryption. If your disk is encrypted, you must unlock it with the passphrase before anything else is readable.
• chroot: short for “change root”. It starts a program with a different folder treated as /. After chroot /mnt, programs see your installed system as the whole world: they read its /etc/passwd, its PAM configuration, its password hashing settings.

Why not just run passwd in the live system?

Because it would change the password of the live system’s user, which disappears at the next reboot. The live system has its own /etc/shadow in RAM. We need the passwd command to operate on your server’s files, with your server’s rules (Debian 13 and Ubuntu 24.04 both hash passwords with yescrypt by default). chroot gives us exactly that, without editing hashes by hand.

What you need

• A KVM VPS. This method needs a virtual machine with its own bootloader and disk. On an LXC container (privileged or unprivileged) there is no bootloader and no ISO boot, because containers share the host’s kernel. If you lose root access to an LXC VPS, contact support or use the password reset or reinstall options in the panel.
• Access to the client panel with the option to attach an ISO, change the boot order and open the VNC or noVNC console in the browser.
• A rescue ISO for amd64. Any of these works: Debian live (the “standard” image is small and has no desktop), Ubuntu Desktop using the “Try Ubuntu” mode, or SystemRescue , which ships with LVM and LUKS tools preinstalled. Many panels already offer some of these in an ISO library.
• Your LUKS passphrase, if the disk is encrypted. Without it, nobody can read the data, and that is the whole point of encryption.
• About 15 to 30 minutes and acceptance of downtime: the VPS runs the rescue system instead of your services during the procedure.

Reset root password with chroot: the 7 steps

Here is the whole procedure at a glance. Each box below matches one numbered step in the rest of the article, so you can always find where you are.

Step 1: Boot the VPS from the rescue ISO

Log in to the DreamServer client panel, open your VPS and find the ISO or rescue section. Attach the ISO (from the library or by URL, depending on what the panel offers), set the boot order so that the CD-ROM comes before the disk, and restart the VPS. Then open the VNC or noVNC console in the browser. This is a virtual screen and keyboard connected directly to the VM, so it works even when networking inside the server is broken.

What you see next depends on the ISO:

• Debian live: pick “Live system (amd64)” in the boot menu. You are logged in automatically as the user user (the password is live if anything ever asks).
• Ubuntu Desktop: choose “Try or Install Ubuntu”, then “Try Ubuntu” in the installer window, and open a Terminal. The live user is ubuntu, without a password.
• SystemRescue: the default menu entry drops you straight into a root shell.

On Debian or Ubuntu live, become root so you don’t have to prefix every command with sudo:

sudo -i

The prompt now ends in #, which means you are root in the live system. Every command from here on assumes this.

Optional but very handy: SSH into the live system. Typing long commands through a VNC console is slow, and copy and paste often does not work. If you want to paste commands from this article, give the live system network access and an SSH server. First check whether the interface already got an address via DHCP:

ip -br addr

If your public IP is not listed, configure it by hand, using the IP, prefix and gateway shown in your panel (the values below are examples, and ens18 must be replaced with the interface name from the previous output):

ip link set ens18 up
ip addr add 203.0.113.10/24 dev ens18
ip route add default via 203.0.113.1
echo "nameserver 1.1.1.1" > /etc/resolv.conf

Then install and start the SSH server, and set a temporary password for the live user (user on Debian live, ubuntu on Ubuntu live):

apt update && apt install -y openssh-server
passwd user
systemctl start ssh

From your own computer, connect while telling SSH not to save the live system’s host key:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@203.0.113.10

Why those options? The live system has different host keys than your server. Without them, SSH would either refuse to connect (because the key for that IP changed) or save the live system’s key in your known_hosts, and you would get a scary warning later when you connect to the real server again. Run sudo -i after logging in.

Step 2: Find the system disk

Now we look at which disks and partitions exist. The -i flag makes lsblk draw the tree with plain ASCII characters, which is easier to read in a console:

lsblk -i -o NAME,SIZE,FSTYPE,MOUNTPOINTS

On a VPS installed with Ubuntu 24.04 and LVM, the output looks roughly like this:

NAME    SIZE FSTYPE      MOUNTPOINTS
loop0   1.2G squashfs    /run/live/rootfs/filesystem.squashfs
sr0     1.4G iso9660     /run/live/medium
vda      50G
|-vda1    1G vfat
|-vda2    2G ext4
`-vda3   47G LVM2_member

How to read it: sr0 is the virtual CD with the ISO, loop0 is the live system’s compressed filesystem, and vda is your real disk. On KVM with virtio the disk is usually vda; with emulated SCSI it is sda, and with NVMe it is nvme0n1 (partitions then look like nvme0n1p1). Adjust every command below to your names.

The FSTYPE column tells you what each partition is:

• vfat, around 1 GB or smaller: the EFI system partition. Not what we want.
• small ext4, 1 to 2 GB: very likely /boot. Not what we want either.
• LVM2_member: an LVM physical volume. Your root filesystem is inside, go to step 3.
• crypto_LUKS: an encrypted partition. Unlock it in step 3, then activate LVM inside it.
• one large ext4 partition and nothing else: typical for VPS templates and cloud images. That is your root filesystem, skip step 3. (Ubuntu 24.04 cloud images, for example, have root on vda1 and a separate /boot on vda16.)

If some LVM volumes already appear under vda3, the live system activated them automatically. That is fine, step 3 will simply confirm it. For more detail, including UUIDs and labels, blkid prints everything it can identify.

Step 3: Activate LVM (and unlock LUKS if needed)

Skip this step if step 2 showed a plain ext4 root partition.

If the partition is crypto_LUKS, unlock it first. cryptroot is just a name we choose for the unlocked device:

cryptsetup open /dev/vda3 cryptroot

Type the passphrase when asked. Nothing is echoed while you type. On success there is no message, and a new device /dev/mapper/cryptroot exists. Running lsblk again should show it under vda3 with the type LVM2_member, because the Debian and Ubuntu installers put LVM inside LUKS.

A small detail: your installed system uses its own name for this device, written in /etc/crypttab (Debian typically uses something like vda3_crypt, Ubuntu 24.04 something like dm_crypt-0). For a password reset the name does not matter. It only matters if you later rebuild the initramfs from inside the chroot; in that case open the device with the same name as in crypttab.

Now activate LVM:

vgscan
vgchange -ay
lvs

vgscan searches all disks for volume groups, vgchange -ay activates every logical volume it finds, and lvs lists them. Expected output on Ubuntu (the lvs columns are trimmed here):

  Found volume group "ubuntu-vg" using metadata type lvm2
  1 logical volume(s) in volume group "ubuntu-vg" now active
  LV        VG        Attr       LSize
  ubuntu-lv ubuntu-vg -wi-a----- <47.00g

Names differ between distributions. Ubuntu uses the volume group ubuntu-vg with a single LV ubuntu-lv. Debian names the group after the hostname, for example myhost-vg, with LVs called root and swap_1 (sometimes also home, var or tmp if you chose separate partitions). The root LV is reachable as /dev/VG/LV, for example /dev/ubuntu-vg/ubuntu-lv, or through the equivalent /dev/mapper/ubuntu--vg-ubuntu--lv (device mapper doubles the dashes inside names, which is normal).

If you get “command not found” for vgchange or cryptsetup, the live image lacks the tools. Install them with apt install -y lvm2 cryptsetup (needs the network setup from step 1), or use SystemRescue, which includes both.

Step 4: Mount the root filesystem

If the server stopped booting because of filesystem errors, now is the moment to check the filesystem, before mounting it (fsck must never run on a mounted filesystem):

fsck -f /dev/ubuntu-vg/ubuntu-lv

Then mount the root filesystem on /mnt. Pick the line that matches your layout:

# Ubuntu with LVM
mount /dev/ubuntu-vg/ubuntu-lv /mnt

# Debian with LVM (replace myhost with your volume group name)
mount /dev/myhost-vg/root /mnt

# plain partition without LVM
mount /dev/vda1 /mnt

Lines starting with # are comments, run only the mount line you need. Then check that you mounted the right thing:

ls /mnt
cat /mnt/etc/os-release

You should see the familiar top level folders (bin, boot, etc, home, usr, var and so on), and os-release should name your distribution. If instead you see grub, lost+found and files like vmlinuz-..., you mounted /boot by mistake: run umount /mnt and try the other partition.

For a password reset, the root filesystem is enough. If you also want to repair the boot process from inside the chroot (reinstall GRUB, rebuild the initramfs), look at /mnt/etc/fstab and mount the separate /boot and EFI partitions as well:

mount /dev/vda2 /mnt/boot
mount /dev/vda1 /mnt/boot/efi

Step 5: Bind-mount /dev, /proc and /sys, then chroot

Programs running inside the chroot still need the kernel’s virtual filesystems: /dev (devices, including the terminal you type in), /proc (processes) and /sys (hardware and kernel information). Your disk only contains empty folders for these. We fill them by “bind mounting”, which makes the live system’s folders appear in a second place:

mount --rbind /dev /mnt/dev
mount --make-rslave /mnt/dev
mount -t proc proc /mnt/proc
mount --rbind /sys /mnt/sys
mount --make-rslave /mnt/sys
chroot /mnt /bin/bash

--rbind also brings along anything mounted underneath (such as /dev/pts, which terminals need). --make-rslave makes sure that unmounting things later does not propagate back and break the live system. The last line starts a bash shell with /mnt as its root.

The prompt may still show the live system’s hostname, because the hostname belongs to the running kernel, not to the disk. To confirm you are inside your server, check the files:

cat /etc/hostname
ls /home

You should see your server’s name and your users’ home folders. From now on, every command acts on your installed system.

Step 6: Set the new password

This is the moment you have been working towards:

passwd root

Expected output:

New password:
Retype new password:
passwd: password updated successfully

Nothing is shown while you type, that is normal. You can confirm the state of the account with passwd -S root: the second field should be P (usable password). L means locked and NP means no password.

A Debian and Ubuntu difference matters here. On Ubuntu, the root account is locked by default and you are expected to use your sudo user. On Debian it depends on the installer: if you set a root password, root is active and your regular user may not even be in the sudo group; if you left it empty, root is locked and the first user got sudo rights. Often the better fix is to reset your own user rather than enabling root:

getent group sudo
passwd alex

The first command lists members of the sudo group (for example sudo:x:27:alex). Replace alex with your username. If your user is missing from the group, add it with usermod -aG sudo alex. If chage -l alex shows an expired account, clear the expiry with chage -E -1 alex, and if passwd -S alex shows L, unlock it with passwd -u alex.

While you are here, you can also restore SSH key access, which is the better long term solution anyway:

mkdir -p /home/alex/.ssh
echo "ssh-ed25519 AAAA...your-public-key... you@laptop" >> /home/alex/.ssh/authorized_keys
chown -R alex:alex /home/alex/.ssh
chmod 700 /home/alex/.ssh
chmod 600 /home/alex/.ssh/authorized_keys

Doing the chown inside the chroot is important: user names are resolved from your server’s /etc/passwd. Outside the chroot, alex would be looked up in the live system and might map to the wrong numeric ID or not exist at all.

A note for people who also manage RHEL family systems: there, with SELinux enforcing, you must run touch /.autorelabel after changing files from a chroot. Debian and Ubuntu use AppArmor, which needs nothing here.

Step 7: Clean up, detach the ISO and reboot

Leave the chroot, unmount everything cleanly and close LVM and LUKS. Skip the vgchange line if you did not use LVM and the cryptsetup line if you did not use LUKS:

exit
cd /
umount -R /mnt
vgchange -an ubuntu-vg
cryptsetup close cryptroot
sync
poweroff

exit returns you to the live system shell. cd / makes sure your shell is not sitting inside /mnt, which would block the unmount. umount -R unmounts /mnt and everything below it in the correct order. vgchange -an deactivates the volume group (use your VG name on Debian), cryptsetup close locks the encrypted device again, and sync flushes any pending writes to disk.

Now go back to the panel: detach the ISO, set the boot order back to the disk and start the VPS. Some panels only apply boot order changes after a full power cycle, which is why we used poweroff instead of reboot. Log in through the VNC console first with the new password, and only then try SSH, so you know immediately whether a problem is the password or the SSH configuration.

Troubleshooting and common mistakes

• “mount: unknown filesystem type ‘LVM2_member’” or “‘crypto_LUKS’”: you tried to mount the container partition itself. Unlock and activate it in step 3, then mount the logical volume, not vda3.
• “Volume group not found” or no LVs listed: run pvs to see whether the PV is detected at all. If the disk is encrypted, you must open LUKS first. In the rare case where the live system has its own VG with the same name, rename yours temporarily by UUID with vgrename, then rename it back before rebooting.
• “chroot: failed to run command ‘/bin/bash’: No such file or directory”: you mounted the wrong partition (often /boot), or you booted an ISO for a different CPU architecture. Use an amd64 ISO for a standard VPS.
• “passwd: Authentication token manipulation error”: the filesystem is read-only, full, or /etc/shadow is immutable. Exit the chroot and run mount -o remount,rw /mnt; check free space with df -h /mnt; check attributes with lsattr /mnt/etc/shadow and remove an i flag with chattr -i /mnt/etc/shadow.
• The password works in the console but not over SSH: SSH has its own rules. On both Debian and Ubuntu, PermitRootLogin defaults to prohibit-password, so root can only log in with a key. Also check PasswordAuthentication in /etc/ssh/sshd_config and in the files under /etc/ssh/sshd_config.d/ (Ubuntu cloud images often have a 50-cloud-init.conf there that changes it).
• The password is “wrong” right after setting it: the VNC console may use a different keyboard layout than you think, so symbols like @, #, y and z get typed as something else. Set a temporary password made only of lowercase letters and digits, log in, then change it with passwd over SSH, where your own keyboard is used.
• “umount: /mnt: target is busy”: a shell or program is still inside /mnt. Run cd /, close extra SSH sessions into the live system, and try again.
• The VPS boots back into the rescue system: the ISO is still attached or the boot order still prefers the CD-ROM. Fix it in the panel and power cycle.

Security notes

This procedure is a good reminder of an uncomfortable truth: whoever controls the console and the boot process controls the server. No password, GRUB lock or sudo rule stops someone who can boot their own operating system on your VM. A few practical consequences:

• Protect the client panel like you protect root. Use a long unique password and two factor authentication on your DreamServer account. Panel access is effectively root access, because it gives console and ISO boot.
• A GRUB password is not a security boundary against ISO boot. It stops casual edits of kernel parameters on the console, nothing more. If you need data to stay private even from someone with console access, the answer is full disk encryption with LUKS. The trade off: you must type the passphrase at every boot (through the VNC console), and if you lose it, the data is gone for good.
• Prefer SSH keys over passwords. After you regain access, keep PasswordAuthentication no and PermitRootLogin prohibit-password (or no) in the SSH configuration, and use a password manager for the account password you just set, so this does not happen again.
• Find out why you were locked out. If you are sure nobody on your team changed the password, treat it as a possible compromise rather than a memory lapse. Look at the login history before you bring services back up. On Ubuntu 24.04 there is a classic /var/log/auth.log. Debian 13 does not install rsyslog by default, so logs live only in the systemd journal; from the live system you can read it with journalctl -D /mnt/var/log/journal. If something looks wrong, rotate every secret on the server (passwords, API keys, SSH keys), not just the root password.
• Don’t leave the ISO attached. Besides the boot loop, an attached ISO is one more way into the machine if someone gets panel access.

So, keep this one in your back pocket

The rescue ISO and chroot technique is the method that works when every other recovery trick fails: locked GRUB, broken boot, encrypted disk with LVM, all of it. Boot the ISO, find the disk, activate LVM, mount, chroot, passwd, clean up. Seven steps, roughly a quarter of an hour, and your data never moves. It is also worth practicing once on a test machine, because the same chroot is how you fix a broken GRUB or a failed kernel update.

If you want a server where all of this is at your fingertips, a KVM VPS from DreamServer comes with console access and ISO boot from the panel. And if you would rather never face a locked server at 2 AM yourself, our server administration team can handle access recovery, SSH hardening and backups for you.

FAQ

Can I just edit /etc/shadow by hand instead of using chroot?

You can, but it is error prone: you would have to generate a correct yescrypt hash yourself and paste it into the right field without breaking the file. A cleaner alternative to a full chroot is passwd --root /mnt root (or chpasswd -R /mnt), which tells the tool to work on the mounted system. The full chroot is still useful because you can also fix sudo groups, SSH keys and boot problems in the same session.

Will this delete or change any of my data?

No. The only file that changes is /etc/shadow (plus any other file you deliberately edit). Mounting and reading a filesystem does not modify your data. The one risky action would be running fsck on a mounted filesystem, which is why we run it before mounting.

Does it work if my disk is encrypted with LUKS?

Yes, as long as you know the LUKS passphrase. You unlock the partition with cryptsetup open in step 3 and continue normally. Without the passphrase there is no way in, which is exactly what encryption promises.

Why does the new root password not work over SSH?

Because Debian and Ubuntu default to PermitRootLogin prohibit-password, which allows root over SSH only with a key. Log in as your sudo user over SSH, or use the VNC console for root. Changing that setting to allow root passwords is not recommended.

Can I use this method on an LXC VPS?

No. LXC containers, privileged or unprivileged, share the host’s kernel and have no bootloader of their own, so there is nothing to boot an ISO into. For LXC, use the password reset or reinstall functions in the panel, or contact support.