On Di, 23.06.26 06:22, Neal Gompa ([email protected]) wrote: > > > 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.
You make it sound as if GRUB was just an abstraction layer. But it really isn't it brings file system drivers with it (of questionnable quality) for example, that it makes front and center of the boot process. It's hence not *abstracting* here, it is *reimplementing* something the firmware has anyway, and that cannot be removed from the boot process even if you wanted. Without what you are suggesting you have to deal with firmware's VFAT drivers. With what you are suggesting you *still* do, but now you have a second low-quality FS driver to care for: the one in Grub. What a shitty deal: you had one problem, now you have two. > 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. Your are making the system unnecessarily complex, while keeping file system drivers in the stack that are universally, … well …, "disprespected" for their quality. > > 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. You cannot avoid interfacing with EFI variables. They are a necessity of the platform we generally focus on. Yes, old firmwares suck, but you cannot ignore EFI variables, because they are simply inherently part of the boot process regardless what you do. > > 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. You are arguing for reimplementing the Linux storage stack in Grub? Jeezuz. It's hard enough for the Linux storage people to maintain that as part of the Linux kernel, and now you expect the handful of Grub maintainers to keep up with this in their own codebase? Are you serious? Lennart -- Lennart Poettering, Berlin -- _______________________________________________ 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
