Fix GRUB: A Practical Guide to Restoring Linux Systems via Live USB

Table of Contents

When the Bootloader Breaks: Understanding the Grub Rescue Prompt

Few things are as frustrating as hitting the power button and seeing grub rescue> instead of your login screen. This error usually means the bootloader can’t find its configuration files or the kernel. I’ve seen this happen most often after a major kernel update, a Windows update overwriting the boot sector, or when a user resizes partitions using GParted and shifts the starting sectors of the OS.

The good news? Your data is almost certainly safe. The system just lost its map. To fix this, you’ll need a Live USB of a major distribution like Ubuntu 22.04 or Fedora 39. We will use a technique called chroot to “step inside” your broken installation and repair it from the inside out.

Core Concepts: Legacy BIOS vs. UEFI

Before typing commands, you must identify your firmware type. Modern hardware handles booting differently than older machines.

Legacy BIOS (MBR): GRUB sits in the first 512 bytes of the hard drive.
UEFI (GPT): GRUB exists as an .efi file within a dedicated EFI System Partition (ESP), typically a 100MB to 500MB partition formatted as FAT32.

To check your mode in a Live environment, run ls /sys/firmware/efi. If the directory exists, you are in UEFI mode. If it’s missing, you’re likely using Legacy BIOS.

Why We Use Chroot

The chroot (change root) command is a lifesaver. It lets you treat a directory on your Live USB as the actual root (/) of your installed system. This allows you to run commands like grub-install as if you had successfully booted into your drive, bypassing the broken bootloader entirely.

Step-by-Step Recovery Process

Boot from your Live USB and open the terminal. We’ll assume you’re working with a standard NVMe or SATA drive.

1. Identify Your Partitions

Use lsblk to map out your drive. You need to find your root partition and your EFI partition.

lsblk -f

Look for a large ext4 partition (your system) and a small vfat or fat32 partition (the EFI bootloader). On many modern laptops, these will be /dev/nvme0n1p2 (root) and /dev/nvme0n1p1 (EFI).

2. Mount the File Systems

We need to build a path for the chroot environment. In this example, we’ll use /dev/sda2 as root and /dev/sda1 as EFI. Adjust these names to match your lsblk output.

# Mount your main system
sudo mount /dev/sda2 /mnt

# Mount the EFI partition (UEFI systems only)
sudo mount /dev/sda1 /mnt/boot/efi

If you have a separate /boot partition, mount it to /mnt/boot before moving forward. Failing to mount a separate boot partition is the most common reason the repair fails.

3. Bind System Directories

The repair tools need access to your hardware and process information. We “bind” these virtual file systems from the Live USB to our mounted system.

for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done

This single line ensures that /run is available. Modern GRUB versions require /run to detect the UUIDs of your disks correctly.

4. Enter the Environment

Now, switch your context into the installed system:

sudo chroot /mnt

Your terminal prompt will change. You are now effectively running as root on your broken installation.

5. Reinstall and Update GRUB

For UEFI systems, reinstall the bootloader files and refresh the configuration. Note that we target the disk (e.g., /dev/sda), not the partition.

grub-install /dev/sda
update-grub

On Arch or Fedora, the update command is grub-mkconfig -o /boot/grub/grub.cfg. This command scans your drives for kernels and operating systems. It then builds the menu you see at startup.

6. Cleanup and Reboot

Exit the environment and unmount everything cleanly. This prevents filesystem corruption.

exit
sudo umount -R /mnt
sudo reboot

Restoring Missing Windows Entries

Did Windows disappear from your boot menu? Since GRUB version 2.06, the os-prober tool is often disabled by default for security. To bring it back, edit your config while inside the chroot:

sudo nano /etc/default/grub

Add GRUB_DISABLE_OS_PROBER=false to the bottom of the file. Save (Ctrl+O) and exit (Ctrl+X). Run update-grub again, and your dual-boot menu should return.

Hard-Won Tips for Boot Stability

I’ve repaired hundreds of these systems, and these three habits prevent most future headaches:

Label your disks: Use e2label to name your partitions. It’s much easier to find “Linux_Root” than /dev/nvme0n1p3 when you’re in a recovery shell.
Keep your Live USB: Don’t format that USB drive after the fix. Keep it on your keychain. You’ll eventually need it for a filesystem check (fsck) or another boot failure.
Monitor SSD Health: If GRUB keeps breaking for no reason, your drive might be failing. Run sudo smartctl -a /dev/sda to check for reallocated sectors.

Final Thoughts

Repairing a bootloader manually is a great way to understand how Linux interacts with your hardware. While automated “Boot Repair” tools exist, they often add unnecessary scripts that can clutter your system. By using the chroot method, you maintain full control and ensure the fix is as clean as possible.