On Mon, Jun 18, 2018 at 7:27 AM, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > On Do, 14.06.18 14:20, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) wrote: > >> The cited BLS spec is the original one, not the more thoroughly >> discussed and thought through variant by Matthew Garrett [1] some >> years ago. > > Quite frankly, as one of the authors of the original BLS spec, I can'd > say Matthew's version was much discussed with me... It was discussed here in devel@ extensively years ago... And there certainly were a lot more questions than answers, which was a big part of what Matthew Garrett was trying to address. So this feature pointing to the original BLS inherently raises all of those same questions and concern again. > > I mean, I am open to extending the spec, but we should do this bit by > bit. > > Zbigniew suggested to move the spec into docbook or markdown format, > and then accept changes via usual github PRs. If there's interest > still in extending the spec with some of Matthew's ideas we can > certainly look into that, but in general I'd actually prefer to reduce > the size of the spec if possible, and drop as many bits of it as we > can, i.e. the stuff noone implements anyway. I'm fine with it being concise and constrained, so long as people understand the consequences. I mainly don't want to have the feature pointing to a spec, and then for the feature to actually implement something else. That has been the track record so far with the bls.mod code in Fedora's fork of GRUB. It really does us no good to have conversations and debates about things that the feature owners have no intention of implementing; meanwhile we totally miss having conversations and debates on things they do intend to implement that we don't know because they aren't in the spec. So yeah: update the reference spec first so we aren't spinning our wheels arguing about aspects of the spec that don't matter. >> The cited BLS spec requires $BOOT be VFAT, are we doing that? > > Why would we? I mean the idea is that $BOOT can be shared among > multiple OSes installed. Which means one really should settle on a > format anyone can read. And VFAT certainly qualifies as that, most > other file systems do not. Do you mean "why wouldn't we?" Flipping over everyone's /boot to become the ESP on VFAT is a substantial change so I'm asking the question, yet again. This was asked a long time ago with the original conversations on this list about BootLoaderSpec, and those questions and answers are addressed in Matthew Garrett's derivative of the spec. The single biggest issue with BootLoaderSpec is the part where kernels and initramfs go on $BOOT. In 2018 the size of an existing ESP created by Microsoft's installer is 100MB, with OEM installers creating an ESP between 100MB and 250MB. This is too small to share, if it includes kernels and initramfs as the spec requires. The Fedora installer creates /boot at 1GiB, which it wants for itself. To really share it with other distros implies a minimum size of 2G, not 500MB as the spec says now. If an ESP already exists, that means a new partition of type 0xEA / bc13c2ff ... and that means Fedora bootloader stuff is on a volume other than the ESP, with an existing BLS format that explicitly doesn't allow pointing to other partitions/volumes (the Matthew Garrett derivative addresses this). So that means a whole host of dual boot liabilities, not just Windows but also other distros. Also, there's no security labeling or UNIX permissions possible on VFAT; so does the 'context=' mount option applied to the whole of this new VFAT $BOOT sufficiently address security concerns? I think no longer persistently mounting this volume helps security rather than hindering it, but there's nothing in the feature proposal assessing any of these changes. > >> Are we going to stop doing the diabolical (and widespread) nested >> mount nonsense, e.g. /boot/efi? Are we getting rid of the persistent >> mounting of these volumes in favor of mounting/unmounting dynamically >> only by the programs that are authorized to make changes to these >> volumes? > > So, in systemd we ship a generator that automatically establishes > automount points for the ESP. It will preferably use /efi as mount > point if it exists and is empty. If it doesn't exist or isn't > empty it will use /boot — if that exists or is empty. If neither exist > or are empty it won't do anything. Using an automount point for this > has many benefits: > > 1) The chance that the ESP remains in a clean state is maximized, as > the file system is unmounted whenever possible, and only mounted > for a short time window around actual disk accesses. This is the > behaviour you really want for something as fragile as the ESP. > > 2) It's compatible with current behaviour, as the path is always > accessible under a fixed name, requiring no explicit mounting. > > 3) There's no need to configure any lines for the ESP in /etc/fstab > anymore. Instead the system will discover the ESP automatically and > make it available. This means the installer can be simpler, and > things are generally more robust as /efi (or /boot) will follow > what is in place, instead of require a separate layer of > configuration that has a good chance of getting out of sync. I've got no complaints with this although as mentioned in the other thread "f29 bootloader changes / raid1 installs + efi" this generator lacks the intelligence needed to support multiple ESPs for any RAID use case, e.g. md or LVM or Btrfs RAID1. I wouldn't say that use case must work for Fedora 29, but I would say the spec and feature must account for this use case and make it possible to support; saying we don't care about this use case compared to BIOS days, is functionally a regression. And saying it's only supportable with proprietary firmware RAID is objectively worse than what Apple has supported in software for a decade, and maybe Windows as well I'm not really sure how they update multiple ESPs. As for /efi vs /boot I think we should, wherever possible, abstract firmware and bootloader differences from the end user as much as possible. And that means using /boot, not /efi. This is consistent with the (next to useless) FHS. It makes the location for these files the same on BIOS, UEFI, and whatever other firmware. It's easier for users and documenters and QA. The counter example: /boot/grub2/grub.cfg vs /boot/efi/EFI/fedora/grub.cfg as an example of what not to do to users. That has been a clusterfuck of a UX (that is the diplomatic language). It also is a departure from upstream and how other distros handle it. And also, last time I checked, the BLS spec file format and bls.mod GRUB code is not upstream. GRUB maintainers had their own questions and concerns on grub2-devel@ that likewise went unaddressed. > I'd love to see Fedora adopt this generator. Primarily this would mean > some chnages to anaconda I guess. It would make things simpler and > more robust. That said, the generator only cares about the ESP, not > for cases where $BOOT is backed by any other partition. Ok so you're saying if $BOOT is type 0xEA, or type bc13c2ff-59e6-4262-a352-b275fd6f7172, the generator will not automount it at /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/NWNKRKAHW7UPK2I53CHHE6YBMJY77RDC/
