Ubuntu recovery mode is a reduced boot environment for diagnosing startup, login, package, filesystem, and service problems. On a typical Ubuntu Desktop installation, you enter it through GRUB, choose a recovery entry for a known kernel, and then use the recovery menu or a root shell. It is not a universal repair button: each option changes a specific part of the system, and the safest approach is to identify the symptom before changing anything.
If the screen stops on a `/dev/... clean, files, blocks` line rather than recovery mode itself, my guide to Ubuntu’s “clean, files, blocks” boot message covers that separate symptom and how to diagnose a real hang.
Use recovery mode to gather evidence and make the smallest reversible repair. Choose the correct kernel, inspect before modifying, and never run a filesystem repair against a mounted read-write filesystem.
Before you begin
Recovery mode is most useful when Ubuntu reaches GRUB but normal startup or login fails. It may not help when firmware cannot detect the disk, the machine never reaches GRUB, full-disk encryption cannot be unlocked, or the storage device is physically failing.
Back up important data before any destructive repair. If the system contains irreplaceable files and the disk is making unusual noises, disappearing from firmware, or reporting repeated I/O errors, stop writing to it and prioritize data recovery.
Ubuntu Desktop recovery entries and Ubuntu Core recovery modes are different systems. Desktop installations normally use GRUB recovery entries. Ubuntu Core 20 and later uses a system-mode chooser with run, recover, install, and factory-reset actions; install and factory-reset can erase data.
How to open the GRUB recovery menu
- Restart the computer.
- After the firmware screen, hold Shift on many BIOS systems or press Escape repeatedly on many UEFI systems. Timing varies, and fast boot can make the window brief.
- Select Advanced options for Ubuntu.
- Select a kernel entry ending in (recovery mode). Start with the newest kernel that previously booted successfully. If the newest kernel appears to be the problem, choose an older known-good kernel for comparison.
- Wait for the recovery menu.
If GRUB never appears, check whether the firmware is booting the correct disk and whether fast boot is hiding the menu. Avoid changing bootloader configuration until you have confirmed the actual boot path.
What the recovery-menu options do
The exact menu depends on Ubuntu release and installed packages, but common entries include the following.
resume
Continues the normal boot process. Use it after an inspection or a completed repair. Expected result: Ubuntu continues booting. Verification: confirm whether the original failure returns. Rollback: none; reboot and re-enter recovery mode if necessary.
clean
Attempts to free disk space, usually by removing package-cache material. It is appropriate only when the root filesystem is full and you understand what will be removed. Expected result: additional free space. Verification: check the affected filesystem with `df -h`. Rollback: package caches can generally be downloaded again, but clean is not a substitute for finding what filled the disk.
dpkg
Attempts to repair interrupted or inconsistent package states. Network access may be required for missing packages. Expected result: package configuration completes or reports a specific error. Verification: review the final package-manager output and, after booting, run `sudo dpkg --audit`. Rollback: note any packages changed; use package-manager logs and reinstall a known version if a repair introduces a regression.
fsck
Checks filesystems selected by the recovery workflow. Filesystem repair is safety-critical. Never manually run `fsck` or `e2fsck` against a filesystem mounted read-write. Confirm the correct device with `lsblk -f` and `findmnt` before any manual check. Expected result: either no errors, corrected errors, or an exit status indicating unresolved problems. Verification: record the checker output and reboot if the tool says a reboot is required. Rollback: filesystem repairs are not always reversible, so back up data first when possible.
network
Enables networking so package repair or remote diagnosis may work. Expected result: an interface receives connectivity. Verification: use `ip address` and test DNS separately from basic reachability. Rollback: disable the connection or reboot; do not expose a recovery root shell to an untrusted network.
root
Opens a root shell for targeted diagnosis. The root filesystem may initially be read-only. Keep it read-only while inspecting. Remount it read-write only when a specific repair requires a write:
`mount -o remount,rw /`
Purpose: allow deliberate changes to the root filesystem. Expected result: `/` becomes writable. Verification: run `findmnt -no OPTIONS /` and confirm `rw` appears. Rollback: finish the repair, run `sync`, and reboot; do not leave a damaged system running indefinitely from the recovery shell.
A safe root-shell diagnostic sequence
Start with observations that do not change the system:
- Identify filesystems and mounts with `lsblk -f` and `findmnt`.
- Check free blocks and inodes with `df -h` and `df -i`.
- Review failed services with `systemctl --failed`.
- Review the current boot with `journalctl -b -p warning`.
- Review the previous boot with `journalctl -b -1 -p warning` when logs are available.
- Check recent kernel messages with `journalctl -k -b`.
These commands are diagnostic. Expected result: evidence pointing to a full filesystem, failed unit, package problem, graphics issue, or storage error. Verification: save or photograph the exact error messages. Rollback: none, because the commands are read-only.
Change one variable at a time. After each repair, reboot and test the original symptom before trying another fix. This preserves causal evidence and makes rollback much easier.
When recovery mode is not enough
Use a live Ubuntu USB when the installed system cannot reach GRUB recovery, the root filesystem must be checked while unmounted, the bootloader needs offline repair, or files must be copied before further work. A live environment also lets you inspect SMART data and mount filesystems read-only.
For encrypted systems, make sure you possess the recovery key or passphrase before changing firmware, TPM, or boot settings. Ubuntu Core recovery keys and recovery-mode commands do not apply automatically to ordinary Ubuntu Desktop installations.
Do not use random package purges, boot parameters, `fsck -y`, or factory-reset options as generic fixes. A command that solves one symptom can destroy data or hide the real cause on another machine.
Recovery-mode decision checklist
- GRUB appears and a recovery entry exists: use the recovery menu.
- A recent kernel update caused the failure: test an older known-good kernel first.
- The disk is full: inspect the correct mount with `df -h` and `df -i` before deleting anything.
- Package configuration was interrupted: use the package-repair option and verify the output.
- Filesystem corruption is suspected: check only an unmounted or read-only filesystem, after confirming the correct device.
- The graphical login fails but a shell works: inspect the display manager and journal rather than treating recovery mode as a graphics cure.
- The disk shows I/O errors or disappears: stop repairs and prioritize backup or professional recovery.
Final judgment
Ubuntu recovery mode is valuable because it creates a controlled place to diagnose a broken boot. Its real advantage is not that it performs automatic repairs, but that it lets you separate symptoms, inspect the system, and apply a narrow fix. If the evidence is unclear, preserve the data and move to a live USB rather than guessing.
