On Tue, Oct 14, 2025, at 1:14 PM, Simo Sorce wrote: > On Mon, 2025-10-13 at 23:37 -0400, Chris Murphy wrote: >> >> On Mon, Oct 13, 2025, at 2:19 PM, Simo Sorce wrote: >>> The difference is that Windows and Mac have a single file system todeal >>> with on their OSs, and likely qualification tests to ensure theboot-loader >>> drivers work correctly in all situations. >>> On Fedora we have several file-systems and that means the test matrixwould >>> have to cover them all and there is an explosion of driver tosupport in the >>> bootloader. >>> Which is why it would be better to simplify away this complexity bymoving >>> kernel and initramfs to a vfat filesystem (vfat because it isalready >>> required to read the EFI partition anyway) and have a singletested >>> configuration for this critical operation. >>> This avoids having to care for a lot of delicate code in grub as wellas >>> making it easier to replace it eventually (if someone wants to doit). >> OK. >> But then that's an argument to drop GRUB in favor of systemd, isn't it? > > No, not necessarily, but it would definitely allow the boot team to look at > that as an option.
Last time this came up (5ish years ago) they said no because it's too simple, doesn't support enough of RHEL's use cases. And that they had insufficient bandwidth for more work. And it's the same in Fedora. Fedora Server can't use systemd-boot or plain FAT only $BOOT, because they require support for /boot on mdadm raid1. Same with CentOS and RHEL. > >> (open)SUSE configures GRUB to boot from Btrfs whether encrypted or not. I'm >> pretty sure that code is being well exercised. Fedora does default to zstd >> compression, they do not, so there could be undiscovered decompression bugs. >> This too is a single file system, simpler. >> Fedora GRUB has supported Btrfs and zstd for a while. The installer permits >> it so long as it's plain, no LUKS. As well as EFI fs, ext234, xfs, f2fs, >> Btrfs, and mdadm. This is a lot to support from small boot loader and >> installer teams. > > Which is why we should simplify all of this away for the boot partition, less > options, less bugs, less problems. What bugs? What problems? How many bugs per year are we not going to have to deal with? Is that really worth the effort? How so you propose to get buy-in when the upside is a very hypothetical improvement in simplicity, which is also intangible to the user, but then take away their working use cases? Who is lining up to do this work? -- Chris Murphy
-- _______________________________________________ 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://pagure.io/fedora-infrastructure/new_issue
