On Mon, Jun 18, 2018 at 3:42 PM, Andrew Lutomirski <luto@xxxxxxx> wrote: >> On Jun 18, 2018, at 10:02 AM, Javier Martinez Canillas <javier@xxxxxxxxxxxx> wrote: >> 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. I don't like it either but I'm trying to keep an open mind. What I recall from the conversations years ago with the mgj59 variant, it's a lot easier to poke holes in any attempt to standardize bootloading, than to standardize bootloading. But if no one is willing to give any ground anywhere, it's way too easy to stop progress. The proposed change doesn't really fix any of the user facing problems, it just gets us away from depending on grubby and grub-mkconfig (we never really depended on grub-mkconfig, the installer uses it as a one shot). So in the most narrow sense, the change succeeds at doing the only thing it's intending to do. But yeah, I lament that we're not being more aggressive while we have the chance to fix past oversights. > >> >> >>> 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. Well as it turns out all the file systems are fragile as far as the bootloader is concerned :-P We've got bugs where the bootloader can't read needed files, because part of the commit is still in the journal rather than fully flushed out to file system metadata. So no matter what you can break a set up... > 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. Getting journal support in the bootloader isn't going to happen. I've already talked to the various fs upstreams about it. > 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. But *le sigh* we have fwupd which wants /boot/efi mounted I use 'umask=0077,shortname=winnt,nofail,noauto,x-systemd.automount' in fstab for /boot/efi and yet every boot: Jun 17 14:07:06 f28h.local systemd[1]: boot-efi.automount: Got automount request for /boot/efi, triggered by 2268 (fwupd) So add that to the list of packages that need an ESP syncing daemon if they don't want to be responsible for dynamically mounting and umounting the ESP. > All that being said, $BOOT should not use security context xattrs — > getting that to work right across distros is probably impossible. It's a good point. I'm not really sure how to prevent conflicts if there is to be a truly shared $BOOT unless it is a file system that will reject xattrs. -- 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/L4K3FPKNIVFQSLKCRZJ4NGXFTITKZKWZ/
