GRUB Continues Working Toward Its Next Release In 2025

[phoronix]

Phoronix: GRUB Continues Working Toward Its Next Release In 2025

As somewhat of an annual tradition for the FOSDEM conference, Daniel Kiper of Oracle presented a status update on the GRUB bootloader. As one of the GRUB maintainers he offers great insight to activity around this most common Linux bootloader...

https://www.phoronix.com/news/GRUB-Bootloader-2025

[Danny3]

Well FFS, when will the fix the major severity, security problem, with 1628 votes so far like the missing LUKS2 support???

https://savannah.gnu.org/bugs/?55093

They work on every crap, just to not solve this problem!

I'm really tired of having to make stupid EXT2 extra partition or LUKS1 partitions because GRUB is too stupid to just open the LUKS2 partition!

Also when will they fix the GRUB reboot into another OS so we can use it for one time only instead of the current situation where if you do that command, it will reboot permanently into that OS that you actually wanted to reboot into just once?

As for the that fucking 90's old default theme, can't they just make a default one like this?:

https://www.gnome-look.org/p/1009236

This is the one that I use and I've installed on computer friends for which I installed Linux + Windows and all of them were impressed.
But I'm honestly very tired to have to do it manually all the time on so many installations / reinstallations.

I'm really disappointed that a project that is used by more than 95% of the Linux distros has such core bugs and problems and aesthetics are completely ignored even after some people proved with themes some beautiful designs and not only beautiful but also more intuitive and understandable no matter the language because of the icons / logos of the OSes.

[Old Grouch]

GRUB2 does support LUKS2 formatted block devices.

However, it doesn't support the Argon2 key derivation functions, so while GRUB2 can be configured to read LUKS2 formatted block devices (I've done it myself), you are forced to use the older, supported, PBKDF2 function for key derivation. Many people find this less than optimal.
There are out-of-tree patches floating around to enable Argon2 support. But the GRUB developers are, as it says on the slide, working on updating libgcrypt to allow GRUB2 to support Argon2. This is non-simple work, as the current library is, to put it politely, non-standard. Look at the mailing list for details.

So, GRUB2 supports LUKS2-formatted block devices, but does not support the most popular key derivation function used with LUKS2. That depends on a tricky update of GRUB's implementation of libgcrypt, which is mired in technical debt.

The GRUB developers know this is a highly requested feature. What is needed is people/resources who can pay off the technical debt and get libgcrypt successfully updated. Shouting at people to work harder/faster doesn't help.

[varikonniemi]

sad to see they have not yet picked up bcachefs support

[Danny3]

Well I think I'm one of those people that find less than optimal to use LUKS2 without Argon2.
Thanks for explaining what is actually the problem here as I did not remember and understood other than LUKS2 missing!

I'm mean installing a Linux distro with manual partitioning + a LUKS2 partition is already a PITA and impossible to do for most people without reading / watching a tutorial with multiple steps and lots of typing. And after doing it once almost nobody can remember all those steps and typed commands.
If we go to all that trouble and then type a possibly long and complicated password at every boot, the it should be worth the hassle in security strength.
If GRUB developers know that this is a highly requested features why don't they prioritize is with their time and resources?
Because if they had the time to work on all those features they just announced, it looks to me like they didn't prioritized it at all.

I'm not shouting at them to work harder / faster, but I guess I'm shouting at them to stop ignoring major security problems.
Especially now since we live in such a shitty / uneducated / evil world which give people like Putin, Trump, Musk the absolute power and the governments keep trying to implement mass surveillance laws like SOPA / ACTA / PIPA / Chat control.
I bet a lot of journalist and activist and so many other people lives could be lost when a device get in the wrong hands in a country like China, Russia and who knows, in the future maybe Australia, UK, US too.
How come people lives matter so little for GRUB developers?
Or do we need to explain to them step by step how flaws and vulnerabilities in computer security can transform into problems with personal security of people, like how people could be maimed, tortured or killed depending on where they are, where they travel and what they have on their computer?
With Trump + Musk duo, don't you think that now it's a possibility that the US could quickly turn into an totalitarian / authoritarian country like China / Russia, at least when it comes to personal privacy and mass surveillance?
Isn't the Patriot act and shiitty abortion laws leaving women to die a bit of a hint that US might have some problems with education level and democracy level and people can be quicly made to accept whatever crap comes their way?

[Old Grouch]

sad to see they have not yet picked up bcachefs support

That's not simple.

GRUB2 file system drivers are exclusively read-only. This makes operating with journalled file systems potentially tricky, because most linux journalled file system drivers will replay the file-system journal when mounted read-only to deliver a file system in a consistent state. One can usually explicitly set a mount option when using linux file system drivers so that a journalled file system will not replay the journal on being mounted*, but that means you have no guarantee about file system consistency.
Adding a journal replay facility to GRUB filesystem drivers for any journalled file system would be difficult, so you need to be prepared to boot from a disk in an inconsistent state.

*For example, ext4 would need the 'noload' mount option, in addition to 'ro' - see kernel.org: ext4 General Information

ro

Mount filesystem read only. Note that ext4 will replay the journal (and thus write to the partition) even when mounted “read only”. The mount options “ro,noload” can be used to prevent writes to the filesystem.

[bachchain]

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

[billyswong]

sad to see they have not yet picked up bcachefs support

Another member here is already complaining they don't concentrate time and resources enough into implementing LUKS2/Argon2. Implementing an experimental filesystem will be in far far lower priority.

[HEX0]

GRUB2 does support LUKS2 formatted block devices.

However, it doesn't support the Argon2 key derivation functions, so while GRUB2 can be configured to read LUKS2 formatted block devices (I've done it myself), you are forced to use the older, supported, PBKDF2 function for key derivation. Many people find this less than optimal.
There are out-of-tree patches floating around to enable Argon2 support. But the GRUB developers are, as it says on the slide, working on updating libgcrypt to allow GRUB2 to support Argon2. This is non-simple work, as the current library is, to put it politely, non-standard. Look at the mailing list for details.

So, GRUB2 supports LUKS2-formatted block devices, but does not support the most popular key derivation function used with LUKS2. That depends on a tricky update of GRUB's implementation of libgcrypt, which is mired in technical debt.

The GRUB developers know this is a highly requested feature. What is needed is people/resources who can pay off the technical debt and get libgcrypt successfully updated. Shouting at people to work harder/faster doesn't help.

Maybe these days the demand for proper grub LUKS2 support is not as high. These days UEFI requires FAT32 unencrypted EFI system partition. Many for simplicity mount FAT32 ESP to unencrypted /boot and encrypt the root partition.

I used to run Legacy BIOS mbr with a single LUKS2 ext4 partition and had grub unlock it. And stored the keyfile inside initramfs to avoid double password prompt.

My current laptop doesn't even have CSM mode. So now I have systemd-boot fat32 ESP mounted on unencrypted /boot and the rest is luks2 ext4 root partition. Also using booster for fast initramfs generation.
I think as time goes on there's less systems that support Legacy BIOS CSM

[pWe00Iri3e7Z9lHOX2Qx]

I'm mean installing a Linux distro with manual partitioning + a LUKS2 partition is already a PITA and impossible to do for most people without reading / watching a tutorial with multiple steps and lots of typing. And after doing it once almost nobody can remember all those steps and typed commands.

Isn't that the distribution's job though? Users should just tick a box for encryption in that distro's GUI / TUI installer. The distro sorts out what that means in terms of LUKS settings and it just magically works for the user.