Solus/Windows 10 dual boot stopped working, not automatically fixed by GRUB

Question

I had a system setup to dual boot Windows 10 with Solus Linux; however, after some trouble with one of my secondary drives (ended up removing it, Windows worked fine without it for a time), attempting to boot Windows in GRUB yielded an error I do not remember, and I had to update Solus through the terminal to get it to boot properly (if I remember correctly). Now, Solus boots fine, but Windows doesn't show up in GRUB at all and after researching and trying solutions for hours I feel like smashing my head against a brick wall. Things I've seen recommended and tried but don't work:

• Attempting to automatically fix it by running os-prober and update-grub. At first, I was receiving an error stating WARNING: Failed to connect to lvmetad. Falling back to device scanning.. Once I resolved this by restarting the lvmetad service, it would output nothing, GRUB would say it updated its configuration, and still no Windows.

• Attempting to manually add a Windows 10 Boot Entry. Mostly following this guide, I struggled to find the fs-uuid but eventually managed to get it. I was never able to get the hints_string working though, always receiving the error grub-probe: warning: unknown device type nvme0n1.. Furthermore, I could not find the /EFI/Microsoft/Boot/bootmgfw.efi I'm supposed to have in my Windows installation, instead finding bootmgfw.efi located at /Windows/Boot/EFI/bootmgfw.efi and receiving an error whenever I try to access the other location that it doesn't exist. Despite these hurdles, I pressed on and added the following as a manual entry to /etc/grub.d/40_custom, only to be met with an error: invalid signature and disappointment.

# Microsoft Windows 10
menuentry "Windows 10" {
  insmod part_gpt
  insmod ntfs
  insmod search_fs_uuid
  insmod chain
  search --no-floppy --fs-uuid --set=root 2E6E49286E48E9E3
  chainloader /Windows/Boot/EFI/bootmgfw.efi
}

• Attempting to run Startup Repair from a bootable Windows 10 USB. Following this suggested answer, I booted into my Windows 10 installer USB, went to "Repair your computer", selected "Startup Repair.", and was told that Windows couldn't figure out what was wrong and was simply prompted to "Shut down".

At this point, I'm exhausted. I feel like I'm running in circles with what I'm finding online, and I can't really think of anything else that could work. I'm no expert with Linux; I'm half-decent at terminal stuff, but I don't have a good understanding of how these things work to try and fix it from nothing on my own. And even though Solus is lovely to use, it still has its share of issues I'm running into (albeit those are irrelevant to the big problem here), and I'd still really like to have a powerful desktop computer capable of running Windows so just abandoning my Windows partition isn't something I want to accept. Anything is appreciated, thank you so much in advance.

For reference if it helps, here's the output of fdisk -l that's relevant to my boot drive:

Disk /dev/nvme0n1: 476.94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: INTEL SSDPEKNW512G8                     
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x313ff715

Device         Boot     Start        End   Sectors   Size Id Type
/dev/nvme0n1p1           2048  499578836 499576789 238.2G  7 HPFS/NTFS/exFAT
/dev/nvme0n1p2      999153664 1000210431   1056768   516M 27 Hidden NTFS WinRE
/dev/nvme0n1p3      499578880  957210623 457631744 218.2G 83 Linux
/dev/nvme0n1p4      957210624  999153663  41943040    20G 82 Linux swap / Solari

Partition table entries are not in disk order.

Also, I'm pretty sure Windows would boot in legacy mode based on the output I found in setupact.log after following this guide to find it.

Answer 1

The guide you followed is for UEFI systems. Windows OSs tie the choice of boot method to the choice of partitioning system, so the fact that your disk is partitioned MBR-style (indicated by Disklabel type: dos in your fdisk -l output) means your Windows is going to boot in legacy BIOS style.

This basically means you'll have to fix three things in your /etc/grub.d/40_custom entry:

• Replace insmod part_gpt with insmod part_msdos.
• If the UUID on the search line refers to /dev/nvme0n1p1 partition, that's not where the Windows bootloader is. Modern Windows places it into the "system" partition that has partition id 27 - in your case, it is /dev/nvme0n1p2. Find out its UUID (with lsblk -o +UUID or blkid), then put it on the search line instead of the current one.
• Replace chainloader /Windows/Boot/EFI/bootmgfw.efi with chainloader +1. (That means: load the first block of the partition selected by the immediately previous search line, and execute it.)

After making these changes, run update-grub as root, and then try booting Windows again.

Reference: Windows 10/11 default partition layout on MBR-partitioned disks