Re: UEFI booting survey

On Tuesday, December 19, 2017, Warner Losh <imp_at_bsdimp.com> wrote:

> On Dec 18, 2017 6:06 PM, "Rodney W. Grimes" <
> freebsd-rwg_at_pdx.rh.cn85.dnsmgr.net> wrote:
>
> > On Mon, Dec 18, 2017 at 3:12 PM, Mark Millard <markmi_at_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_at_freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "
> freebsd-current-unsubscribe_at_freebsd.org"
>
> --
> Rod Grimes
> rgrimes_at_freebsd.org
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>