Does it matter which live USB distribution I use?

Any live Linux environment works as long as it boots in the same firmware mode (UEFI or BIOS) as your installed system. Using the same distribution is convenient because the package tools match, but it is not required.

My system uses LVM or LUKS encryption. Does the process change?

Yes. Before chrooting you need to assemble the LVM volume group (vgchange -ay) or unlock the LUKS container (cryptsetup open) so the root filesystem is accessible. The GRUB reinstall and config regeneration steps are the same afterward.

Why do I need to regenerate grub.cfg separately? Shouldn't grub-install do that?

grub-install only writes the GRUB bootloader code to the disk or ESP. It does not scan for kernels. grub-mkconfig (and its wrappers) does that scan and writes the menu configuration file that the bootloader reads at startup.

Will reinstalling GRUB remove Windows or other operating systems from the boot menu?

No. grub-mkconfig uses os-prober to detect other operating systems on the disk and includes them in grub.cfg automatically. If Windows disappears from the menu after the repair, install the os-prober package and regenerate the config again.

I have a dual-boot system and Windows keeps overwriting GRUB after updates. How do I prevent this?

Windows Update sometimes resets the UEFI boot order to prefer the Windows Boot Manager. After a Windows update, boot a live USB and rerun efibootmgr to restore the boot order, or use your firmware's boot order settings to permanently prioritize GRUB.

How to Fix a Broken GRUB Bootloader

A broken GRUB bootloader leaves you staring at a blank screen, a grub rescue> prompt, or an "error: no such partition" message instead of your desktop. This happens after accidental overwrites from a Windows installation, a failed kernel update, or corrupted partition tables. The fix follows a consistent pattern regardless of the cause: boot from live media, mount your system, chroot into it, and reinstall GRUB. This guide covers BIOS/MBR and UEFI/GPT systems.

Identify Your Setup Before You Start

Before running any commands you need to know two things: whether your machine uses BIOS/MBR or UEFI/GPT, and which disk and partition holds your Linux root filesystem. You can figure both out from a live session.

Check Firmware Mode

Boot the live environment and check whether the system was installed in UEFI mode:

ls /sys/firmware/efi

If that directory exists, you are running in UEFI mode and have an EFI System Partition (ESP). If it is absent, you are on a BIOS/MBR system.

Locate Your Partitions

lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT,PARTTYPENAME

Note the device name of your root partition (e.g., /dev/sda2 or /dev/nvme0n1p3) and, on UEFI systems, your ESP (usually a small FAT32 partition, often the first, around 100–512 MB).

Step 1 — Boot From Live Media

Use a live USB that matches your installed distribution when possible. Ubuntu, Fedora, and Arch ISOs all work; the key requirement is that the live environment boots in the same firmware mode (UEFI or BIOS) as your installed system. On UEFI machines this usually means selecting the entry labelled UEFI in the boot menu. If you boot the live USB in BIOS mode but your system was installed in UEFI mode, the GRUB you reinstall will not be found by the firmware.

Step 2 — Mount the Installed System

Replace /dev/sda2 with your actual root partition throughout this section.

Mount Root

sudo mount /dev/sda2 /mnt

Mount Virtual Filesystems

These are required for the chroot environment to work correctly with hardware and the kernel.

sudo mount --bind /dev  /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys  /mnt/sys

UEFI Only — Mount the ESP

Check where your installed system expects the ESP. It is almost always /boot/efi.

sudo mount /dev/sda1 /mnt/boot/efi

If you have a separate /boot partition, mount that too before the ESP:

sudo mount /dev/sda3 /mnt/boot
sudo mount /dev/sda1 /mnt/boot/efi

Mount efivars (UEFI Only)

sudo mount --bind /sys/firmware/efi/efivars /mnt/sys/firmware/efi/efivars

Step 3 — Chroot Into the Installed System

sudo chroot /mnt

Your prompt will change. You are now executing commands as root inside your installed system, with access to its packages, configuration, and kernel.

Step 4 — Reinstall GRUB

The command differs by firmware mode and distribution.

BIOS/MBR Systems

Install GRUB to the disk, not a partition. Replace /dev/sda with your target disk.

# Debian / Ubuntu
grub-install /dev/sda

# Fedora / RHEL / Rocky
grub2-install /dev/sda

# Arch Linux
grub-install --target=i386-pc /dev/sda

UEFI/GPT Systems

On UEFI you do not specify a disk — GRUB installs itself into the ESP and registers a firmware boot entry.

# Debian / Ubuntu
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu

# Fedora / RHEL / Rocky
dnf reinstall grub2-efi-x64 grub2-efi-x64-modules shim-x64

# Arch Linux
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB

The --bootloader-id value becomes the label shown in your firmware's boot menu. You can use any name you like, but stick to ASCII characters.

Step 5 — Regenerate the GRUB Configuration File

Reinstalling GRUB alone is not enough. The configuration file at /boot/grub/grub.cfg (or /boot/grub2/grub.cfg on RHEL-family distros) must be regenerated so GRUB knows which kernels to boot.

# Debian / Ubuntu
update-grub

# Fedora / RHEL / Rocky (EFI path)
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

# Fedora / RHEL / Rocky (BIOS path)
grub2-mkconfig -o /boot/grub2/grub.cfg

# Arch Linux
grub-mkconfig -o /boot/grub/grub.cfg

update-grub is a thin wrapper around grub-mkconfig; both do the same thing. Watch the output — it should list the kernels it finds. If it reports no kernels found, your kernel packages may be missing or the /boot partition was not mounted correctly.

Step 6 — Exit Chroot and Reboot

exit

sudo umount -R /mnt
sudo reboot

Remove the live USB when prompted, or simply let the firmware prefer the newly registered GRUB entry.

Verification

After rebooting into your system, confirm GRUB is correctly installed and the configuration is current:

# Debian / Ubuntu / Arch
grub-install --version
cat /boot/grub/grub.cfg | grep menuentry

# UEFI — check the firmware boot order
efibootmgr -v

The output of efibootmgr -v should show your distribution's entry as active (marked with an asterisk) and pointing to the correct ESP path.

Troubleshooting

"grub-install: error: cannot find EFI directory"

The ESP was not mounted before running grub-install. Re-enter chroot, mount /dev/sda1 (or your ESP) to /boot/efi, and run the install command again.

"error: no such partition" at Boot

GRUB's stored partition UUID no longer matches the actual disk. This usually means grub.cfg was not regenerated, or a partition was resized. Regenerate the config from inside chroot and reboot.

System Still Boots Straight to Windows or Firmware

The UEFI firmware is ignoring the new GRUB entry. Use efibootmgr inside the installed system to reorder boot entries:

# List entries and their hex IDs
efibootmgr -v

# Set Linux entry (e.g., Boot0002) as first
efibootmgr --bootorder 0002,0000,0001

GRUB Rescue Prompt With No Live Media

If you are stuck at grub rescue> and cannot boot the live USB, you can sometimes manually load GRUB modules to get to the menu:

set root=(hd0,gpt2)
insmod normal
normal

Replace (hd0,gpt2) with the partition that contains your /boot directory. Once booted, run the full reinstall procedure above and make it permanent.

Secure Boot Blocks GRUB

On systems with Secure Boot enabled, GRUB must be signed. Fedora, Ubuntu, and Debian ship signed shim loaders that handle this automatically. Arch Linux requires you to sign GRUB yourself or disable Secure Boot. If your firmware shows a Secure Boot violation, check that the shim package is installed and that grub-install is using the shim EFI path.