On Tue, Jul 26, 2022, at 7:18 PM, Chris Adams wrote:
> Once upon a time, Chris Murphy <lists(a)colorremedies.com> said:
>> 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.
>
> Is GRUB upstream any more active these days?
It is but seems there's no interest in this particular issue.
I started a couple threads on this topic previously, but there's not much traction:
https://lists.gnu.org/archive/html/grub-devel/2022-02/msg00072.html
https://lists.gnu.org/archive/html/grub-devel/2022-03/msg00227.html
> IIRC Fedora has a whole
> pile of patches; I'm sure nobody wants the pile to grow, but it doesn't
> look like that's changing. Could this be implemented in Fedora's GRUB?
It's been cut down quit a bit actually. GRUB 2.06 cut the patchset around in half.
And GRUB 2.12 release is imminent, which will cut things down farther.
Since the Red Hat bootloader team is pretty swamped as it is, and has indicated it needs
to drop BIOS support (in favor of the newly minted BIOS SIG) soon, I'm skeptical the
bootloader team has at least the time to work on this, maintain it, and try to push it
upstream. Thing is, it really needs upstream to agree to it, because if it's not
upstreamed, what's the point? This is an issue that affects all distros and quite a
lot of users eventually, as Bitlocker by default becomes more prevalent. Maybe this issue
needs more visibility? Behind the handful of lists I've tried so far?
Time to ask Microsoft to approve a different stage-2 bootloader?
--
Sincerely,
Demi Marie Obenour (she/her/hers)