Date: Fri, 15 Dec 2017 20:43:58 -0500 From: Eric McCorkle <eric@metricspace.net> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-arch@freebsd.org, Warner Losh <imp@freebsd.org>, Allan Jude <allanjude@freebsd.org> Subject: Re: loader.efi architecture for replacing boot1.efi Message-ID: <46af04dd-8f74-b9dc-3d3a-343f022129ed@metricspace.net> In-Reply-To: <CANCZdfpJm9MjxvO4dPy7qZ4jjot44yAMj7NhaY_MQ5z7WVbd9A@mail.gmail.com> References: <1fa7edde-6ac0-1d4f-e75a-503b23a5d4dc@metricspace.net> <CANCZdfpJm9MjxvO4dPy7qZ4jjot44yAMj7NhaY_MQ5z7WVbd9A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/15/2017 20:09, Warner Losh wrote: > This should be second. Uefi variables Trump all. > > 2) If not, then attempt to read EFI vars to determine the boot location > > 3) If no EFI vars are defined, and no partition was specified, fall back > to looking for an installed system on devices > > > This is fine, so long as it is only on the device that the loader loaded > from. It's fine if it's configurable, but there needs to be sane behavior if the EFI vars aren't set. > 4) At the very last, do the legacy (what loader.efi currently does) > behavior. > > > This is bogus. It violates the uefi boot loader protocol. We must > abandon this legacy behavior. The behavior is actively harmful since > something random will boot. This has caused actual operational issues at > Netflix. Guessing is really bad. We can't just ditch the current behavior and break everyone's existing install, though. Legacy behavior should be supported at least until the next major release. > > Step (3) is done by attempting to stat /boot/loader.conf and > /boot/kernel. First, all partitions on the same disk are searched, then > all remaining partitions are searched. > > This should allow mechanisms like EFI vars and command-line args to work > without interference from the fallback mechanisms. However, it also > provides robustness in the face of failure modes and uninitialized > systems (I personally ran into a problem a while back with a linux > system, where I couldn't boot with EFI, because the EFI vars weren't > set, because I couldn't set them if I couldn't boot with EFI; had to use > Shell.efi to sort out the mess...) > > More importantly, it provides a seamless transition from the way things > are now to the way we want things to be. > > Please provide comments and feedback. > > > Please listen when I say searching all devices is actively harmful. The > uefi boot manager, which I'm in the process of bringing in, offers a way > to specifically say what you want to boot. If someone needs something > complicated, they must use that moving forward. Part of what makes the > protocol work is loaders giving up early so the next one on the list can > be tried. We also have to deal with the reality that some EFI implementations are adversarial. We have to be able to deal with implementations that make it difficult to set EFI vars, or which mess with their values (Lenovo is particularly notorious for this). You can disable fallback mechanisms with command-line args or macros or whatever, but they need to be there.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46af04dd-8f74-b9dc-3d3a-343f022129ed>