UEFI booting survey

Mark Millard markmi at dsl-only.net
Tue Dec 19 19:26:34 UTC 2017

[I forgot to list the .dtb file with the
kernel and world.]

On 2017-Dec-19, at 9:58 AM, Mark Millard <markmi at dsl-only.net> wrote:

> On 2017-Dec-18, at 2:37 PM, Warner Losh <imp at bsdimp.com> wrote:
>> . . .
>> Or the following pseudo-code with all the weird special cases removed for clarity
>> load loader.efi from ESP
>> if BootXXXX uefi variable holds a second path, use that for root/kernel
>> otherwise if an override variable holds a kernel/root path, use that
>> otherwise scan for a usable ZFS pool, use that if it exists
>> otherwise use the same partition loader.efi was booted from for root/kernel if it's usable
>> otherwise use the first UFS partition on the ESP that's usable.
>> A partition is usable if /boot/loader.rc exists on that path.
> What will be the role of /etc/fstab in establishing
> were the kernel is loaded from? Where world is
> loaded from? Where/how does use of /etc/fstab for
> specifying the root file system mount fit in the
> above pseudo-code?

Typo: should be "establishing where".

> (For my particular interest the context uses UFS, not
> ZFS.)

I forgot to list:

What will be the role of /etc/fstab in establishing
where the .dtb file will be found (when such is

>> What is being deleted is one final step: "otherwise use the first UFS partition on any drive in a random order that's usable." which used to be at the end of the boot1.efi psuedo code. It's my belief that no such installations actually use this due to the random factor today (plug in a new USB drive and it might take over). If my belief is wrong, it's my belief that efibootmgr will solve it, and failing that, the fallback mechanism (for platforms that use u-boot + EFI where UEFI variables don't work) will allow the two or three people that are doing this today.

Mark Millard
markmi at dsl-only.net

More information about the freebsd-current mailing list