On Tue, May 9, 2023, at 8:08 AM, Zbigniew Jędrzejewski-Szmek 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. Related but slightly off topic... What about the increasing growth in linux-firmware and in particular the NVIDIA firmware requirements? My reading suggests it's significant and the future growth also significant. There's some preference to put /boot on Btrfs to take advantage of storage pooling so that we're neither over nor under provisioning the size of /boot. The problem I have with this is two fold: what about our non-btrfs use cases? Surely those use cases are equally concerned about this problem? And then what are the impediments to booting the kernel faster and more quickly getting `/` mounted? Why is there so much pressure to stuff the firmware blobs into the initramfs or onto /boot in general? Why does firmware availability need to happen so early during boot, and is it really not possible to somehow make mounting `/` a higher priority than it has been up until now? Huge universal initramfs will slow down boot. And it delays mounting `/`. So if there is some good reason why firmware blobs need to be available soon, it's in direct opposition to booting fast and that strikes me as a design flaw or need for a feature request. I just don't know what that could be. But to just keep stuffing more things into the initramfs doesn't scale either. Back to the original topic: ESP and XBOOTLDR are not user domain, should have no user facing configuration in a GUI at all. It's irrelevant esoteric knowledge that 99% of our users do not need to worry about. By extension, they don't belong in /etc/fstab nor should they be persistently mounted. Whether one or the other are temporarily mounted to /boot, /efi, /boot/efi, is up to the developers creating tools that modify these volumes. I prefer that they are mounted to a pseudo-random location in /run but I don't really care. NOTE: We can apply SELinux labels to FAT file systems by using 'mount -o context=' mount option. The limitation is the label applies to that entire mount point, you don't get per directory labels, it's a one size fits all. Recent Windows 10/11 images on microsoft.com within the last year produce a 100M EFI System partition per: https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions?view=windows-11 I have reinstalled Windows 10 and 11 using the microsoft.com procured installer as of a year ago and it likewise creates a 100M ESP. Maybe Microsoft didn't get the memo and the space requirement is really something the OEM's are concerned about? So I expect this problem is not only our problem to solve. -- Chris Murphy _______________________________________________ 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
