On Wed, Jul 20, 2016 at 9:29 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
21.07.2016 01:34, Chris Murphy пишет:
What *should* be true, and someone ought to check since I'm too lazy to do it right now:
Last step is to create EFI firmware bootmanager entries for each ESP instance.
Fedora's installer does do this, with the caveat I mention below...
This is the way Ubuntu does it, last time I checked. It is not the way Fedora does it on UEFI, there it's broken because the real grub.cfg only exists on the ESP and it is never sycned.
Does it also support multiple ESP and populates each one with bootloader files when bootloader is updated? What about EFI boot menu entries?
Good questions. Fedora doesn't support multiple ESPs except indirectly by mdadm RAID 1 using 0.9 metadata, which means gdisk type code FD00 is used for these ESPs rather than the proper EF00 type code. It seems most firmware don't actually care if the ESP has type code EF00, it'll try to read the file specified by NVRAM. And each member device is added to NVRAM. So on the one hand they're individuals, on the other hand they're part of a logical array. Messy. I'm not sure about Ubuntu and openSUSE. What's needed is a daemon that makes sure the proper NVRAM entries exist, otherwise there most likely won't be a proper fallback to a working drive; and this daemon can also make sure the ESPs are sync'd, including when the bootloader is updated (including shim).
Anyway, depending on whether opensuse on UEFI puts the grub.cfg, determines if this works out of the box or not. I suspect openSUSE does this per upstream GRUB, where grub.cfg is always at /boot/grub (or /boot/grub2 depending on distro specific naming) rather than on the ESP.
Correct. On non-secure EFI there is no grub.cfg on ESP at all. On secure EFI, where we install pre-built signed grub image, we do exactly as you describe - minimal grub.cfg stup to find real $prefix. Which arguably creates security issue because this stub itself is not signed.
Right. I guess you have to trust something. And that something modifying (or creating a new) grub.cfg should be capable of signing it, and then include configuration file verification within GRUB proper before trusting it. Another way of doing this is including it in measured boot. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org