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/
