loader.efi architecture for replacing boot1.efi

Eric McCorkle eric at metricspace.net
Sat Dec 16 00:57:16 UTC 2017


I have posted a review which begins to move loader.efi in the direction
of replacing boot1.efi.  The review can be found here:
https://reviews.freebsd.org/D13497

This patch enables loader.efi to be installed to /efi/boot/BOOTX64.EFI
on the ESP.  It implements what I envision being the last-resort
fallback mechanism, but this is enough to allow it to boot a FreeBSD system.

It also preserves the existing behavior, so as not to break anyone's
install.

The *eventual* procedure for initial partition selection looks like this:

1) See if the boot loader arguments directly specify a kernel and/or
partition, use that if they do.

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

4) At the very last, do the legacy (what loader.efi currently does)
behavior.

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.


More information about the freebsd-arch mailing list