You click the update button in Windows
You click the update button in Windows. The system restarts. The screen goes black, then Windows loads directly to the desktop. The GRUB menu is gone. Your Fedora installation is still intact, but the bootloader that hands off control has been overwritten or demoted in the firmware boot order. This happens more often than you expect. Windows Update occasionally resets the EFI boot priority or replaces the boot manager files on the shared EFI System Partition.
Reboot before you debug. Half the time the symptom is gone.
What's actually happening
Dual-boot systems share a small FAT32 partition called the EFI System Partition. Both operating systems store their bootloaders there. Fedora places its files in /boot/efi/EFI/Fedora/. Windows places its files in /boot/efi/EFI/Microsoft/. The UEFI firmware maintains a boot order list that points to these directories. When Windows Update runs, it sometimes reprioritizes its own boot manager to the top of the list. In worse cases, it deletes the Fedora directory entirely or overwrites the default boot path. The operating system files on your Linux root partition are untouched. Only the handoff mechanism is broken.
Think of the EFI partition as a shared reception desk. The firmware asks the desk which OS to wake up first. Windows Update sometimes rearranges the name tags or removes the Fedora tag. You need to drop into your installed Fedora environment from a Live USB, rewrite the EFI files, and restore the correct boot order. The process uses a chroot to make the Live environment think it is running inside your actual system. This lets package managers and bootloader installers work against the correct disk layout.
Trust the package manager. Manual file edits drift, snapshots stay.
The fix
Boot your machine from a Fedora Live USB. Select the option to try Fedora without installing. Open a terminal and identify your partitions. You need the root partition where Fedora lives and the EFI System Partition. Run lsblk -f to see filesystem labels and UUIDs. Look for the partition labeled fedora_... or root and the one labeled EFI or FAT32.
Here is how to mount the partitions and prepare the chroot environment. Replace the device names with your actual partitions.
sudo mount /dev/nvme0n1p2 /mnt
# Mount the root filesystem so the chroot has a working directory
sudo mount /dev/nvme0n1p1 /mnt/boot/efi
# Mount the EFI partition where bootloader binaries live
sudo mount --bind /dev /mnt/dev
# Share device nodes so hardware and block devices are visible
sudo mount --bind /proc /mnt/proc
# Share process information for the chroot environment
sudo mount --bind /sys /mnt/sys
# Share kernel subsystem data like firmware and drivers
sudo chroot /mnt
# Switch the root directory to the mounted Fedora system
You are now inside your installed Fedora system. The prompt will change to reflect the chroot. The first step is to ensure the bootloader packages are present and correctly linked. Windows updates sometimes leave orphaned or broken symlinks in the EFI directory. Reinstalling the packages forces the package manager to restore the correct files.
dnf reinstall grub2-efi-x64 shim-x64 --assumeyes
# Restore the GRUB binaries and the Secure Boot shim wrapper
grub2-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Fedora
# Write the GRUB EFI binary to the shared partition
grub2-mkconfig -o /boot/grub2/grub.cfg
# Scan for installed kernels and Windows, then rebuild the menu
The grub2-install command copies the bootloader to /boot/efi/EFI/Fedora/ and registers it with the EFI firmware. The grub2-mkconfig command runs os-prober in the background to detect Windows and other Linux installations. It writes the final configuration file that GRUB reads at startup. If os-prober fails to detect Windows, the menu will still boot Fedora correctly. You can add a manual Windows entry later if needed. Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/default/grub for timeout or theme changes, then rerun grub2-mkconfig. Never edit /boot/grub2/grub.cfg directly.
Before exiting, check the SELinux contexts on the boot directory. A chroot environment sometimes misses the automatic relabeling that happens during a normal package install. Restoring the contexts prevents boot failures caused by security policy denials.
restorecon -Rv /boot
# Reset SELinux file contexts to match the policy defaults
exit
# Leave the chroot and return to the Live environment
Unmount the filesystems in reverse order. The --all flag handles the bind mounts cleanly.
sudo umount -R /mnt
# Recursively unmount all bind mounts and the root filesystem
Reboot the machine and remove the USB drive. The GRUB menu should appear. If the firmware still boots straight to Windows, you need to adjust the boot order from the firmware setup screen or use efibootmgr from the Live environment.
Run journalctl first. Read the actual error before guessing.
Verify it worked
Boot into Fedora and open a terminal. Check the EFI boot order to confirm Fedora is listed.
sudo efibootmgr
# Display the current UEFI boot order and registered entries
Look for an entry labeled Fedora with a boot number. The BootOrder line should list that number first. If Windows is still first, change the order from the firmware menu or run sudo efibootmgr --bootnext <number> to test the next boot. Verify the GRUB configuration contains the Windows entry by checking the generated file.
grep -i windows /boot/grub2/grub.cfg
# Confirm os-prober detected the Windows installation
Run journalctl -xe after the first successful boot. The x flag adds explanatory text and the e flag jumps to the end. Look for clean GRUB and systemd startup messages. If you see Failed to start GRUB or EFI stub loader failed, the EFI binary path is still misaligned. Check that /boot/efi is mounted and that the shimx64.efi file exists in the Fedora EFI directory.
Snapshot the system before the upgrade. Future-you will thank you.
Common pitfalls and what the error looks like
Mounting the wrong partition as /boot/efi is the most common mistake. The EFI partition must be FAT32 and usually under 500 megabytes. Mounting a Linux ext4 partition there will cause grub2-install to fail with this exact output:
Installing for x86_64-efi platform.
grub-install: error: /boot/efi doesn't exist or isn't mounted.
Check your partition table before mounting. The lsblk -f command shows filesystem types clearly.
Secure Boot complications appear when the shim-x64 package is missing or the signature chain is broken. The firmware will drop you into a shellx64 prompt or show Security Violation. The reinstall command above restores the signed shim. If you compiled a custom kernel, you must sign it with your own Machine Owner Key before GRUB can load it under Secure Boot.
Legacy BIOS systems do not use EFI partitions. If your machine predates 2012, you are likely using GRUB PC. The fix requires grub2-install /dev/sda targeting the whole disk, not a partition. The --target=i386-pc flag is implied. Modern Fedora installations default to UEFI. Check your firmware setup screen to confirm the boot mode.
SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. A missing context on /boot/efi/EFI/Fedora/grubx64.efi will cause the firmware to reject the binary even if it is valid. The restorecon step above prevents this. If you still get boot loops, run touch /.autorelabel inside the chroot before exiting. The system will relabel all files on the next boot, which takes extra time but guarantees correct contexts.
If the boot menu is gone, GRUB rescue is your friend, not your enemy.
When to use this vs alternatives
Use the chroot method when Windows Update overwrites the EFI files or breaks the boot order. Use the firmware boot menu when the GRUB files are intact but the firmware priority list changed. Use a full Fedora reinstall when the root filesystem is corrupted or the partition table is damaged. Stay on the default GRUB configuration if you only need to adjust timeout values or menu themes. Edit /etc/default/grub and run grub2-mkconfig instead of touching EFI binaries directly. Use efibootmgr when you need to reorder boot entries without touching disk partitions. Use os-prober configuration flags when Windows fails to detect automatically.