On Tue, Jun 23, 2026 at 6:07 AM Gerd Hoffmann <[email protected]> wrote: > > Hi, > > > From the Fedora Cloud point of view, I am generally supportive of > > this. I would like to see other common filesystem modules re-added > > though (particularly btrfs, but it also probably makes sense to re-add > > xfs and ext4). I have had a todo item for a while now to discuss > > extending grub to s390x like the SUSE folks do for similar reasons. > > I'd rather see the fat driver removed and grub using > EFI_SIMPLE_FILESYSTEM_PROTOCOL instead. > > > Having a unified chain across all architectures that gives us a > > consistent set of features allows us to have focused integration > > points in userspace and develop failure mode handling that works > > regardless of the platform. > > That is IMHO an illusion. The boot loader can't hide the platform > differences. >
I didn't say anything about illusions. The point of GRUB is to provide a common layer regardless of the underlying platform. I still get a consistent feature set, I get a stable configuration target, and a universal way to detect platform differences and adapt to them. > Look, grub started as boot loader for x86 bios systems. That is > firmware with a very limited feature set. So grub brings its own > drivers for pretty much everything. And that history is still very > present today in the grub code base. > I know how these things started, I started with Linux using LOADLIN and later LILO and finally GRUB today. I'm not unfamiliar with how all this works. :) > UEFI arrived, with alot more features. grub continues to use its > own drivers, causing conflicts at times because both the grub driver > and the efi driver are active at the same time. Also grub completely > ignores features provided by the firmware. For starters the grubenv > file with all its problems such as grub needing write access to the > filesystem for updates IMHO doesn't make much sense on UEFI systems > because grub could store that data in EFI variables instead. > EFI variables are horribly broken in practice. I don't know if you happen to have perfect computers, but like half of my real-world test machines and two of my daily driver computers have either failed-with-success, non-writable, or otherwise non-functional EFI variables. And with fake/emulated EFI systems like U-Boot and whatnot, these things work even less well. As a general rule, I want to minimize the reliance on the firmware layer and jump into stuff we have as quickly as possible. > > And being able to leverage filesystem features to provide defense > > in-depth around data integrity is something David and I have been > > exploring and engaging with upstreams on as well. > > Why "filesystem features" and "data integrity" is something boot > loaders should have to care about? > Well, at least from GRUB's point of view, currently they don't, but in the future, it could. For example, if fsverity is "broken" on a file, then GRUB could refuse to read the file. This can even extend further with UKIs to halt the boot process. There are lots of opportunities to be smart early and do it in a way that provides a consistent experience. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
