On Tue, Jul 26, 2022 at 4:07 PM Kevin Kofler via devel
<devel(a)lists.fedoraproject.org> wrote:
Chris Murphy wrote:
> a. Fix GRUB by giving it the ability to modify UEFI NRAM "bootnext"
value,
> so that instead of chainloading the Windows bootloader from GRUB, GRUB
> will modify the system NVRAM such that the next boot (only) will directly
> boot the Windows bootloader. Thus far there's no interest by GRUB
> upstream. Whereas systemd-boot has implemented it.
As I already mentioned the last time this has come up: Why can we not,
instead of chainloading Windows directly, chainload a systemd-boot
configured to always bootnext to Windows? GRUB would still think it boots
Windows directly. (I do not see why it would notice any difference, all that
would change is the name of the image that gets chainloaded.) And systemd-
boot does not need to know that it is being chainloaded from GRUB. So I do
not see why that would not work, without any changes to the software.
Kevin Kofler
Why wase the cycles trying to outsmart TPM? Why not use a virtualized
Fedora in a VM on the Windows box, or vice versa, instead of
continuing to burn cycles on what has been a long running source of
instability and incompatibility on new hardware and with new
bootloaders? If there were anyone actually working on improving the
upstream BIOS to handle dual-booting better, I might see it. But I
don't see hardware vendors pusuing this. Do you?