On Mon, 2025-10-13 at 12:44 -0500, Neal Gompa wrote: > On Sun, Oct 12, 2025 at 4:19 PM Casey Jao via devel > <[email protected]> wrote: > > > > > macOS and windows are not a good example. Those systems effectively > > control the full stack and dictate what is supported and allowed, > > starting at the firmware level, through the boot loader, the OS, the > > file systems, etc. This is very different from us, where we support > > a wide range of machine types and have to work with the firmware written > > with the primary goal of supporting _other_ operating systems. > > > > This may be true for MacOS but Windows boots from the same UEFI firmware > > that boots Linux systems. Windows faces the same hardware diversity that > > Linux faces. And the last time I checked, Windows allocates a mere 100mb > > for the EFI system partition[1]. Everything else is NTFS. What is Windows > > doing right? > > > > [1]https://www.terabyteunlimited.com/kb/kb-articles/standard-windows-10-partitions-for-mbr-gpt-disks/ > > We do it the same way Windows does: the bootloader includes filesystem > drivers. ReactOS does the same thing[1] as does Quibble[2]. > > Incidentally, macOS does the same thing: their boot chain includes > APFS drivers on x86 for older Intel Macs. > > > [1]: > https://github.com/reactos/reactos/tree/master/boot/freeldr/freeldr/lib/fs > [2]: https://github.com/maharmstone/quibble
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). The value here is reduced complexity and simplification which generally leads to more robustness. 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. That said if SimpleDRM should be used and therefore smaller initramfs images that would also be a plus (and allow smaller boot partition defaults). SimpleDRM goes in the same direction of reducing the complexity of the boot code, making it easier to test, and avoiding bad situation where what's on disk and what is in the HW do not agree (for example because you had to replace your motherboard and suddenly the initramfs on disk is not great any more because the integrate GPU has changed). In fact, the ideal situation is that we simplify as much as possible both the boot partition and the initramfs to the point where we can achieve unified kernel images that are built by the distribution so they can be signed for Secure Boot. And leave all the custom driver loading as much as possible to after the boot process pivots to the real kernel. Custom initrd images should become the exception and not the rule. This would also greatly improve the robustness of the boot process in general. 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. HTH, Simo. -- 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
