[systemd-devel] why does bootctl default to /boot and not to /boot/efi?

[Chris Murphy]

On Wed, Jun 1, 2016 at 2:46 AM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> Lennart Poettering wrote on 30/05/16 17:47:
>> hence an acceptable alternatively might be to
>> introduce /efi and mount the esp there, and simply not have /boot on
>> legacy free systems.
>
> This might be the pragmatic way to get this schema more widely adopted.
> kernel-install could be modified to detect which is used and copy the
> kernel to the appropriate directory (or copy it to both).
>
> I really like the ESP as /boot approach but it's hard to get people to
> buy into it :(

Well it's a non-starter for dual boot because the existing Windows and
OS X ESP's are too small to host kernels, and I'm not aware of any
installer that'll create an additional ESP or grow an existing one.

Next, it rather seems like rearranging the deck chairs. There's no
major advantage. The boot manager gets a bit smaller but now it's
mandatory to put the kernel and initramfs on the ESP, unlike any other
OS. You get to drop the 500MB ext4 /boot, but now you have to have a
500MB or possibly larger, FAT32 /boot, in order to hold 4 kernels and
initramfs's. When those initramfs's are the nohostonly or reproducible
variety, they're currently 50MB on Fedora 24. So
kernel+system.map+initramfs = ~60MB which is ~60x bigger than most
boot managers. And some use cases will want posix permissions and
xattr support, which is lacking on FAT; and still others that will
want the initramfs at least on an encrypted volume.

It think it'd be better to put an EFI wrapper around the GRUB fs
modules, so any UEFI boot manager inherits the ability to read
anything GRUB already supports: cryptoluks, mdraid, lvm, btrfs, xfs,
ext4, etc. No one actually needs to reinvent the fs wheel for each
UEFI boot manager.

But I do agree with the criticism of nested mounts, e.g. /boot/efi, as
well as persistently mounting the ESP, which is also

-- 
Chris Murphy