Dual Boot GRUB Missing Windows Entry – Fix Guide

1. os-prober Didn't Run – The Most Common Cause

What's actually happening here is: after a kernel update or GRUB reinstall, the update-grub command runs but doesn't call os-prober unless the config explicitly allows it. On Ubuntu 22.04+ and Debian 12+, the file /etc/default/grub has a line GRUB_DISABLE_OS_PROBER=false that's commented out by default. That's the culprit.

I've seen this on a Dell XPS 13 running Ubuntu 23.10 after a routine apt upgrade. One minute Windows 11 was there, next reboot—poof, gone. The fix is stupid simple once you know.

1. Boot into Linux. Open a terminal.
2. Edit the GRUB config file: sudo nano /etc/default/grub
3. Find the line #GRUB_DISABLE_OS_PROBER=false. Uncomment it (remove the #).
4. Save and exit.
5. Run: sudo update-grub

The reason step 5 works is because update-grub now runs os-prober, which scans all disks for bootable OSes. It'll output something like "Found Windows Boot Manager on /dev/nvme0n1p1". If you see that, you're good. Reboot and Windows should be back.

If you still don't see it, check if os-prober is installed: dpkg -l | grep os-prober. On minimal installs it might be missing. Install it with sudo apt install os-prober and run sudo update-grub again.

2. GRUB Installed to Wrong Disk – Second Most Common

This one happens when you reinstall Linux (maybe trying a different distro) or use a tool like Boot-Repair. GRUB ends up on the Linux disk, but your UEFI firmware is looking at a different EFI System Partition (ESP).

I ran into this on a custom PC with a Gigabyte Z790 motherboard. Windows on a Samsung 980 Pro NVMe, Linux on a separate Crucial SSD. After reinstalling Fedora 39, the Windows entry vanished. What actually happened: the Fedora installer put GRUB on the Crucial SSD's ESP, but the motherboard's boot order still pointed to the Samsung NVMe's ESP (which only had Windows boot files). GRUB never loaded.

Fix: reinstall GRUB to the correct disk.

1. Find your Linux boot partition: lsblk -f. Look for the partition mounted at /boot or /boot/efi. It'll say vfat and have a size around 100-500 MB.
2. Mount that partition if not already: sudo mount /dev/sdXY /mnt (replace sdXY with your ESP, like /dev/nvme0n1p1).
3. Reinstall GRUB: sudo grub-install --target=x86_64-efi --efi-directory=/mnt --bootloader-id=GRUB
4. Update config: sudo update-grub

The --efi-directory flag is key—it tells GRUB where the ESP is. Don't skip it. After that, check your BIOS boot order and make sure the GRUB entry (usually "GRUB" or "Linux") is first.

3. Windows EFI Boot Files Got Corrupted or Moved

Less common but happens after Windows updates (especially the 23H2 one) or disk repartitioning. The Windows bootloader isn't gone, but its EFI file path changed or got deleted.

You can verify this: boot a live Linux USB, mount the ESP, and list files: ls /mnt/EFI/Microsoft/Boot/. If that folder is empty or missing, Windows boot files are toast. But often the folder is there—the problem is GRUB's os-prober can't find the correct UUID because the partition table changed.

Fix: regenerate the GRUB config and manually add a custom entry.

1. Run sudo os-prober alone. See if it detects Windows. If not, something's wrong with the partition table.
2. Check the UUID of the Windows ESP: sudo blkid /dev/nvme0n1p1 (adjust device). Note the UUID.
3. Add a manual entry by editing /etc/grub.d/40_custom:

menuentry "Windows 11" {
  insmod part_gpt
  insmod fat
  insmod chain
  set root='(hd0,gpt1)'
  chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

Replace (hd0,gpt1) with your actual device—use sudo grub-probe --target=device /dev/nvme0n1p1 to get the right format. Then run sudo update-grub.

Quick-Reference Summary Table

One last thing: if nothing works, you can always boot from a Windows recovery USB and run bootrec /fixmbr, but that will remove GRUB entirely—only do that if you want to kill the dual boot. I've done it once, regretted it.