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? (For my particular interest the context uses UFS, not ZFS.) > 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 https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
