How to Repair GRUB2 on Fedora from a Live USB
You rebooted after a routine update and the screen went black with a blinking cursor. Or maybe you installed Windows alongside Fedora and the GRUB menu vanished entirely. Your system is still there. The data is safe. The bootloader just lost its way. This happens. Fedora gives you the tools to fix it from a Live USB without touching your files.
The panic is real when the screen refuses to show the login prompt. The grub rescue> prompt looks like a terminal from a horror movie. A black screen with a single underscore suggests the hardware has no idea where to start. In every case, the operating system is intact. The connection between the firmware and the kernel is broken. You can rebuild that connection in minutes.
What's actually happening
GRUB has two distinct jobs. The first job is to load the kernel. The second job is to show you the menu so you can choose which kernel or operating system to boot. These jobs rely on two different locations on your disk.
The bootloader binary lives in the EFI System Partition. This is a small FAT32 partition that your motherboard firmware reads directly. Fedora places its files in /boot/efi/EFI/fedora/. If this binary is missing or corrupted, the firmware cannot hand off control to Linux. You see a black screen or a grub rescue> prompt.
The configuration file lives in /boot/grub2/grub.cfg. This file lists the available kernels, the initramfs images, and the boot parameters. If this file is missing, GRUB might still load but cannot find the kernel. You might see an error like error: file '/boot/vmlinuz-...' not found.
Windows updates are a common culprit. Windows sometimes overwrites the EFI partition during a major update, removing the Fedora entry. Fedora updates rarely break GRUB unless a manual partition change occurred. The repair process involves mounting your installed system from a Live USB and rewriting both the binary and the configuration.
The repair procedure
Boot the Fedora Live USB. Select "Troubleshooting" then "Rescue a Fedora system" if you want the automated rescue mode, or simply boot the Live desktop and open a terminal. The manual approach gives you full control and teaches you the mechanics. Open a terminal in the Live environment.
Identify your partitions before you mount anything. Guessing the partition device leads to mounting the wrong filesystem and wasting time.
# List block devices with filesystem details.
# The -f flag shows filesystem types and labels.
# Look for the partition with ext4 or btrfs that matches your root size.
lsblk -f
The output shows a tree of devices. An NVMe drive appears as nvme0n1. A SATA drive appears as sda. Partitions are numbered suffixes like p1, p2. The EFI partition is usually the first partition and has the vfat filesystem. The root partition is larger and has ext4 or btrfs. Note the device name of your root partition. It will look like /dev/nvme0n1p2 or /dev/sda2.
Mount the root partition to /mnt. This creates a bridge to your installed system.
# Mount the root partition to /mnt.
# Replace /dev/nvme0n1p2 with your actual root partition device.
sudo mount /dev/nvme0n1p2 /mnt
If you use a separate /boot partition, mount it now. Most Fedora installs combine /boot with root. If you have a separate /boot, mount it to /mnt/boot.
Bind mount the virtual filesystems. The chroot environment is isolated. It cannot see hardware or processes unless you explicitly connect those directories. Skipping this step causes grub2-install to fail with errors about missing devices.
# Bind mount /dev to give the chroot access to hardware devices.
# This is mandatory for bootloader installation.
sudo mount --bind /dev /mnt/dev
# Bind mount /proc to expose process information.
sudo mount --bind /proc /mnt/proc
# Bind mount /sys to expose kernel parameters and device attributes.
sudo mount --bind /sys /mnt/sys
Enter the chroot environment. Your prompt will change. You are now operating inside your installed Fedora system, not the Live USB. Any command you run affects the installed system.
# Change root to the mounted system.
# You are now root inside your installed Fedora.
sudo chroot /mnt
Reinstall the GRUB bootloader. Fedora defaults to UEFI systems. The command must target the EFI architecture and point to the EFI directory. The --bootloader-id flag names the folder in the EFI partition. This prevents conflicts with other operating systems.
# Reinstall GRUB to the EFI system partition.
# The --target flag ensures the correct x86_64 EFI binary is written.
# The --efi-directory flag points to the mounted ESP.
# The --bootloader-id flag names the folder as 'fedora'.
grub2-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=fedora
If you are on a legacy BIOS system, the command differs. Run grub2-install /dev/nvme0n1 replacing the device with your disk, not a partition. Fedora Workstation has not shipped BIOS defaults since Fedora 33, so UEFI is the standard case.
Regenerate the configuration file. This step scans your disk for kernels and other operating systems. It writes the menu entries that GRUB displays at boot.
# Regenerate the GRUB configuration file.
# This scans /boot for kernels and checks for other OSes.
# The output file is /boot/grub2/grub.cfg.
grub2-mkconfig -o /boot/grub2/grub.cfg
The command will print lines like Found linux image: /boot/vmlinuz-6.8.7-200.fc39.x86_64. If you dual-boot Windows, it should also print Found Windows Boot Manager on /dev/nvme0n1p1@/efi/Microsoft/Boot/bootmgfw.efi. If Windows is missing from the output, check that the EFI partition is mounted correctly and that the Windows bootloader file exists.
Exit the chroot and unmount the partitions. Leaving mounts active can corrupt the filesystem on reboot.
# Exit the chroot environment.
exit
# Unmount all mounted partitions under /mnt recursively.
# The -R flag handles submounts like /boot/efi automatically.
sudo umount -R /mnt
# Reboot the system.
sudo reboot
Unmount everything before you reboot. Leaving mounts active can corrupt the filesystem.
Verify the repair
The best verification is a successful boot. Remove the Live USB and restart. The GRUB menu should appear. Select Fedora and watch the system load. If the menu does not appear but the system boots, the repair succeeded. The menu might be hidden by default. Press Shift or Esc during boot to force the menu to show.
You can also verify the EFI files from your running system. Open a terminal and check the EFI directory.
# List the Fedora EFI directory to confirm the binary exists.
ls /boot/efi/EFI/fedora/
The output should contain grubx64.efi and shimx64.efi. If these files are present, the bootloader binary is intact. You can also check the configuration file size to ensure it is not empty.
# Check the size of the GRUB configuration file.
# A size of zero indicates mkconfig failed silently.
ls -lh /boot/grub2/grub.cfg
Run journalctl -b after boot to check for any lingering errors. Look for lines mentioning grub or efi. A clean boot log confirms the repair is complete.
Common pitfalls and what the error looks like
Mounting the wrong partition breaks the chroot. If you mount a data partition as root, the chroot environment lacks the necessary directories. Commands like grub2-install will fail with No such file or directory. Always verify the filesystem type and size with lsblk -f before mounting.
Forgetting bind mounts causes silent failures. grub2-install may appear to run but fail to write the EFI binary because it cannot access /dev. The error cannot find EFI directory or cannot read EFI variables points to missing bind mounts. Run the bind mount commands again and retry.
LVM and LUKS require extra steps. This procedure assumes standard partitions. If your root volume is on LVM, you must activate the volume group with vgchange -ay before mounting. If your disk is encrypted with LUKS, you must unlock it with cryptsetup luksOpen first. The Live USB rescue mode handles LVM and LUKS automatically. Use the rescue mode if you are unsure about your storage layout.
Editing grub.cfg manually is a trap. The file is generated by grub2-mkconfig. Any manual edits disappear the next time you run the command or update the kernel. Edit /etc/default/grub for persistent changes like timeout or default entry. Then run grub2-mkconfig to apply them. Trust the package manager. Manual file edits drift, snapshots stay.
Secure Boot can block custom kernels. If you compiled a custom kernel, the bootloader might refuse to load it. Fedora ships with signed shim and GRUB binaries. Custom kernels require manual signing. If you see a signature verification error, check the Secure Boot status in the firmware settings.
When to use this approach
Use a Live USB chroot repair when the system cannot boot and you need to rewrite the bootloader from an external environment.
Use sudo grub2-install from a running system when GRUB is missing entries but the system boots fine and you want to reinstall the binary without rebooting.
Use sudo dnf reinstall grub2-common grub2-efi-x64 when configuration files are corrupted but the system is accessible and you want to restore package defaults.
Use grub2-mkconfig alone when you added a new kernel or second operating system and want to update the menu without touching the EFI partition.
Use the Live USB rescue mode when you are uncomfortable with manual mount commands or your storage uses LVM and LUKS encryption.