loader.efi architecture for replacing boot1.efi

Eric McCorkle eric at metricspace.net
Fri Dec 22 01:13:03 UTC 2017


On 12/16/2017 19:17, Richard Perini wrote:

>> No. It doesn't. You're assuming that if we fail, the system won't boot.
>> That's false. If we fail to boot device X, it's our job to fail so that if
>> there's a Y or a Z it can be next. We have no knowledge of whether the user
>> would prefer Y or Z as the next one to try, but the boot manager that runs
>> inside every single UEFI firmware does and it will go to the next one. Y
>> might be a recovery disk or copy of a freebsd memory stick release and Z
>> might be a redundant copy of X to use in cases where X fails. Or vice
>> versa. Do we want to boot to the installer? Not as a first choice, but
>> maybe as a last resort. But we should let UEFI orchestrate the retries.
>> Trying to second guess is fundamentally wrong, especially in UEFI where the
>> boot order and boot recovery stuff is so extensively and particularly
>> defined. Having fought the "oh, I'm going to guess" code in boot1.efi for
>> over a year and after having it consistently pick the wrong thing to boot
>> on some tiny fraction of the hundreds of systems I've had deployed give me
>> strong empirical data that shows the guessing too hard bit is actually
>> actively harmful. I've thought about this a lot. I've thought through all
>> the supported scenarios. I've written up documents and solicited feedback.
>> Nobody to date has said "oh no! I really want the random installed system
>> roulette! I love it! Don't kill it."
>>
>> Warner
>> _______________________________________________
>> freebsd-arch at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
> 
> To add support to Warner, as an administrator of 50+ FreeBSD systems on
> a variety of hardware and disk configs, I totally support Warner's arguments.
> Having the loader trying to guess in the case of unusual setups when it
> can't find a kernel __on the same device as the loader__ causes grief.  If 
> you want to have your thing boot that way, then configure it to do so, or 
> present a menu of boot options.  
> 

Ok, I've updated my review, simplifying the search code.  The option to
search all devices is only enabled by a preprocessor macro at this point.

I have a mostly-complete follow-on, which adds parsing of args from the
boot.config files.

Anyway, the state of my review at this point is enough that I'm
unblocked on the GELI work.


More information about the freebsd-arch mailing list