That’s very likely the problem. While grub2 can use “btrfs”, it can be confused by the subvolume structure.[/QUOTE]
I’m doing something similar, though I mostly avoid “btrfs”. And I do use UEFI booting. However, how you boot is pretty much dependent on how Windows boots. My UEFI box does not use Windows, and my Windows 7 box uses legacy booting.
I’ll describe what I do. Whether that’s helpful for you, that I cannot guess.
I partition first before any linux install. So my installs all use existing partitioning.
For grub booting, I try to set it up so that no matter which controls the boot, that system can boot all of the others. For that, I use “/etc/grub.d/40_custom”, where I add entries to boot each linux system.
Here’s a typical entry:
menuentry "configfile for openSUSE Tumbleweed on /dev/sdb2" {
set bootdir='hd2,gpt2'
search --label --set=bootdir boot1
configfile (${bootdir})/grub2/grub.cfg
}
If you are using “btrfs”, you might need to add a line for “insmod btrfs” when the system being booted uses that. Put it before the “search” line.
You will notice that I am using a search for label. Previously, I used search for UUID. But the trouble is that the UUID changes on a reinstall. Since I can set the label myself, I can avoid that problem with labels.
When I boot a different linux system, I use the “configfile” line for that system. This brings up another layer of menu. The advantage is that on a kernel update, the second level of menu should know which is the latest kernel. That’s because the kernel install normally updates the menu for that linux (which becomes the second level menu).
You can omit that “set bootdir=” line. It’s just gives a fallback if the search fails. And it is hard to get it right. How grub numbers your disks may depend on the hardware and BIOS.