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/
