I actually told Calamares to use /boot/efi, because it wasn’t happy about the other options.
Not sure if it wasn’t happy because my (EOS) partitions are LUKS, or because it was scared I couldn’t boot.
Telling GRUB to use the correct file didn’t helped.
But I just noticed it say’s “File « /EFI/… » non available.”, it doesn’t tell that it can’t find it, if that might help.
1 Like
Just to be sure, boot Windows and do Windows Key + R and type msinfo32, hit enter and check for BIOS Mode.
It’s UEFI.
It’s right then. While in Windows, open CMD and post the output of bcdedit
C:\WINDOWS\system32>bcdedit
Gestionnaire de démarrage Windows
---------------------------------
identificateur {bootmgr}
device partition=\Device\HarddiskVolume1
path \EFI\Microsoft\Boot\bootmgfw.efi
description Windows Boot Manager
locale fr-FR
inherit {globalsettings}
default {current}
resumeobject {043dd582-ff68-11ec-abdb-6c6a773bd18d}
displayorder {current}
{b0ca1a71-48a5-11ec-b1d7-6c6a773bd18d}
{106f4ec3-a0b4-11ec-ab59-6c6a773bd18a}
toolsdisplayorder {memdiag}
timeout 0
displaybootmenu No
Chargeur de démarrage Windows
-----------------------------
identificateur {current}
device partition=C:
path \WINDOWS\system32\winload.efi
description Windows 10
locale fr-FR
inherit {bootloadersettings}
recoverysequence {695b1b18-ff68-11ec-a432-e74ec878215f}
displaymessageoverride Recovery
recoveryenabled Yes
isolatedcontext Yes
allowedinmemorysettings 0x15000075
osdevice partition=C:
systemroot \WINDOWS
resumeobject {043dd582-ff68-11ec-abdb-6c6a773bd18d}
nx OptIn
bootmenupolicy Standard
Chargeur de démarrage Windows
-----------------------------
identificateur {b0ca1a71-48a5-11ec-b1d7-6c6a773bd18d}
device partition=C:
path \$WINDOWS.~BT\NewOS\WINDOWS\system32\winload.efi
description Windows 10
locale fr-FR
inherit {bootloadersettings}
restartonfailure Yes
isolatedcontext Yes
allowedinmemorysettings 0x15000075
osdevice partition=C:
systemroot \$WINDOWS.~BT\NewOS\WINDOWS
resumeobject {b0ca1a70-48a5-11ec-b1d7-6c6a773bd18d}
nx OptIn
bootmenupolicy Standard
I think I might also need to rename this topic, if I can. 
1 Like
I’m not sure what the proper path is? On my install it looks like the path is
/boot/efi/EFI/endeavouros/grubx64.efi
Same for me. At least for EOS install/drive.
Quite remarkable issue this one 
You might want to “turn the table” and create a boot entry for your Linux from Windows.
I know this is possible using the command line tool bcdedit but I don’t know the exact command line.
There are also GUI tools like EasyBCD.
The above is for your information. Do your own research before implementing any suggestion.
The responsibility for yor system is yours and only yours.
Alright, what’s the worst that could happen? x)
But I’ll do a image of the EFI partition, better safe than sorry.
Which disk do you have EOS, Windows and GRUB installed? GRUB is trying to access /dev/nvme0n1, I’m not sure if it should do that since the boot entries should be in /dev/sda.
The worst that can happen is that your data gets corrupted, and you can’t use your disk unless you format it completely. EFI boot entries are a pain to deal with if they get corrupted.
EOS’ GRUB is in /dev/sdb2.
Windows’ boot loader/manager is in /dev/nvme0n1p1.
It might sound a bit tedious but maybe the “safest” approach would be to skip os-prober and boot up into your other installs via bios’ one-time boot menu. And use Grub only for EnOS.
Only a suggestion.
I’m not 100% sure, but from what I understand GRUB creates a boot entry for Windows inside the EFI Partition for EOS, it works like that for me but I only use one drive, not different drives, so I’m not sure. Try to mount the EFI partition of EOS instead of Windows, and post the tree output.
EDIT: I think the situation is like this, may be, it’s detecting an old Windows boot entry (from an old installation) since it was detected before os-prober was enabled. I had a similar problem in which the BIOS detected old boot entries that didn’t point to anything. Removing all Windows entries and reinstalling Windows and EOS could solve the problem, but obviously it’s not the ideal solution. The ideal solution would be removing the entries and regenerating them both on Windows and EOS, so you don’t have reinstall Windows or EOS.
I would also clean up efibootmgr of all the entries that don’t need to be there taking up space. It only holds so many entries and then you run into problems.
EasyBCD works. Used it myself many times.
Great! Good to have confirmation!
I have known about it only by “hearsay” 
I just don’t understand how these issues happen? I have dual boot Windows with EndeavourOS installed on a separate SSD. I can install it either way using the Windows /efi or having the /efi created by the installer on the SSD and it detects and finds Windows and adds it to grub.