On Tuesday, December 19, 2017, Warner Losh <i...@bsdimp.com> wrote: > On Dec 18, 2017 6:06 PM, "Rodney W. Grimes" < > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > > On Mon, Dec 18, 2017 at 3:12 PM, Mark Millard <mar...@dsl-only.net> > wrote: > > > > > Warner Losh imp at bsdimp.com wrote on > > > Mon Dec 18 20:29:45 UTC 2017 : > > > > > > > The specific thing we will stop doing is that in the absence of > > > > instructions to the contrary, we will no longer search for root on a > > > device > > > > other than the one the loader.efi came from. > > > > > > Warner Losh imp at bsdimp.com wrote on > > > Sun Dec 17 19:52:07 UTC 2017 : > > > > > > > In the coming months, we're looking at dropping boot1.efi and instead > > > > installing /boot/loader.efi onto the ESP (most likely as > > > > \efi\freebsd\loader.efi). > > > > > > > > > Combining the two statements would appear to have consequences > > > not obvious from the separate statements in isolation. Rewording > > > the first to substitute where loader.efi comes from based on > > > the second (if I interpret right): > > > > > > MISQUOTE > > > The specific thing we will stop doing is that in the absence of > > > instructions to the contrary, we will no longer search for root > > > on other than the device for the ESP used (which will hold > > > loader.efi). > > > END MISQUOTE > > > > > > > The specific thing we will stop doing is that in the absence of > > instructions to the contrary, we will no longer search for root on other > > than the device for the ESP used (which will hold now loader.efi as > > boot1.efi will shortly be eliminated). > > Yes please, that is the correct behavior, our searching can lead to > problems, and as you have pointed out, often more problems than it > ever really fixed. > > > > > 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. > > use the ACTIVE ufs partition, not the first, I can have more than 1 slice, > only 1 of them can be set active. Do not use any ufs partitions if they > are not in active slices, it is possible to have 0 partitions set active. > > > Active is not a GPT concept. UEFI makes it hard to implement since there is > no good API to get and set the flags FreeBSD's gptboot uses to hack this > concept in. Active is done via BootOrder UEFI variable. Loader.efi and > boot.efi completely ignore this today. I have no plans on changing that.
And what's about the bootme and bootonce flags in gpart? They are freebsdism? Or they are the equivalent of active in the UEFI standard? > > > > > A partition is usable if /boot/loader.rc exists on that path. > > A partition is usable if it is in an active slice, and ^above > > > Active isn't a got thong. So no. > > Is there any fallback to skip loader and go direct to > /boot/kernel/kernel, back to /kernel any more? > > > You are thinking about this wrong. We are loader.efi, not boot2. This is > one of the big advantages of loading directly. We don't have the space > limitations that forced that design, so we should simplify. > > Warner > > > 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. > > > > Warner > > _______________________________________________ > > 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" > > -- > Rod Grimes > rgri...@freebsd.org > _______________________________________________ > 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" > _______________________________________________ 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"
