On Tue, Jun 19, 2018 at 3:40 AM, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > The boot loader spec suggests that $BOOT and the ESP are the same > thing, and I am very sure this is the best and simplest approach for > all images that have no explicit reason to depart from that. However, > the spec does not actually require $BOOT to be the same as the > ESP. The freedom to make $BOOT != ESP was added as a compromise, > because some folks were adamant that resizing the ESP on multi-boot > systems should not be done (i personally don't think it's as big a > prob as people claim though...). It's effectively not possible because in every layout, from Windows to all distros, it's wedged in by other file systems. You literally can't resize it. All you could do is create a new bigger one, copy over the contents of old to new, and then wipefs the old one, and change the partition type GUID or remove the partition entry. I seriously doubt the installer folks want to take responsibility for such a thing, and update the various NVRAM boot entries accordingly. > > 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. 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. And the volume format for 0xEA / bc13c2ff... I don't know that it's possible to get consensus. But set that aside, it means the BLS file format needs a way to reference files on another volume. Assuming all paths are local doesn't seem workable except in the most narrow case, and always narrow casing this is what prevents it from being adopted. Windows, macOS, the various distros - they all have substantial differences in how they boot. But the one commonality I most consistently see? The bootloader teaches the pre-boot environment, right off the bat, how to read a real file system, and from that real file system the kernel and initramfs are loaded. >The boot loader can start the EFI shell and its > trivial to explore the contents and everything and manually boot any > kernel you like. This approach also means that no /etc/fstab entry is > needed, and thus things are a lot more self-sufficient and robust. > > It would be my assumption that all OS images generated in full by some > image builder would go for option #1, and option #2 would only be used > when a traditional installer such as anaconda is used that is supposed > to add a Fedora installation to a system that is already set up > otherwise, i.e. already has an EFI partition in place that is > considered too small. i.e. option #2 is the multi-boot-with-windows > usecase, while option #1 is for pretty much everything else. Flowchart that paragraph, it's a frigging maze. This is a Choose Your Own Adventure spec. This paragraph itself demonstrates the inconsistency, depending on what firmware you have, and what layout existed before hand. And that tells me there isn't enough abstraction that things are that variable and messy. I don't like the idea of asking users helping users, to have to be so familiar with such esoteric things. It makes support, repair, maintenance, upgrades, testing, documentation harder. There are too many exceptions. Just give up. The ESP belongs to the OSLoaders and a static configuration if needed, so that we can figure out where to jump to immediately to get the BLS snippets, the kernel, and initramfs. And make that location consistent no matter the firmware, no matter the prior layout. -- 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/XKMBS6GW7CWXWGAEBW7O6PXQXIBAACPH/
