Re: F29 System Wide Change: Make BootLoaderSpec the default

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

 



On 06/22/2018 03:35 PM, Chris Murphy wrote:
> On Fri, Jun 22, 2018 at 11:01 AM, Javier Martinez Canillas
> <javier@xxxxxxxxxxxx> wrote:
>> On Thu, Jun 21, 2018 at 11:19 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote:
>>
>> [snip]
>>
>>>>> OK anyway, I don't see broad BLS consensus forming yet, but I do see
>>>>> two items that aren't controversial and could move forward as part of
>>>>> this feature proposal:
>>>>>
>>>>> a. Consistent $BOOT/loader/entries for UEFI and BIOS where $BOOT is
>>>>> the ESP on UEFI, and $BOOT is "other" on BIOS (most likely the
>>>>> existing /boot ext4 volume currently used). i.e. do not put
>>>>> /loader/entries in /EFI/fedora
>>>> By "consistent", do you mean that both EFI and BIOS boot loaders will
>>>> reference the same entry files? I like that.
>>> Yes.
>>>
>>>> However, I don't like the entries existing on ESP mostly because of the
>>>> use case of md-RAID for /boot referenced in another thread. I think it
>>>> would be best to just put the GRUB EFI file on ESP and put the rest of
>>>> the bulk GRUB stuff in its utility partition (which may be RAID-ed).
>>> Right. The config + kernel + initramfs on traditional /boot can make
>>> use of software raid, depending on static one time proper
>>> configuration of each member drive's ESPs and now the ESPs never need
>>> to be touched and thus not sync'd.
>>>
>>> Whereas constantly changing the ESP, means we need some way to
>>> establish a master and rsync to the extras.
>>>
>> So the consensus seems to be to have the BLS fragments in
>> $BOOT/loader/entries even on EFI, where $BOOT is the boot partition
>> mounted on /boot. That will give us the following advantages as
>> mentioned in this thread:
>>
>> 1. The BLS will not be stored in vfat, so ostree could keep using
>> symlinks to do atomic swap of its /boot/loader/entries
>> 2. The ESP won't be modified on kernels install / removal, that will
>> make it easier for software RAID.
>> 3. There will be consistency on where the BLS fragments are installed
>> regardless of the firmware interface (EFI, BIOS, OPAL on ppc64le and
>> zipl on s390x will all use /boot/loader/entries).
>>
>> I've updated the wiki page to reflect this and we will also change the
>> implementation.
>
> $BOOT being non-vfat is a fairly substantial departure from either
> BootLoaderSpec, the original requires $BOOT be vfat, the mjg59 version
> require $BOOT be firmware readable. That is not a complaint, I'm just
> making an observation of the consequences. I'm personally on the fence
> when it comes to the merit of a shared $BOOT. It sounds like a good
> idea, but maybe it's specious?
>
> Just to give some people still hanging on to this thread a visual of
> the dilemma:
>
> Not Shared $BOOT <--------------------||---> Shared $BOOT
> md raid                                          vfat
> lvm, lvmraid                         udf
> btrfs                                ntfs
> LUKS
> F2FS
>
> By making it possible to put /boot/loader/entries on e.g. md or even
> lvm raid1 or btrfs raid1, that implies a /boot/loader/entries that's
> readable for very few bootloaders, and no operating systems other than
> Linux. So it is not a shared $BOOT design. And that is a big departure
> from the entire point of the BootLoaderSpec, which I think is a bit
> too rigid.  I think the spec would be better off presenting itself as
> a continuum from a highly sharable $BOOT, to one that has features
> that inevitably make it less sharable.
>
> e.g. Somewhere close to shared $BOOT would be udf or ntfs. Both have
> read support on all major OS's, and by GRUB. Both support symlinks and
> some other features of modern file systems that FAT lacks. But UDF
> gets the edge on Linux because we have kernel level support, whereas
> only FUSE support for NTFS.
>
> Syncing a share $BOOT without fancy Linux features (upper left list)
> isn't that hard, it just requires a big dose of political capital to
> get a service or daemon that most every distro is willing to support
> in their core components so that sharing $BOOT doesn't result in out
> of sync ESPs. That could be a supplement to BootLoaderSpec and
> possibly a feature of systemd. But to date, there has been no one
> willing to do that work.
>
> Anyway, I'm OK with all of the changes made so far. I think it does
> simplify things quite a bit for Fedora users, while not shutting the
> door on future standardization efforts. e.g. An option still available
> to Fedora users is $BOOT on ESP where ESP automounts via systemd gpt
> generator onto /boot - and you'll get /boot/loader/entries just like
> everyone else if you want to use systemd-boot.

What is the benefit to sharing $BOOT between different operating
systems/distros?

I'd like to point out that $BOOT doesn't have to be shared to dual-boot
multiple distros or benefit from other details of BLS.

Each installed OS that wants to use some derivative of BLS really *can*
just each have their own $BOOT and even use different bootloaders to
implement BLS. (bootloaders can be chained in BIOS, and they can exist
independently of each other in EFI)

The primary benefit I see to adopting BLS here is the drop-in
configuration and consistent syntax regardless of the implementing
bootloaders. The benefit to sharing $BOOT between operating systems
isn't obvious to me, and only introduces limitations such as this
filesystem one.
_______________________________________________
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/H5KLJIPCQTBJAR4DOOKU2YOL7SHVP35A/




[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