Dual-Boot Debugging Note: Fixing Windows Boot from GRUB on EndeavourOS

0. TL;DR

I installed EndeavourOS alongside Windows and wanted to select both Linux and Windows from GRUB.

The problem was not that Windows itself was broken. Windows could still boot correctly when selected directly from the motherboard firmware / BIOS boot menu.

The real issue was that GRUB was seeing multiple Windows / EFI remnants, and one of the automatically generated Windows entries was using a duplicated FAT UUID, which caused GRUB to resolve the wrong EFI partition.

That finally made:

GRUB -> Windows -> boot successfully

1. What problem did I run into?

After installing EndeavourOS, I wanted a clean dual-boot setup where I could choose either OS directly from GRUB.

However, Windows boot behavior became inconsistent:

• Booting Windows directly from BIOS / firmware worked
• Booting Windows from GRUB did not work reliably
• At different times, GRUB:
  • booted into an old Windows installation
  • entered Windows repair
  • or failed to find the target disk

There were also signs of old boot artifacts from a previous Windows installation or a previously cloned / reused disk layout.

Main symptoms

• os-prober detected two Windows Boot Managers
• UEFI had multiple Windows boot entries
• The EFI partitions had a duplicate FAT UUID
• GRUB's automatically generated Windows entry was not trustworthy

2. What did I try?

A. Verified the actual boot situation

I checked:

• efibootmgr -v
• lsblk -f
• os-prober
• EFI directory contents under /boot/efi
• Windows BCD contents using bcdedit

This helped confirm:

• Windows itself was still healthy
• the NVMe EFI partition contained both:
  • Microsoft
  • endeavouros
• BIOS could boot the correct Windows
• the problem was specifically the GRUB -> Windows path

B. Rebuilt Windows boot files

In Windows, I ran:

mountvol S: /S
bcdboot C:\Windows /s S: /f UEFI

This successfully rebuilt Windows boot files on the EFI partition.

C. Fixed Linux EFI mounting

I found that Linux was not consistently using the intended EFI partition because /etc/fstab was mounting /boot/efi by a FAT UUID that existed on more than one EFI partition.

So I changed /boot/efi to explicitly use the NVMe EFI partition instead of relying on the duplicated UUID.

D. Reinstalled GRUB to the correct EFI

I reinstalled GRUB onto the correct NVMe EFI partition.

E. Tried custom GRUB Windows entries

I tested several custom GRUB entries.

Some failed because:

• they used the duplicated FAT UUID
• they relied on a GRUB disk reference that did not resolve correctly on this machine
• or they still indirectly pointed into the wrong boot path

F. Tracked down the bad auto-generated GRUB entry

Eventually I confirmed that the bad Windows menu entry was being generated by:

/etc/grub.d/45_eos_windows

That script was generating a Windows entry using:

search --fs-uuid 0673-D633

That was the key problem, because that FAT UUID was duplicated across EFI partitions.

3. What finally worked?

The final successful solution was:

Step 1: Disable the bad auto-generated Windows entry

The problematic script was disabled so it would stop generating the wrong Windows entry.

Step 2: Add a manual Windows entry in 40_custom

Instead of using FAT UUID search, I manually added a GRUB entry that first finds the correct EFI partition by looking for a file unique to the EndeavourOS EFI directory:

menuentry "Windows (NVMe EFI)" {
    insmod part_gpt
    insmod fat
    insmod chain
    search --no-floppy --file --set=root /EFI/endeavouros/GRUBX64.EFI
    chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

Step 3: Regenerate GRUB

After regenerating grub.cfg, GRUB finally presented a clean Windows entry that worked.

Result

Windows now boots successfully from GRUB.

4. Why did this work?

Because the previous setup failed at the partition selection stage.

What was wrong before

The bad GRUB entry used:

search --fs-uuid 0673-D633

That was unreliable because multiple EFI partitions had the same FAT UUID.

So GRUB could resolve the wrong EFI partition, which then caused one of several bad outcomes:

• booting an old Windows installation
• entering repair
• failing to locate the disk properly

Why the final approach worked

The final manual entry used:

search --file /EFI/endeavouros/GRUBX64.EFI

That was much more reliable because:

• the file existed on the correct NVMe EFI
• it was a stronger discriminator than FAT UUID
• once GRUB found the correct EFI partition, chainloading:
  • /EFI/Microsoft/Boot/bootmgfw.efi worked correctly

So the final fix succeeded because it solved the real problem:

GRUB was not failing to chainload Windows in general; GRUB was selecting the wrong EFI partition.

5. Summary

Root cause

The system had multiple EFI / Windows remnants, and GRUB's automatically generated Windows entry relied on a duplicated FAT UUID, causing GRUB to target the wrong EFI partition.

What mattered most

• Windows itself was fine
• BIOS direct boot proved that
• Windows BCD on the NVMe EFI was also correct
• the failure was specifically in how GRUB located the Windows EFI partition

Final lesson

For tricky dual-boot cases like this:

• do not blindly trust auto-generated Windows entries
• do not rely on FAT UUID if multiple EFI partitions may exist
• verify:
  • EFI contents
  • BCD targets
  • GRUB script sources
• prefer a manual GRUB entry that locates the correct EFI partition using a unique file path

Final stable state

• GRUB boots EndeavourOS correctly
• GRUB also boots Windows correctly
• the broken auto-generated Windows entry is removed
• OS selection from GRUB now works as intended