On Wed, Jun 20, 2018 at 8:35 AM, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > On Di, 19.06.18 11:17, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) wrote: > >> > Today, systemd has this generator that will automatically find the ESP >> > for you and mount it to /efi or /boot. The idea behind that is that >> > installers can choose whether they want to merge $BOOT and the ESP or >> > not: >> > >> > 1. If they are merged, then the ESP (and thus also $BOOT) is mounted >> > to /boot, automatically by the generator. No other preparation is >> > needed, and /efi does not exist. (Distros could even make /efi a >> > symlink → /boot, but I personally wouldn't bother). >> > >> > 2. If they are not merged, then the ESP is mounted to /efi, >> > automatically by the generator. And /boot would be mounted as $BOOT >> > via an /etc/fstab entry added by the installer. >> > >> > And as mentioned, I'd generally recommend everybody to go for option >> > #1 because it is a lot simpler, and EFI has trivial access to all >> > kernels and such. >> >> Except, it's not simple for installers to migrate to a new bigger ESP >> in the dual boot case. And having different layouts for UEFI and BIOS >> and whether there's dual boot or single boot, isn't simpler. > > Again, if you don't want to resize the ESP, then go for option #2 > above. But if the ESP is usable, then go for option #1. In 100% of the cases where the ESP already exists, it is too small to share. No one. Not Apple, not Microsoft, not Windows OEMs, not Fedora, not any distro, creates an ESP bigger than 550MB. Typical is 99MB for the Microsoft installer (I have a laptop partitioned by Microsoft's install, not an OEM installer, and it's 99MB), and 128MB for Apple, and 200MB for Linux distros. None of these are big enough to share. And the ESP partition is wedged in, again in 100% of cases. It can't be resized in place. Therefore, Option #2 will be extremely common. What percent of Fedora users dual boot? I have no empirical data. I'd guess 1/2. And in my opinion, it's not simple to say: OK if you have this size ESP to start, you get this layout, and if it's bigger you get this other layout, and if it's BIOS you have this 3rd layout. And now we have to document all of this, and train the installer, and openqa, and all the people who help others out with their problems on #fedora and Ask Fedora and users@. I understand it, and I think it's a clusterfuck of complication. I can only imagine the end user confusion, people who actually just want to get shit done. It is possible to just ignore the ESP by treating it pretty much the same as the MBR gap and BIOS Boot. And have one layout for all three cases. That's simple. > >> If $BOOT is defined as where non-static bootloader config + kernel + >> initramfs goes, and if shared $BOOT is a good thing for Linux distros, >> then the $BOOT to always create is type 0xEA / bc13c2ff... and not >> conflate it with the location for the bootloader binaries: the ESP on >> UEFI, and either MBR gap or BIOSBoot on BIOS. > > Well, I am pretty sure legacy-free systems should not be bothered by > having two partitions for that. That just complicates stuff. No, it really doesn't. The *standard* Fedora installation today already has two partitions for that, ESP and /boot. You have to decide which is more important. Broad adoption, which will require equal doses of compromise and simplicity. Or narrow adoption. The BLS, as it is today, is barely even narrowly adopted, let alone broadly adopted. And in my opinion it's because it's neither simple, nor does it compromise. And as Fedora is right now looking to implement BLS, what did they actually do? Adopt the BLS file format and drop in concept, and abandon the other 90% of the spec by punting. I'll tell you what. Maybe consider a general purpose layout and a simplified layout. The typical layout represents a compromise no matter the firmware, and no matter what OS is already present - your option 2. This would be used for workstations, and any case where dual or multiboot is expected. And for things like Fedora VM images, IoT, possibly server, possibly ARM - where the sharing aspect of $BOOT is not expected or a consideration, go with the simplified layout - your option 1. *shrug* >I mean, > adding some minimal kludges to support Windows-cross-boot is fine, but > adjusting everything with that case in the center of everything is > quite wrong. It isn't just Windows. It's macOS. It's all other Linux distros. > Also note that we put together the boot loader spec with systemd-boot > as our implementation of it, as a reference implementation if you so > will. systemd-boot is a very simple, straight-forward boot loader, > that adds a few things missing in UEFI itself, and doesn't contain > code for parsing partition tables or file systems, for searching for > devices and so on, like grub does. It implements the spec, but > explicitly doesn't support splitting $BOOT and the ESP. I am pretty > sure we as the spec authors should keep our implementation and the > spec aligned. It has the appearance of setting the spec to a bootloader, rather than setting the spec to solve broad problems, get broad support, and have a shared $BOOT among the distros. As it is right now, it ignores enough relevant use cases, that it can't go anywhere it already isn't being used. As it is right now, it will never grow its market acceptance. And you can certainly have one spec, that has two use cases: general, and simple. And the systemd-boot can be the reference implementation for the simple use case portion of that spec. And the general purpose portion *might* have enough merit with shared $BOOT to get the interest of the distros. But maybe they don't care about that, so far they all seem to treat stomping on prior Linux distros as a competitive sport. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/PWDV27SSQUXOSI5DHSGV4UOLB2FN2J4U/
