You updated Windows and Fedora vanished
You clicked "Update and Restart" in Windows. The screen went black. The manufacturer logo appeared. Windows loaded. You waited for the GRUB menu. It never came. You don't see Fedora. You don't see the option to choose an operating system. The system boots straight to the Windows desktop. You panic. You think the update wiped your Linux installation. It didn't. Your files are safe. Your kernel is intact. The bootloader chain is just pointing the wrong way.
Windows Update runs maintenance scripts that touch the boot area of your disk. These scripts can delete the GRUB entry, set Windows as the default boot target, or overwrite the boot code entirely. The result is the same. Your firmware hands control to Windows, and Windows has no idea Fedora exists. You need to restore GRUB as the primary bootloader so you can choose where to go. This repair takes five minutes if you have a Live USB and know which partition holds your root filesystem.
What the bootloader chain looks like
The bootloader lives in a special area of your disk. On modern UEFI systems, this is the EFI System Partition. This partition is formatted as FAT32 and holds small executable files for each operating system. Fedora installs a file named shimx64.efi and grubx64.efi in a subdirectory. The firmware reads a boot entry that points to this file. On older BIOS systems, the bootloader lives in the Master Boot Record, a small sector at the start of the disk.
Windows Update sometimes runs a tool called bcdboot. This tool refreshes the Windows boot configuration. It can delete other entries from the EFI partition. It can change the boot order so Windows loads first. It can overwrite the fallback boot path. On legacy BIOS, Windows can overwrite the Master Boot Record with its own boot manager. The effect is the same across firmware types. The chain is broken. The firmware finds Windows and stops looking.
The data is safe. The bootloader is just a pointer. Fix the pointer, and the system returns.
Check the firmware boot order first
Before you grab a USB drive, check the firmware settings. Many systems allow you to change the boot order without reinstalling anything. Restart the computer. Press F2, F12, Del, or Esc depending on your manufacturer. Look for Boot Order or Boot Priority. If you see "Fedora" or "GRUB" in the list, move it to the top. Save and exit. If Fedora appears, you are done. If the list only shows Windows, or if "Fedora" is missing, you need to reinstall the bootloader.
Reboot before you debug. Half the time the symptom is gone after a boot order change.
Reinstall GRUB from a Live USB
You need a Fedora Live USB. If you don't have one, create one on another machine using the ISO from the Fedora website. Boot from the USB. Select "Troubleshooting" then "Rescue a Fedora system" or boot to the desktop and open a terminal. The rescue environment gives you access to the disk without mounting the root filesystem automatically. This is safer. You control what gets mounted.
Identify your partitions
Here's how to list your partitions so you can find the root filesystem and the EFI partition. The output shows device names, sizes, and filesystem types. Look for the partition with ext4 or btrfs that matches the size of your Fedora installation. Look for the small vfat partition for the EFI System Partition.
# List all block devices with filesystem labels and types.
# Look for the root partition (ext4/btrfs) and EFI partition (vfat).
lsblk -f
The output will look similar to this. Your device names will differ. Note the partition for root and the partition for EFI.
NAME FSTYPE LABEL UUID
nvme0n1
ββnvme0n1p1 vfat 1234-5678
ββnvme0n1p2 ext4 aaaa-bbbb-cccc
ββnvme0n1p3 ext4 dddd-eeee-ffff
In this example, nvme0n1p1 is the EFI partition. nvme0n1p3 is likely the root partition. nvme0n1p2 might be Windows or a data partition. Verify the size to be sure.
Mount the filesystem and prepare the chroot
Here's how to mount the root filesystem and the EFI partition, then bind mount the virtual filesystems required for a working chroot environment. The chroot command changes the root directory for the current shell. This makes the installed system look like the running system. However, the installed system needs access to devices and system information. That's why you bind mount /dev, /proc, and /sys. Without these, commands like grub2-install cannot detect disks or firmware types.
# Mount the root filesystem. Replace /dev/nvme0n1p3 with your actual root partition.
mount /dev/nvme0n1p3 /mnt
# Mount the EFI partition. This must be at /boot/efi inside the chroot.
mount /dev/nvme0n1p1 /mnt/boot/efi
# Bind mount /dev to provide access to block devices and terminals.
mount --bind /dev /mnt/dev
# Bind mount /proc to provide access to process and kernel information.
mount --bind /proc /mnt/proc
# Bind mount /sys to provide access to hardware and driver details.
mount --bind /sys /mnt/sys
If you have a separate /boot partition, mount it to /mnt/boot before mounting the EFI partition. The EFI partition must be at /mnt/boot/efi. If you skip the bind mounts, the chroot will fail with errors about missing devices or firmware.
Reinstall the bootloader and regenerate config
Here's how to enter the chroot, reinstall GRUB to the EFI partition, and regenerate the configuration file. The grub2-install command writes the bootloader files to the EFI partition and registers the boot entry with the firmware. The grub2-mkconfig command scans for kernels and other operating systems, then writes the menu configuration. Always run grub2-mkconfig after grub2-install. The config must match the installed bootloader.
# Enter the installed system. This makes /mnt look like / for the commands that follow.
chroot /mnt
# Reinstall GRUB to the EFI partition. The --target flag matches your firmware type.
grub2-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=fedora
# Regenerate the config file. This scans for kernels and other OSes.
grub2-mkconfig -o /boot/grub2/grub.cfg
# Exit the chroot environment.
exit
The --target=x86_64-efi flag is required for UEFI systems. On legacy BIOS systems, you would use --target=i386-pc and install to the disk device like /dev/sda. Fedora defaults to UEFI on modern hardware. If you are unsure, check lsblk output. If you see an EFI partition, use the EFI target.
Run grub2-mkconfig last. The config must match the installed bootloader.
Verify the repair
Unmount the filesystems and reboot. Remove the USB drive. The GRUB menu should appear. If you see the menu, the fix worked. If you boot straight to Windows again, check the boot order in your firmware settings. Some laptops hide the boot menu behind a specific key. Press F12 or Esc during startup to bring up the boot menu. Select Fedora from the list.
If you see a grub rescue> prompt, the configuration file is missing or corrupted. Boot back into the Live USB, chroot again, and run grub2-mkconfig. The prompt appears when GRUB loads but cannot find the config file. This usually means the EFI entry points to the wrong file or the config file is missing.
Reboot and remove the USB. The menu should appear. If it doesn't, check the mount points again.
Common errors and how to read them
Errors during this process usually point to a mounting mistake or a target mismatch. Read the error message carefully. The path in the error tells you exactly what went wrong.
If you see grub2-install: error: cannot find EFI directory, you likely forgot to mount the EFI partition or mounted it to the wrong path. The EFI partition must be at /boot/efi inside the chroot. Check your mount commands. Run ls /mnt/boot/efi to verify the partition is accessible.
If you see error: disk 'hd0,msdos1' not found, your partition labels might have shifted. Windows updates can sometimes change partition order. Regenerate the config to pick up the new identifiers. Run grub2-mkconfig again. The tool scans the disk and updates the references.
If you see grub2-install: error: failed to get canonical path of /dev/sda, you are likely on a UEFI system but trying to install to a disk device instead of specifying the target. Use --target=x86_64-efi. The disk device syntax is for legacy BIOS installations.
If you see Security Violation or Invalid Signature, Secure Boot is blocking the bootloader. Fedora ships with signed bootloaders. This error usually appears if you installed a custom kernel or modified the boot chain. Disable Secure Boot in the firmware settings to proceed. You can re-enable it later if you enroll the necessary keys. For dual boot with Windows, keeping Secure Boot enabled is usually fine as long as you use the default Fedora packages.
Read the error message. The path in the error tells you exactly what went wrong.
Managing the GRUB configuration
Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/default/grub. Never edit /boot/grub2/grub.cfg. The generated file contains comments that warn you not to edit it. Trust the generator. Manual edits drift and get overwritten.
The file /etc/default/grub controls the behavior of the menu. You can change the timeout, the default entry, or add kernel parameters. For example, to change the timeout from 5 seconds to 10 seconds, edit the line GRUB_TIMEOUT=5 to GRUB_TIMEOUT=10. After editing, run grub2-mkconfig -o /boot/grub2/grub.cfg to apply the changes.
If you need to pass parameters to the kernel, add them to GRUB_CMDLINE_LINUX. For example, to disable the splash screen and show boot messages, add quiet=0 to the string. The parameter applies to all kernels. If you need a parameter for a specific kernel, use the GRUB menu editor. Press e at the menu to edit the entry for that boot only.
Edit /etc/default/grub. Never touch the generated file.
When to use each recovery method
Use the firmware boot menu when GRUB is installed but Windows is set as the default. Use grub2-install from a Live USB when the bootloader is missing or corrupted. Use bcdboot from Windows Recovery when you prefer Windows to handle booting and chainload Linux. Stay on GRUB as the primary bootloader when you want a unified menu and direct control over boot parameters.
Use the right tool for the breakage. Reinstalling GRUB is the nuclear option. Check the boot order first.