On Tue, May 9, 2023 at 8:09 AM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > On Tue, May 09, 2023 at 12:02:26PM +0200, Gerd Hoffmann wrote: > > Hi, > > > > > If we want to change the default here, let's do some proper cleanup: > > > 1. the split between ESP and XBOOTLDR is only useful in the case where > > > ESP already existed and was small. If the installer is *creating* > > > an ESP, it should just make it large enough. > > > > And install kernels to /boot/efi in case /boot is not a XBOOTLDR > > filesystem? > > If /boot is not a XBOOTLDR, then we only have one file system which is > the ESP. It could be mounted on /boot or on /efi or maybe even /boot/efi (*). > The kernels would then go to /boot/EFI/Linux, /efi/EFI/Linux, or /boot/efi/EFI/Linux, > respectively. (When you write /boot/efi, it's not clear what exactly you > mean. The duplication of "efi" and "EFI" on on case-insensitive system > is confusing.) > > (*) This is actually something that'd need to be figure out. > /boot/efi is the worst choice; either /boot or /efi would be OK, > but something needs to be chosen. > > > > 2. having a second partition with a second (different) file system > > > implementation just increases the footprint and attack surface for > > > no gain. If we create XBOOTLDR, make it like the ESP (i.e. VFAT > > > in almost all realistic scenarios). > > > > While being at it also give the XBOOTLDR the correct type uuid according > > to the discoverable partitions spec. > > Of course ;-] > I've been asked to consider converting /boot to a Btrfs subvolume so that it no longer has a fixed space allocation to deal with the ever increasing amount of firmware required for NVIDIA GPUs[1]. This is currently incompatible with how systemd views the world, because the "discoverable partition spec" is wired to partitions, and there is no equivalent spec for subvolumes of a volume. And I imagine that XBOOTLDR (whatever that is) also would have a problem with this. Also, as an aside, there is now a "from-scratch" Btrfs EFI driver in development[2] (and for your personal horror, an NTFS one too[3]). [1]: https://pagure.io/fedora-btrfs/project/issue/7#comment-855321 [2]: https://github.com/maharmstone/btrfs-efi [3]: https://github.com/maharmstone/ntfs-efi -- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue