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

[Chris Murphy]

On Thu, Jun 2, 2016 at 4:34 AM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Wed, 01.06.16 19:53, Chris Murphy (lists at colorremedies.com) wrote:

>> 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.
>
> I never had a problem with that. On my system Windows 10 allocated
> 256MB for the ESP and I only have 85 MB of that used with two
> kernels. It's a vendor-installed Windows (Lenovo).

And on Dell's it's 100MB. Windows itself has no say in the matter.
Most Windows "installations" are imaged by the OEM, not with the
Microsoft installer. But if you go download an eval copy of Windows
Enterprise either version 8 or 10, that installer creates a 99MiB
(literally, according to gdisk) ESP.


>
>> 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.
>
> On my Fedora 24 they are ~30M each.

If it's an upgrade from a previous version of Fedora you're probably
not running into a new behavior in Fedora 24 where all the initramfs's
are nohostonly. 30MB sounds like a hostonly initramfs to me.

On a new Fedora 24 (prerelease) installation, /boot consumes 142MB
with two copies of the kernel and two initramfs. Since one set is
rescue, this is actually just 1 kernel against the dnf
installonly_limit of 3. So that means /boot is expected to hold five
kernels and initramfs's simultaneously. Upon five being there
successfully, one is deleted to maintain the limit of 3 plus rescue.

So in no possible realm does this fit onto a 100MB ESP where Windows
uses 26MB of that.

And on a 256MB ESP, it might work it might not. Perhaps it will today,
bu it probably won't in the near future.


> Which means at the Windows default
> of 256M, and 25M of that used by Windows I can still install ~5
> kernels or so...

By stuffing the ESP to 91% of capacity, OK. FAT is so well known about
that it's one of those file systems where we got the "my god man,
whatever you do don't use more than 80% of free space!" advice. The
TPM stuff being worked on is going to necessitate a reproducible
initramfs and near as I can tell it's as big as a nohostonly
initramfs.


>> 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.
>
> sd-boot certainly requires none of that.

Sure but does it support any of that even if the pre-boot environment
understands those on disk formats via GRUB fs modules being wrapped as
EFI drivers, such that the kernel and initramfs can exist on something
other than the ESP?



-- 
Chris Murphy