|
On 06/18/2018 07:37 PM, Andrew
Lutomirski wrote:
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: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. I've been thinking about this, too, and I agree that this seems like the best solution. I think EFI is one of the places where Ubuntu/Debian seems to do better than other distros. Their GRUB .EFI file has a script and relative path hardcoded that reads a UUID from a file accompanying the .EFI file, and reads /grub/grub.cfg from the block device with the UUID specified in the accompanying file in the ESP. This lets them sign the .EFI file for secure boot, everyone gets the same .EFI file, yet it can load a grub config file from a user-defined partition (which may be md-RAIDed, which eliminates the need for complex ESP-syncing logic beyond initial installation of original EFI file and UUID file). Not to mention that their GRUB doesn't require the efi suffixes on commands like "linux" and "initrd" so the same config file can be used by both BIOS GRUB and EFI GRUB for non-dual-boot entries. Keeping the bulk kernels/initrds in their own partition should also mitigate size issues with dual booting with other distros. If ESP size is a concern for one distro, it will probably be a bigger concern for multiple distros that want to store kernels and initrds in ESP (though, it is also fair to say that the user can re-partition to make a bigger ESP. They're not exactly one-size-fits-all, anyway). The necessity/automation of running efibootmgr for new drives will need to be documented if this method ends up being used to provide a redundant ESP on md-RAIDed systems. Again, the structure I am referring to would be:
|
_______________________________________________ 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/QJKGENMUYT2VN62G3JSSL4EAZEYJIQUL/
