We have two storages (e.g., SSD): /dev/sda and /dev/sdb.
Install Windows on /dev/sdb (so it creates its own ESP);
Install Linux on /dev/sda (so it creates its own ESP), with a normal/manual partitioning:
- /boot/ (for Kernels I have 4 GiB+);
- /boot/efi/ (commonly, from 128 to 512 MiB is enough);
- Here I normally also have a swap partition, and separate: /home/, /var/;
- Select Grub to be installed on the /dev/sda;
Boot the Grub in /dev/sda;
Update Grub within Linux, so it finds the Windows EFI on another drive via its os-prober.
Here, I believe efibootmgr should show the existing EFI, or you could check it manually in /boot/efi after.
Windows should operate on its own ESP it created on its own storage, and don’t overwrite the Grub.
At voila!
Then Windows will fuck up your EFI entries. Which is not a big deal if you know what you are doing but a completely different story for the audience you are explicitly addressing here when you even explain how to check those entries in the first place.
Also you did not actually mention that fastboot needs to be disabled in Windows, thus a clueless person will not understand the random hardware errors on Linux caused by not properly initialized devices and will blame Linux.
(And let’s not even talk about some of the really insane stuff like pre-installed Microsoft SecureBoot keys that brick you whole system when removed because idiotic OEMs signed their own hardware’s EFI drivers with the keys already pre-installed just because they can…)
So no, it’s not “quite odd to see so many people having the issue when Windows”. That’s what Windows is causing, often intentionally so. Is most of this easily fixable? Sure… But it’s a very effective deterrent for many people, so they never reach the point where they understand and be able to fix that stuff.
Windows never touched the main EFI entry in my cases, even at updating it from 10 to 11, and I clarified it 3 times.
With a few Google queries we may find it mentioned, yet I’ve just found a weak one at this moment:
If you are booting with Windows, you should simply be aware of the problem, because you can easily overcome it by temporarily changing the type code of the non-Windows ESP(s) if you run into problems. Note that Windows will boot just fine on a disk with multiple ESPs; it’s just the installer that chokes on such disks.
Some documentations found mentioned relatively similar:
The only Microsoft supported workaround for booting multiple installations of Windows in a uEFI environment is to use a dual boot configuration. This will make use of a single ESP and one MSR while still allowing the user to choose to boot to an installation on disk 1 or disk 2.
Note that Windows will boot just fine on a disk with multiple ESPs
Nice for Windows to support this theoretically but the UEFI standard does not require support for multiple ESPs on a disk, so you will easily find hardware that in fact will simply discover the first ESP then stop. Because actual implementations matter and a lot of them are bad.
Speaking of bad implementations. We got several manufacturers a few years ago where their UEFI implementation broke and bricked the whole device after editing the EFI entries via efibootmgr exactly as defined by standard. Oh, you wanted to install Linux? Your device is now done because no one ever tested them without anything but the Windows pre-installs.
Yet two other cases of totally coincidental “This should work but doesn’t, must be a Linux issue” artificially created by Microsoft (who after all were one of the driving forces behind UEFI development, also the reason we are still stuck with FAT32 ESPs - the only file system ESPs are required to support by the standard with everything else optional).
Windows never touched the main EFI entry in my cases
In the end positive anecdotal experiences don’t matter much. If a relevant fraction of users has issues that should not exist when installing Linux (and that obviously don’t exist with Windows because here OEMs actually do proper testing here… or it’s Windows/Microsoft itself causing the issues (pre-installed key, fast boot shenanigans, hardware that should be supported but randomly isn’t etc.)) that’s helping to prevent a lot of people from trying it in the first place. And that’s by design.
Then Windows will fuck up your EFI entries. Which is not a big deal if you know what you are doing but a completely different story for the audience you are explicitly addressing here when you even explain how to check those entries in the first place.
Also you did not actually mention that fastboot needs to be disabled in Windows, thus a clueless person will not understand the random hardware errors on Linux caused by not properly initialized devices and will blame Linux.
(And let’s not even talk about some of the really insane stuff like pre-installed Microsoft SecureBoot keys that brick you whole system when removed because idiotic OEMs signed their own hardware’s EFI drivers with the keys already pre-installed just because they can…)
So no, it’s not “quite odd to see so many people having the issue when Windows”. That’s what Windows is causing, often intentionally so. Is most of this easily fixable? Sure… But it’s a very effective deterrent for many people, so they never reach the point where they understand and be able to fix that stuff.
Windows never touched the main EFI entry in my cases, even at updating it from 10 to 11, and I clarified it 3 times.
With a few Google queries we may find it mentioned, yet I’ve just found a weak one at this moment:
Some documentations found mentioned relatively similar:
Nice for Windows to support this theoretically but the UEFI standard does not require support for multiple ESPs on a disk, so you will easily find hardware that in fact will simply discover the first ESP then stop. Because actual implementations matter and a lot of them are bad.
Speaking of bad implementations. We got several manufacturers a few years ago where their UEFI implementation broke and bricked the whole device after editing the EFI entries via
efibootmgrexactly as defined by standard. Oh, you wanted to install Linux? Your device is now done because no one ever tested them without anything but the Windows pre-installs.Yet two other cases of totally coincidental “This should work but doesn’t, must be a Linux issue” artificially created by Microsoft (who after all were one of the driving forces behind UEFI development, also the reason we are still stuck with FAT32 ESPs - the only file system ESPs are required to support by the standard with everything else optional).
In the end positive anecdotal experiences don’t matter much. If a relevant fraction of users has issues that should not exist when installing Linux (and that obviously don’t exist with Windows because here OEMs actually do proper testing here… or it’s Windows/Microsoft itself causing the issues (pre-installed key, fast boot shenanigans, hardware that should be supported but randomly isn’t etc.)) that’s helping to prevent a lot of people from trying it in the first place. And that’s by design.
Thank you, heartfelt, for a more experienced, informative, and great response, with more details to learn from!