> On Jun 18, 2018, at 3:54 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > 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. > > And that's fine, as long as it's not done in a way that makes it harder to improve in the future. >>> >>>> 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... > ... > > Getting journal support in the bootloader isn't going to happen. I've > already talked to the various fs upstreams about it. > Why are you talking to the fs upstreams? The problem is a bug in GRUB, full stop. All this freeze crap that Fedora does is just papering over the bug. IMO the right thing to do is to get *GRUB* upstream to have a fully functional implementation of *one* widely-supported fs. Hmm, GRUB supports F2FS, and F2FS is log-structured, right? So I don't see how GRUB could fail to read a dirty filesystem correctly even if it wanted to. Or someone could design a very simple, highly reliable, filesystem designed to make it easy to do atomic-enough updates and to read reliably. Think VFAT-like but with a full atomic swap of all FS metadata. Or a dead-simple log-structured FS. /me ducks. Seriously, though, F2FS might be a fantastic choice for this purpose. > >> 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. I disagree. fwupd doesn't need any ESP syncing. In the very worst case, fwupd sticks a capsule in the ESP from which we booted, then that disk dies, and we don't apply the capsule. No harm done. I really think the correct approach here is to have an ESP on each potentially bootable disk. Each ESP will independently contain the code to handle BootLoaderSpec entries on a *different* partition. The only time we need to modify all the ESP copies is when we upgrade GRUB or upgrade GRUB's configuration. We do *not* need to propagate capsules or any other similar objects. And we should not even try to impose a requirement that the filesystems be bitwise identical. They're *copies*, not RAID. > > >> 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. > Mount with noxattr? --Andy _______________________________________________ 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/THLCDQMNWAFK3JATIEZYIU44GYAOY35B/
