On 06/18/2018 07:37 PM, Andrew Lutomirski wrote:
>> On Jun 18, 2018, at 3:54 PM, Chris Murphy <li...@colorremedies.com> wrote:
>>
>> On Mon, Jun 18, 2018 at 3:42 PM, Andrew Lutomirski <l...@mit.edu> 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:
1. grub${arch}.efi reads its embedded config file
2. embedded config file says to read grub.cfg from file from ESP (maybe
hardcoded to /EFI/fedora/grub.cfg if we want a copy of the efi file
at /EFI/BOOT/BOOT${arch}.EFI to also work)
3. ESP's grub.cfg says to read /grub2/grub.cfg from UUID=X
4. /grub2/grub.cfg on UUID=X is where kernel and initrd lives and are
configured.
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org/message/QJKGENMUYT2VN62G3JSSL4EAZEYJIQUL/
