[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

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to