Re: F29 System Wide Change: Make BootLoaderSpec the default

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux