Chris Murphy venit, vidit, dixit 2025-10-15 04:43:36: > > > 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.
Lennart answered to the raid1 part already, but let me stress something else: "And it's the same in Fedora.". No. As you point out yourself: it's the same in Fedora *server*. Some of us are old enough to remember what got us here: /boot size keeping users from upgrading because initramfs became too large. None of this is a concern to "group R" among those two: R) Reinstall or reprovision a new release U) Upgrade to a new release in place In an R-scenario, you reinsyall/reprovision if you need different partition sizes or something breaks. In particular, you don't need a rescue image. We do not get any further if "R-people" see R only and no R-benefits from a change that would help U-issues only - but those are why we are here. We do not get any further if "U-people" disregard or create U-issues, of course (not seeing much of that, though). But maybe (if I read Chris correctly) we have to admit that we cannot serve both well by the same solution, and that we need an R-solution and a U-solution. I mean, we have quite a few other things which are different between Fedora desktop and server installs already. The upshoot from everything said so far seems to be: R) No dire need and no interest in change (keep grub, /boot separate on ext4 (2, really) resp xfs). U) Work on a making future-proof solution practical for the normal desktop user (probably sd-boot on a vfat /efi). I'm fully aware that a new U) solution will need one reinstall, but that's the same with the current "solution" (1GB->2GB for /boot) which just buys time. As a first step, we need the alternative U-solution to be better accessible than by outdated change proposals and more up-to-date (?) forum posts, including secure boot of course. Michael -- _______________________________________________ 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
