On Tue, Jul 26, 2022 at 4:07 PM Kevin Kofler via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> 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? _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
