GRUB Recovery: Step-by-Step Guide for Ubuntu and CentOS

Introduction / Why This Is Needed

GRUB (Grand Unified Bootloader) is a critical component that loads the operating system. If its configuration is corrupted (for example, after a failed update, disk failure, or Windows reinstallation), the computer may display errors like grub rescue>, no such partition, or simply hang on a black screen. This guide will help you restore the bootloader without reinstalling the system and without data loss. We will cover both classic BIOS/Legacy and modern UEFI.

Requirements / Preparation

Before you begin, make sure you have:

Another computer or a live USB drive (flash drive) with any Linux system (Ubuntu/Debian or their live images are recommended).
Basic terminal skills and an understanding of how mounts work in Linux.
Knowledge of which partition your main system is on (if you don't remember, we will determine it in the first step).
Access to BIOS/UEFI to configure booting from the USB drive (usually the F2, F12, Del keys during startup).

⚠️ Important: If you have an encrypted system (LUKS), the GRUB recovery process will be more complex and will require additional steps to open the container. This guide assumes standard (unencrypted) partitions.

Step 1: Booting from Live-USB and Identifying Partitions

Insert the live USB and boot from it, selecting the "Try Ubuntu" (or similar) option.
After booting, open the terminal (Ctrl+Alt+T).
Run the command to see all disks and partitions:
```
sudo fdisk -l
```
Or:
```
lsblk -f
```
Find your main disk (usually /dev/sda, /dev/nvme0n1, or /dev/vda). The output list will look something like this:
```
NAME   FSTYPE  LABEL  UUID                                 MOUNTPOINT
sda
├─sda1 vfat    ESP    ABCD-1234                            # ESP partition (UEFI)
├─sda2 ext4    root   1234abcd-5678-ef90-1234-567890abcdef  # Your root partition (/)
└─sda3 swap          swap-uuid-1234
```
- For UEFI, you will need two partitions: the root (ext4, xfs) and the ESP (FAT32, usually the first, ~100-500 MB, may be labeled boot or ESP).
- For BIOS/Legacy, only the root partition (ext4, xfs) is needed.

Note your partition names (e.g., /dev/sda2 for root, /dev/sda1 for ESP).

Step 2: Mounting Partitions and Entering chroot

Now we will mount your system to the /mnt directory to work with it as the root.

Mount the root partition (replace /dev/sda2 with yours):
```
sudo mount /dev/sda2 /mnt
```
If you have UEFI, mount the ESP partition to /mnt/boot/efi:
```
sudo mount /dev/sda1 /mnt/boot/efi
```
💡 Tip: If you have multiple disks, ensure you mount partitions from the same system you are trying to recover.

Mount the virtual filesystems required for grub-install and update-grub to work:

for fs in dev proc sys run; do sudo mount --bind /$fs /mnt/$fs; done

Enter the chroot environment of your system:
```
sudo chroot /mnt
```
The command prompt will change, for example, to root@ubuntu:/#. Now all commands will execute inside your damaged system.

Step 3: Reinstalling and Updating GRUB

Inside chroot, run the following commands.

Reinstall GRUB to the disk (not to the partition!). Replace /dev/sda with your disk (e.g., /dev/nvme0n1), not a partition (/dev/nvme0n1p1).
- For BIOS/Legacy:
```
grub-install /dev/sda
```
- For UEFI, the command is the same, but GRUB will automatically find and use the mounted ESP:
```
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB
```
  ⚠️ If grub-install in UEFI gives an error, check that the ESP partition is mounted exactly at /boot/efi and is of type vfat.
Update the GRUB configuration (scans for kernels and generates the menu):
```
update-grub
```
You should see lines Found linux image... and Found initrd image... for your kernel.
(Optional) Check the configuration:
```
cat /boot/grub/grub.cfg | head -20
```
Ensure the file is not empty.

Step 4: Exit and Reboot

Exit chroot:
```
exit
```

Unmount all partitions in the correct order:

for fs in run sys proc dev; do sudo umount /mnt/$fs; done
sudo umount /mnt/boot/efi  # Only for UEFI
sudo umount /mnt

Remove the live USB and reboot the computer:
```
sudo reboot
```

Verifying the Result

After rebooting, you should see:

The GRUB menu with kernel selection (if it was there before).
Automatic boot of your main system without errors (grub rescue>, error: no such partition).
If the system boots but the menu doesn't appear, that's normal if the GRUB configuration has a timeout of 0. Check that the system is functional.

💡 Tip: If after recovery the system still doesn't boot, check BIOS/UEFI settings (boot mode: UEFI/Legacy, boot device priority) and bootloader entry order (e.g., efibootmgr in UEFI).

::in-article-ad

Possible Issues

Error: "grub-install: error: failed to get canonical path of `overlay'"

Cause: Missing mounted virtual filesystems (/dev, /proc, /sys). Solution: Ensure you executed the mount command from Step 2 before chroot.

Error: "error: couldn't translate filesystem offset" or "file not found"

Cause: Incorrect ESP partition specified (UEFI) or it is not formatted as FAT32. Solution: Recheck lsblk -f. The ESP partition must be of type vfat. If it doesn't exist, your disk might use pure BIOS booting, or the ESP is on another disk.

Error: "grub-install: error: will not proceed with blocklists"

Cause: GRUB cannot write the boot sector due to non-standard partition layout (often on RAID or LVM). Solution: Try adding the --force flag to the grub-install command, but only if you are sure about disk integrity. In complex cases (RAID, LVM), deeper recovery via grub-probe and manual root specification may be needed.

Cause: GRUB_TIMEOUT=0 is set in /etc/default/grub. Solution: Boot into the system, edit the file:

sudo nano /etc/default/grub

Change the line to GRUB_TIMEOUT=5, then run sudo update-grub.

System doesn't boot, drops back to `grub rescue>` again

Cause: You specified the wrong disk in grub-install (e.g., /dev/sda1 instead of /dev/sda) or restored GRUB to a different disk. Solution: Reboot with the live USB and recheck which disk (/dev/sdX) the bootloader is installed on (use sudo fdisk -l to see the partition with * in the Boot column). Install GRUB to that exact disk.

In UEFI, after recovery the message "no bootable device" appears

Cause: The GRUB entry was not added to the UEFI Boot Order. Solution: In chroot or in the live environment (with ESP mounted), run:

efibootmgr -c -d /dev/sda -p 1 -L "GRUB" -l '\EFI\ubuntu\grubx64.efi'

(Replace /dev/sda, 1, and the path \EFI\ubuntu\... with yours). Then check efibootmgr -v and set the priority via BIOS/UEFI.

F.A.Q.

What's the difference between GRUB recovery in UEFI and BIOS?

Can GRUB be recovered without a live USB?

Will my data be lost during GRUB recovery?

What to do if the `grub-install` command gives a 'file not found' error?

Hints

Booting from Live USB and identifying partitions

Mounting partitions in chroot

Reinstalling and updating GRUB

Exit and reboot