Date: Thu, 26 Oct 2017 08:32:58 -0400 From: Eric McCorkle <eric@metricspace.net> To: Warner Losh <imp@bsdimp.com> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Warner Losh <imp@freebsd.org> Subject: Re: New behaviors for loader.efi Message-ID: <87ceccf2-09fb-1adb-6304-649961cae2d4@metricspace.net> In-Reply-To: <CANCZdfpfxxkAjmFoCdeXi-Q0kduJiXCS_%2BiwfuW_32FY_m0EbA@mail.gmail.com> References: <ecfa88fb-be25-0c47-ee24-ef6511dccd9e@metricspace.net> <CANCZdfpfxxkAjmFoCdeXi-Q0kduJiXCS_%2BiwfuW_32FY_m0EbA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/25/2017 22:58, Warner Losh wrote: > I would vote neither. If it belongs on the ESP at all, it belongs in > \efi\freebsd\boot.conf. We now own \efi\freebsd, so that's where all our > boot files need to wind up in our install. But I'm not sure that we need > it at all, since boot.conf is only for boot1/boot2 in the current system > (though it does set serial by default, which might be helpful to > preserve). It would be even better, though, to use the command line > that's passed in as part of the UEFI:BootXXXX environment variable. > Since we have to move it anyway, we should do things in the EFI way, > which is to store all the nonvolatile info in UEFI environment variables > (and in this case, the command line / aux info in the BootXXXX > variable). We really need to stop polluting \efi\boot with anything, > except on removable media. That seems reasonable, however it might be worth having a backup mechanism (boot.conf) in case the EFI vars get clobbered. Also, a file with the args can be more easily signed and verified than EFI vars. > I think it should be in /boot/loader.conf on /, not the ESP. We should > only have \efi\freebsd\loader.efi in the ESP. Also my inclination. > I'm not sure that it should look very hard, and it should only look as a > last result. > > UEFI:BootCurrent lists the current boot variable. It points to the > UEFI:BootXXXX that contains a LoadOption variable. This variable > contains a series of DevicePaths. The first one is what the UEFI BIOS > uses to load loader.efi (installed as ESP:\EFI\FREEBSD\LOADER.EFI). The > second one in the list will point to the kernel to load. That way we > shouldn't have to go looking at all. We assume that the root is the same > partition we load the kernel comes from. We should only go looking if we > fail to find the second path in the LoadOption. Right. The search would be a fallback mechanism, if all else fails. It doesn't even need to succeed; it just needs to make a reasonable guess. > No, we don't. boot1.efi already does this, and legacy systems will > already have this installed. So we don't have to recreate this behavior > if we don't want to since updated systems will need to follow the > efibootmgr protocol. There's no way the loader.efi will fit on the old > ESPs we created anyway... loader.efi needs to cope with being loaded > this way, but it doesn't have to recreate boot1.efi's behavior. OK, I was assuming there'd be an interim period where loader.efi still gets installed to /boot/, in which case the dual-purpose would be necessary. It sounds like you want to quit installing it there altogether. With regard to GELI, it sounds like it can actually be committed in parallel with any of the changes you're planning here. This would give loader the ability to attach and explore EFI partitions, but you wouldn't be able to boot a pure-GELI system until the loader-only setup is viable.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87ceccf2-09fb-1adb-6304-649961cae2d4>