On Wed, Jun 1, 2016 at 2:46 AM, Colin Guthrie <gm...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel