Hi,
Dual boot has been a pretty important use case for Fedora Workstation edition and the desktop spins.
There are final release criterion that apply to Windows and macOS (notably not Fedora itself or any other Linux distros): https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Windows_dual... https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#OS_X_dual_bo...
The subtle difference is the Windows release criterion requires the bootloader to also boot Windows, not just Fedora. So what this thread is about, is that. The installer can still install to free space. The problem is how to boot it afterward? For macOS, Macs have a built-in graphical boot manager, mactel-boot installs some things that enable the Mac firmware to see Fedora, and we boot that way, rather than via the GRUB menu. For Windows, we use a Windows menu entry in GRUB. That's the main problem.
Pretty much all recent Windows 10 pre-installed systems that have a TPM 2.0 chip and Modern Standby, are coming with Bitlocker enabled. This is Windows' software disk encryption. The gist is to use measured boot to verify the boot chain has not been tampered with. And if it hasn't been tampered with, the TPM will unseal the Bitlocker encryption key and you boot.
The problem is shim and GRUB as intermediaries results in measured boot failing. And the user sees a Windows blue screen asking for a Bitlocker Recovery key. My Lenovo Thinkpad (gen 7, circa late 2020) came with this preinstalled. And my understanding is it's required for Windows 11 preinstallations.
This problem is, per release criterion as currently written, a (conditional) blocker. It's conditional, because we don't yet know the scope of users affected. And also it's going to be too hard to fix in the Fedora 36 release cycle. https://bugzilla.redhat.com/show_bug.cgi?id=2049849
A work around is having GRUB set an NVRAM variable indicating the next boot should be Windows. That's an instruction to the firmware, so there's no intermediary, thus measured boot works. The next boot (from Windows) would boot Fedora again. GRUB can't get or set EFI variables yet. systemd-boot, meanwhile, will be supporting BootNext in their next release.
I posted an inquiry on the grub-devel list: https://lists.gnu.org/archive/html/grub-devel/2022-02/msg00072.html
Anyway, so far it's not clear to me that upstream GRUB has interest in making this work.
Still another work around is merely using `sudo efibootmgr --bootnext $windowsentry` and rebooting. Or what about the desktop restart dialog detecting the presence of Windows, by looking at NVRAM for an entry, and presenting an option to do a one time boot of Windows?
How important is this?
Chris Murphy wrote:
A work around is having GRUB set an NVRAM variable indicating the next boot should be Windows. That's an instruction to the firmware, so there's no intermediary, thus measured boot works. The next boot (from Windows) would boot Fedora again. GRUB can't get or set EFI variables yet. systemd-boot, meanwhile, will be supporting BootNext in their next release.
So, can we not, in GRUB, instead of chainloading the Windows bootloader, chainload a systemd-boot copy preconfigured to BootNext to Windows?
Kevin Kofler
On Wed, Feb 23, 2022 at 6:35 PM Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
Chris Murphy wrote:
A work around is having GRUB set an NVRAM variable indicating the next boot should be Windows. That's an instruction to the firmware, so there's no intermediary, thus measured boot works. The next boot (from Windows) would boot Fedora again. GRUB can't get or set EFI variables yet. systemd-boot, meanwhile, will be supporting BootNext in their next release.
So, can we not, in GRUB, instead of chainloading the Windows bootloader, chainload a systemd-boot copy preconfigured to BootNext to Windows?
No because systemd-boot isn't signed with a Fedora Secure Boot signing key, so on systems with UEFI Secure Boot enabled, they'd fail to load systemd-boot.
But also, this isn't an upstreamable solution, so the Fedora and Red Hat bootloader teams are unlikely to support it either.
On Thu, Feb 24, 2022 at 12:56 AM Chris Murphy lists@colorremedies.com wrote:
And my understanding is it's required for Windows 11 preinstallations.
Except if your country has required that TPM not be used, and as Microsoft did not want to prevent billions of people from using Windows 11 those locations are exempt from the requirements.
On Wed, Feb 23, 2022 at 05:56:14PM -0700, Chris Murphy wrote:
Hi,
Dual boot has been a pretty important use case for Fedora Workstation edition and the desktop spins.
It sounds to me like it is time to punt the problem to the firmware on UEFI systems. Make sure we don't clobber existing Windows boot entries or partitions and let the firmware sort it out. Most of my UEFI systems have a boot menu that will list the entries and let you easily select them. I'd rather do that than depend on some kind of half-boot linux reboot into windows thing.
Yeah, I know the firmware experience is inconsistent and terrible. But given the combination of TPM and bitlocker I don't see any other solution.
Brian