Re: F29 System Wide Change: Make BootLoaderSpec the default

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

 



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.

-- 
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/TKFDVPRTCL737REDIQ5TZN7AQH3ZXE3M/




[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