On Mo, 18.06.18 10:30, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) wrote: > >> 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 boot loader spec suggests that $BOOT and the ESP are the same thing, and I am very sure this is the best and simplest approach for all images that have no explicit reason to depart from that. However, the spec does not actually require $BOOT to be the same as the ESP. The freedom to make $BOOT != ESP was added as a compromise, because some folks were adamant that resizing the ESP on multi-boot systems should not be done (i personally don't think it's as big a prob as people claim though...). Today, systemd has this generator that will automatically find the ESP for you and mount it to /efi or /boot. The idea behind that is that installers can choose whether they want to merge $BOOT and the ESP or not: 1. If they are merged, then the ESP (and thus also $BOOT) is mounted to /boot, automatically by the generator. No other preparation is needed, and /efi does not exist. (Distros could even make /efi a symlink → /boot, but I personally wouldn't bother). 2. If they are not merged, then the ESP is mounted to /efi, automatically by the generator. And /boot would be mounted as $BOOT via an /etc/fstab entry added by the installer. And as mentioned, I'd generally recommend everybody to go for option #1 because it is a lot simpler, and EFI has trivial access to all kernels and such. The boot loader can start the EFI shell and its trivial to explore the contents and everything and manually boot any kernel you like. This approach also means that no /etc/fstab entry is needed, and thus things are a lot more self-sufficient and robust. It would be my assumption that all OS images generated in full by some image builder would go for option #1, and option #2 would only be used when a traditional installer such as anaconda is used that is supposed to add a Fedora installation to a system that is already set up otherwise, i.e. already has an EFI partition in place that is considered too small. i.e. option #2 is the multi-boot-with-windows usecase, while option #1 is for pretty much everything else. > > 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. Well, if you really want to cover this, then using the automount stuff actually allows you to solve this much nicer than traditional setups: write a service (possibly just a script around dd with some locking might suffice) that is pulled in by the .mount unit that the .automount unit is backed by, and is ordered before the .mount unit. This then means its ExecStart= and ExecStop= line would run before and after the mount is around. In ExecStop= you could then dd the mounted file system onto the other copies. And we'd do though automatically after each series of accesses. > > 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 ? systemd will do the discovery and automount unit generation only for the ESP, and it's very defensive, i.e. it will never over-mount neither /boot or /efi if there's anything in there, or if there's already an explicit line for in /etc/fstab and such. If you want to separate $BOOT from the ESP, then let the generator handle the ESP for you under /esp, and mount $BOOT yourself with an fstab entry. Lennart -- Lennart Poettering, Red Hat _______________________________________________ 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/A3KO4LXBJC2SLHHLVXAV7PLXZXG4PWKZ/
