GRUB Continues Working Toward Its Next Release In 2025

[ayumu]

GRUB really needs to shift focus to having first-class support for RISC-V if it wants to survive.

[intelfx]

That's not simple.

Not really.

Far as I can remember, bcachefs is very flexible and pliable when it comes to recovery options, and it supports in-memory replay as a first-class citizen. And with the extent of code sharing between Linux kernel and bcachefs userspace tools, there's really no excuse to not have this support other than nobody taking time to.

(Now, I'm not saying someone ought to pick up his arse right now and do it; this is free software after all, but I don't think there is any kind of inherent technical problem.)

[S.Pam]

With UEFI it seems unnecessary to have the full GRUB. I use rEFInd won my own system which works well. For security, I guess unified kernels or signed kernel+initrd should be enough. Then deal with luks and drivers from initrd.

[DMJC]

Everyone whining on here, go pick up a project and dev on it. Development is hard, it's getting easier thanks to AI but it still takes time and skill to put together working code. Most of the FLOSS world is held together with gum, ductape and shoe strings. If you don't like it, either hack on it, or submit bug requests/debugs.

[Azpegath]

Haven't used grub in years. refind with discoverable partitions is great.

Same here, I'm so happy with the switch to refind. Quick, easy to maintain, looks good, etc.

[Setif]

Will they support HiDPI displays?

[elatllat]

LUKS2 support? GRUB can't do LUKS1 without using 100% CPU while waiting for a password.

[S.Pam]

LUKS2 support? GRUB can't do LUKS1 without using 100% CPU while waiting for a password.

Does that matter?

[Old Grouch]

Not really.

Far as I can remember, bcachefs is very flexible and pliable when it comes to recovery options, and it supports in-memory replay as a first-class citizen. And with the extent of code sharing between Linux kernel and bcachefs userspace tools, there's really no excuse to not have this support other than nobody taking time to.

(Now, I'm not saying someone ought to pick up his arse right now and do it; this is free software after all, but I don't think there is any kind of inherent technical problem.)

Remember that GRUB does not use linux kernel filesystem drivers, for the simple reason that GRUB is not running a linux kernel. Neither does GRUB use linux libc. It's not simple code-sharing.

You can use linux FUSE to run the GRUB filesystem drivers (which are strictly read-only) via grub-mount, but there is no equivalent going the other way - although if you have a FUSE driver, it is probably possible to hack it down to work in GRUB as a module loaded by the GRUB command insmod. Note that EFI filesystem drivers can be produced from the GRUB filesystem drivers - see GitHub: EfiFs - EFI File System Drivers.

Further reading:
StackOverflow: GRUB2 and a custom File System
OS DEv.org WIki: Writing GRUB Modules
GitHub: koverstree/bcachefs-tools: bcachefs fusemount hangs on file write #171

[kpedersen]

I'm sure the Red Hat "leeches" will benefit from Oracle's hard work for free, right avis?