On Mon, Jun 18, 2018 at 02:42:40PM -0700, Andrew Lutomirski wrote: > > On Jun 18, 2018, at 10:02 AM, Javier Martinez Canillas <javier@xxxxxxxxxxxx> wrote: > > > >> On Thu, Jun 14, 2018 at 10:20 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > >> On Thu, Jun 14, 2018 at 12:51 PM, Adam Williamson > >> <adamwill@xxxxxxxxxxxxxxxxx> wrote a monolithic config > > > > > > >> The cited BLS spec requires $BOOT be VFAT, are we doing that? > >> > > > > Yes for EFI systems but no otherwise. On EFI the BLS snippets are in > > /boot/efi/EFI/fedora/loader/entries and on non-EFI systems are in > > /boot/loader/entries. > > > > I think this is the wrong approach. I see no valid reason that the > paths should be different on EFI. Yeah, I think you've convinced Javier and I that we should just put the BLS fragments in /boot/loader/entries in either case. So that will probably happen next week sometime. > >> If there's no room on the EFI System partition for all of this, will > >> we following bullets 2 and 5 of the BLS spec under "The installer > > > > No, $BOOT is always the ESP where GRUB 2 is installed. > > I’m going to go out on a limb and make a stronger objection than > Chris’: I think that $BOOT SHOULD NOT be the ESP. The ESP is > problematic for any number of reasons. It’s usually vfat, so it’s > fragile. It does not support RAID safely. And it’s often small. > > Most of this can be solved by putting $BOOT on a different partition. > Stick it on mdadm 1.1 if you want RAID (*not* 1.0 or 0.9 due to > corruption risks [0]), and maybe even use a journaling filesystem that > the bootloader can *correctly* read. (That means the bootloader should > be able to parse the journal.). And make it however big you want. Yeah, I've never understood why some people seem to really want to use the ESP for anything that doesn't need to be read through the firmware's file I/O code. The only thing we really want to be loading from the ESP is the bootloader itself and some relatively static config data - basically, how to find /boot. For simplicity, I expect that means we'll make it be a grub.cfg that's generated once, and a grubenv file containing UUIDs and the like. Once we have most of this working well, I do intend on shipping an actual grub2-static-config package with a config file that isn't machine specific at all, but loads everything from bls, small config snippets (like grub-setpassword makes now), or grubenv, so you don't have to have grub-mkconfig or the other bulky tools installed at all on platforms that don't need grub-install. > As an extra plus, upgrading a kernel doesn’t require mounting the ESP, > which means that the bootloader installation can sync the ESP across > multiple disks and it will remain synced. Yeah, that's a thing you can do. > All that being said, $BOOT should not use security context xattrs — > getting that to work right across distros is probably impossible. Not to agree or disagree, but I'm not sure what of the above led you to say this part. > [0] I use mdadm a lot, and I never use 0.9 or 1.0. It’s too fragile. One caveat here (that's not particularly relevant to the broader conversation) is that you *can* make /boot and the ESP both reasonably redundant - obviously by using hardware RAID, but less obviously by using Intel's IMSM firmware RAID, because they made mdadm support it pretty well. But it's present on scarce few platforms in the world. -- Peter _______________________________________________ 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/SJYJ7LAK2CWOQEJYCT47EKXLKTOKZISI/
