The Windows installer overwrites the bootloader
You installed a major Windows update or reinstalled Windows on your dual-boot machine. You rebooted, and the GRUB menu vanished. Windows boots straight to the desktop. Your Fedora installation is still there, but the bootloader that points to it has been overwritten. This happens because the Windows installer treats the disk as its own and replaces the existing bootloader without asking.
What actually happened to your disk
Think of the bootloader as the front door to your house. GRUB was the doorman who asked which room you wanted to enter. Windows setup walked in, fired the doorman, and installed a new lock that only opens the Windows room. The Fedora room still exists, but the new lock does not know about it.
On UEFI systems, which cover almost all modern Fedora installations, the Windows installer modifies the EFI System Partition. It drops its own boot files and updates the NVRAM boot order to prioritize Windows. On legacy BIOS systems, the installer overwrites the Master Boot Record with its own code. The result is the same: GRUB is no longer in control. You need to boot from a Fedora Live USB, chroot into your installed system, and reinstall GRUB to take back the front door.
Reboot from the Live USB before you start. The recovery process requires a clean environment and direct access to the disk partitions.
Restore GRUB from a Live USB
Boot the Fedora Live USB and open a terminal. You need to identify your partitions, mount the installed system, and run the GRUB installation commands inside a chroot environment.
Here is how to list your partitions and identify the root and EFI devices.
lsblk -f # Show device names, mount points, and filesystem types to identify partitions
Look for the partition with xfs or btrfs labeled Fedora or your root mount point. Note the device name, such as /dev/nvme0n1p4. Also note the EFI System Partition, which is a small vfat partition, usually /dev/nvme0n1p1.
Mount the root partition and the EFI System Partition. The EFI partition must be mounted at /mnt/boot/efi so GRUB can install its files to the correct location.
sudo mount /dev/nvme0n1p4 /mnt # Mount the Fedora root partition
sudo mount /dev/nvme0n1p1 /mnt/boot/efi # Mount the EFI System Partition for UEFI systems
Bind mount the virtual filesystems so the chroot environment has access to hardware devices and kernel information. Without these mounts, commands inside the chroot will fail with missing device errors.
sudo mount --bind /dev /mnt/dev # Expose hardware devices to the chroot environment
sudo mount --bind /proc /mnt/proc # Expose process information to the chroot environment
sudo mount --bind /sys /mnt/sys # Expose kernel interfaces to the chroot environment
sudo chroot /mnt # Switch root directory to the installed system
Reinstall GRUB to the disk device and regenerate the configuration file. The installation target is the disk, not a partition. The configuration step scans for operating systems and updates the boot menu.
grub2-install /dev/nvme0n1 # Install GRUB binaries to the disk device, not a partition
grub2-mkconfig -o /boot/grub2/grub.cfg # Scan partitions and regenerate the boot menu configuration
Exit the chroot and unmount the filesystems. Leaving mounts active can cause stale mount errors on the next boot.
exit # Exit the chroot environment
sudo umount -R /mnt # Recursively unmount all partitions under /mnt
Reboot immediately. The chroot environment is fragile and a power loss here can corrupt the mount table.
Handle Btrfs and LVM correctly
Fedora Workstation uses Btrfs by default. If your root filesystem is Btrfs, the mount command in the previous section may not attach the correct subvolume. You must specify the subvolume option.
Mount the root subvolume explicitly if your installation uses Btrfs.
sudo mount -o subvol=/@ /dev/nvme0n1p4 /mnt # Mount the root subvolume if Fedora uses Btrfs
If you use LVM, the logical volumes are not active in the Live USB environment. You must activate the volume groups before mounting.
Activate LVM volume groups so logical volumes become available for mounting.
sudo lvm vgchange -ay # Activate volume groups so logical volumes become available
Check the subvolume layout if the standard mount fails. Btrfs subvolume names can vary depending on the installation date.
sudo btrfs subvolume list /mnt # List subvolumes to verify the root path
Run journalctl -xe on the installed system if the boot fails after recovery. The logs often reveal mount errors or missing subvolumes that prevent the root filesystem from loading.
Verify the boot chain
After rebooting, check that GRUB appears and that Windows is listed. If the system boots straight to Windows, the firmware boot order may still prioritize the Windows entry.
List the EFI boot entries to verify Fedora is registered and ordered correctly.
efibootmgr # List EFI boot entries to verify Fedora is registered and ordered
Look for an entry named Fedora. If the entry exists but is not first, reorder the boot entries using the -o flag with the hex codes from the output.
Reorder the boot entries if Windows loads first despite GRUB being installed.
sudo efibootmgr -o 0001,0000 # Set boot order with Fedora first, replace codes with your actual entry numbers
Check Secure Boot status if GRUB fails to load and drops to a shell. Windows updates can sometimes reset Secure Boot variables or interfere with the shim loader.
mokutil --sb-state # Check if Secure Boot is enabled and verify shim status
Trust the package manager. Manual file edits drift, snapshots stay. If GRUB binaries are corrupted, run sudo dnf reinstall grub2-efi-x64 shim-x64 inside the chroot before reinstalling.
Common errors and fixes
The grub2-install command will refuse to proceed and print error: failed to get canonical path of 'cow'. This error occurs when the chroot environment cannot resolve device paths. Ensure you bind-mounted /dev, /proc, and /sys before entering the chroot. If you use Btrfs, verify the subvolume is mounted correctly.
If you see error: /usr/lib/grub/i386-pc/modinfo.sh doesn't exist, you are targeting the wrong architecture. This happens when running a BIOS command on a UEFI system. Fedora uses grub2-install which auto-detects the target. Do not pass --target=i386-pc on UEFI systems.
Never edit /boot/grub2/grub.cfg directly. That file is generated by grub2-mkconfig. Changes vanish on the next kernel update. Edit /etc/default/grub for global settings or add scripts to /etc/grub.d/ for custom entries.
If the boot menu appears but Windows is missing, the OS probe may be disabled. Run grub2-mkconfig again and watch the output. If it skips Windows, check that the Windows partition is not hidden and that the EFI files are intact.
Reboot before you debug. Half the time the symptom is gone.
Choose the right recovery tool
Use grub2-install when the bootloader binary is missing or the EFI entry has been overwritten by Windows.
Use grub2-mkconfig when GRUB boots but fails to detect the Windows partition or a new kernel.
Use efibootmgr -o when the boot order is wrong and Windows still loads first despite GRUB being installed.
Use dnf reinstall grub2-common when configuration files are corrupted and standard reinstall commands fail.
Stay on the Live USB rescue environment when the installed system cannot mount or the chroot fails due to missing dependencies.