Retrieve a lost Ubuntu password through GRUB recovery mode or a LiveCD chroot. The right way is recovery mode for most cases, LiveCD for encrypted disks or when GRUB is broken. The right commands are passwd username in either case. The team that has the right path has the password back in under 15 minutes.
Table of contents
- The right path for most cases
- The right path for encrypted disks or broken GRUB
- The /etc/shadow gotcha
- LUKS encryption
- FAQ
The right path for most cases
The right way to reset a lost Ubuntu password is GRUB recovery mode. The right procedure:
- Reboot the machine.
- Hold
Shift(or pressEscapeon some hardware) during boot to bring up GRUB. - Select
Advanced options for Ubuntu. - Select the recovery mode entry.
- Select
root - Drop to root shell prompt. - Run
mount -o remount,rw /. - Run
passwd username. - Run
reboot.
The right verification is to log in with the new password after the reboot.
The right path for encrypted disks or broken GRUB
If recovery mode is unavailable (encrypted disk, broken GRUB), the right answer is a LiveCD. Boot from an Ubuntu install USB, choose Try Ubuntu, then:
sudo mount /dev/sda2 /mnt
sudo mount /dev/sda1 /mnt/boot # if separate
sudo chroot /mnt
passwd username
exit
sudo reboot
The chroot makes the live environment treat your installed system as its root. From the chroot, passwd writes to the right /etc/shadow.
The /etc/shadow gotcha
The wrong answer is to edit /etc/shadow directly with vi. The right answer is to use passwd, which handles the salt, hashing algorithm, and lock flag correctly. The right answer if you have to script the change is chpasswd with a here-doc.
LUKS encryption
If the disk is encrypted with LUKS, you need the LUKS passphrase to unlock the disk at boot. The right answer for a forgotten LUKS passphrase is that the data is unrecoverable — LUKS is designed so that forgetting the passphrase is permanent. The only remediation is to wipe the disk and restore from backup.
FAQ
Will I lose my data?
No. Resetting the password only rewrites the hash in /etc/shadow. Files on disk are untouched.
My GRUB menu is hidden. What do I do?
The right answer is to set GRUB_TIMEOUT=10 in /etc/default/grub from a LiveCD, then sudo update-grub.
Can I do this remotely?
Only if the hosting provider gives you console access (IPMI, KVM, or a cloud provider’s serial console). AWS gives you this through EC2 Serial Console. Hetzner and OVH do not.
Does this work on a Raspberry Pi?
Yes, the same procedure applies. The right answer is to attach a keyboard and monitor to the Pi, or to use the Pi’s serial console for headless access.
What if the user account is locked or deleted?
The right answer is to use usermod -p to set the password, or useradd -m -G sudo newuser to create a new account. The wrong answer is to try to recover the old account.
How do I prevent this from happening again?
The right answer is to keep a working LiveCD on a USB stick, enable the GRUB menu timeout, and store the user password in a password manager.
If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.
Useful related references: