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 to > > deal with on their OSs, and likely qualification tests to ensure the > > boot-loader drivers work correctly in all situations. > > > > On Fedora we have several file-systems and that means the test matrix > > would have to cover them all and there is an explosion of driver to > > support in the bootloader. > > > > Which is why it would be better to simplify away this complexity by > > moving kernel and initramfs to a vfat filesystem (vfat because it is > > already required to read the EFI partition anyway) and have a single > > tested configuration for this critical operation. > > > > This avoids having to care for a lot of delicate code in grub as well > > as making it easier to replace it eventually (if someone wants to do > > it). > > 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. > (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. > > > Even if you dedicated 4GB (by default) for a boot partition in future > > installs that would be fine, these days disks are so huge that 4GB is a > > rounding error. > > Not everyone has big drives. There's a wide assortment of hardware Fedora is > supported on. As I mentioned you can still allow interested parties to edit the partition table and chose a smaller size, and if we reduced the amount of drivers to support in early stage we wouldn't even need that much space to start with. > > I had boot loading broken half a dozen times over the years and 100% of > > the times it was because dracut built a broken (in some minor but > > significant ways) initrd image. That is not fun and is an entirely > > preventable state. > > It would be interesting to tally up all our boot problems and complaints. > What would it tell us? That the stack is unnecessary complex, and it is so for no good reasons in most cases. A lot of the complexity is inflicted by "just because I can" reasoning. > Even if boot failures are rare, they're varied. We can't make it perfect. But > right now the way we fail to boot is a pretty bad UX. If it's early enough, > before root mount, the user drops to a dracut shell. But in many cases, > /etc/passwd is read and then there's a failure - and because root user has no > password set by default, the user is stuck. They are required to login as > root, but without a root password they can't. Pretty suboptimal. We can't > even give them good advice how to get the rdsosreport.txt off the system in > order to help them troubleshoot - that's how stuck. If we could greatly simplify the boot process we could probably much more easily provide a rescue mode that can operate in somewhat sane manners to better help users. Lot's of things can still go wrong, there is no perfect solution, but perfect is the enemy of good and I want good not perfect. -- Simo Sorce Distinguished Engineer RHEL Crypto Team Red Hat, Inc
-- _______________________________________________ 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
