Re: ZFSROOT UEFI boot

From: Steven Hartland <steven_at_multiplay.co.uk>
Date: Sat, 30 Jan 2016 12:43:31 +0000
I did some more work on the review last night, if you could apply the
latest patch set diff4 to see if that helps.

If not compile with debugging using -DEFI_DEBUG on your make line then you
will get a lot more information about which disk is being used to load from
as well as info about the probe order.

What you should see is that the disk you boot from (where boot1 is loaded
from) should be probed first and hence get flagged as successful
(preferred).

This also shows up as * instead of + in the non-debug boot process.

If this happens you should see loader.efi loaded from this disk and then
the kernel.

The debug output is verbose so you may need a serial console to be able to
capture the output easily.

Thanks for testing so far hopefully we can nail this soon 😊
On Saturday, 30 January 2016, Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp>
wrote:

> Thanks for your quick support!
> I tried your patch [Diff1] (built with head r295032 world/kernel) and
> now have good and bad news.
>
> Good news is that without USB memstick boot1.efi runs as expected.
> Great!
>
> Bad news is that when booting from USB memstick (the one I used my
> previous test, boot1.efi [bootx64.efi] and loader.efi is replaced) and
> whichever of internal disk (ada[01]) have loader.efi in its ZFS pool,
> ada[01] is booted instead of da0 (USB memstick).
>
>   *If ada0 has loader.efi, always booted from ada0 (stable/10).
>   *If ada0 doesn't have loader.efi and ada1 has, booted from ada1
>    (head).
>   *If both ada0 and ada1 don't have loader.efi, da0 (USB memstick) is
>    booted (head, installer is invoked).
>
>  *Whichever ada[01] has loader.efi in their UFS or not didn't matter.
>
> These behaviour would be because ZFS thoughout all disks is tried
> before trying UFS throughout all disks, if I understood correctly.
>
> Changing boot order (ZFS to UFS per each disk, instead of each
> ZFS to each UFS) would help.
> But providing ZFS-disabled boot1.efi (boot1ufs.efi?) for installation
> media (memstick, dvd, ...) helps, too. I built ZFS-disabled boot1.efi
> and it worked fine for USB memstick for me.
>
>  *`make clean && make -DMK_ZFS=no` in sys/boot/efi/boot1 didn't disabled
>    ZFS module, so I must edit the definition of *boot_modules[] in
>    boot1.c. I'd have been missing something.
>
> Regards.
>
>
> On Fri, 29 Jan 2016 02:58:26 +0000
> Steven Hartland <killing_at_multiplay.co.uk <javascript:;>> wrote:
>
> > On 28/01/2016 16:22, Doug Rabson wrote:
> > > On 28 January 2016 at 15:03, Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp
> <javascript:;>> wrote:
> > >
> > >> It's exactly the NO GOOD point. The disk where boot1 is read from
> > >> should be where loader.efi and loader.conf are first read.
> > >>
> > > I just wanted to note that gptzfsboot and zfsboot behaves this way.
> Boot1
> > > looks for loader in the pool which contains the disk that the BIOS
> booted.
> > > It passes through the ID of that pool to loader which uses that pool
> as the
> > > default for loading kernel and modules. I believe this is the correct
> > > behaviour. For gptzfsboot and zfsboot, it is possible to override by
> > > pressing space at the point where it is about to load loader.
> >
> > I believe I understand at least some of your issue now, could you please
> > test the code on the following review to see if it fixes your issue
> please:
> > https://reviews.freebsd.org/D5108
> >
> >      Regards
> >      Steve
> > _______________________________________________
> > freebsd-current_at_freebsd.org <javascript:;> mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "
> freebsd-current-unsubscribe_at_freebsd.org <javascript:;>"
> >
>
>
> --
> 青木 知明  [Tomoaki AOKI]
>     junchoon_at_dec.sakura.ne.jp <javascript:;>
>     MXE02273_at_nifty.com <javascript:;>
> _______________________________________________
> freebsd-current_at_freebsd.org <javascript:;> mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org
> <javascript:;>"
>
Received on Sat Jan 30 2016 - 11:43:34 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:02 UTC