Date: Fri, 15 Dec 2017 19:05:17 -0700 From: Warner Losh <imp@bsdimp.com> To: Eric McCorkle <eric@metricspace.net> 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: <CANCZdfrpi3JTDxo17RBiLdZ=UjdPF3FgpqwmBepZ=8k5-P0F2g@mail.gmail.com> In-Reply-To: <46af04dd-8f74-b9dc-3d3a-343f022129ed@metricspace.net> References: <1fa7edde-6ac0-1d4f-e75a-503b23a5d4dc@metricspace.net> <CANCZdfpJm9MjxvO4dPy7qZ4jjot44yAMj7NhaY_MQ5z7WVbd9A@mail.gmail.com> <46af04dd-8f74-b9dc-3d3a-343f022129ed@metricspace.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 15, 2017 6:43 PM, "Eric McCorkle" <eric@metricspace.net> wrote: 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. Where do we get this info for such a broken setup? Do you have actual examples? > 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. What useful setups does this break? Absent a real example, we absolutely are breaking this. There is a real cost to doing this that as the de facto maintainer of stand I'm unwilling to maintain, test or commit to not breaking. The legacy behavior is broken and has caused me hours of pain in production. There has been no articulated use case this enables, especially since boot loader can be interrupted to specify something in recovery scenarios. > > 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. No. Absent a sane use case, I refuse. Give me a reasonable use case, I will reconsider. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrpi3JTDxo17RBiLdZ=UjdPF3FgpqwmBepZ=8k5-P0F2g>