Re: When will the FreeBSD (u)EFI work?

From: Nathan Whitehorn <nwhitehorn_at_freebsd.org>
Date: Sun, 29 Mar 2020 19:33:49 -0700
On 2020-03-29 19:09, Kyle Evans wrote:
> On Sun, Mar 29, 2020 at 6:19 PM Rebecca Cran <rebecca_at_bsdio.com> wrote:
>> On 3/29/20 6:11 AM, Tomoaki AOKI wrote:
>>
>>> 3. based solution looks good to me.
>>>
>>> IMHO, assuming /efi/bootx[64|32].efi is boot1.efi or loader.efi
>>> or EFI environment pointing to either one is properly used,
>>
>> That's another thing: we should be installing loader.efi as
>> \efi\boot\bootx64.efi (as well as \boot\freebsd\loader.efi) since it's
>> entirely possible to lose the Boot Manager entry and end up with an
>> unbootable system as a result. Unfortunately people have had bad
>> experiences with other operating systems overwriting bootx64.efi and
>> don't believe we should do that.
>>
> I have mixed feelings about this -- symlinks don't exist on FAT,
> right? So then the maintenance overhead goes up, as you can always
> replace \EFI\FreeBSD\ bits, but you need to make sure \EFI\BOOT
> components are actually 100% without-a-doubt yours before you replace
> them.
>
> I'd be in favor of installing to \EFI\BOOT\... as well if and only if
> the file doesn't already exist, assuming we can figure out how to make
> it not a maintenance nightmare -- which I suspect would just mean that
> we have some tool that users use to update the ESP rather than
> instructing them to examine/replace files manually.
>
> Thanks,
>
> Kyle Evans
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>

It's basically this that has been the problem: we need a way to manage
updates of the EFI loader in this situation, which we don't currently
have. The ESP needs to be mounted at a standard point,
installworld/freebsd-update/etc. need to know to replace files there, we
need to fall back cleanly on older systems, etc. The original (failed --
and I wrote it) concept with boot1.efi was that we could install a shim
that never needs updates, which avoids needing to think about these
things, but that didn't work ideally.
-Nathan
Received on Mon Mar 30 2020 - 00:34:02 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:23 UTC