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/co...
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