Re: ZFSROOT UEFI boot

On Sat, 30 Jan 2016 12:53:46 +0000
Steven Hartland <steven_at_multiplay.co.uk> wrote:

> I just realised an important point, does your usb disk have a UFS
> root partition and your internal disk ZFS root partition?

Yes. That's it, as shown in my prior post (`gpart show` output).
The USB memstick is dd'ed with memstick.img of head, so UEFI-enabled
root-on-UFS installation without ZFS and starts bsdinstall if booted.
And internal disks are both working root-on-ZFS installation, each of
which have raw UFS partition (not inside ZFS pool) for (mostly for now)
testing loader.


> If so then I know what the issue is, I'll have quick look now, so wait for
> a diff5 to appear before testing.

I'll report later in reply to your another message (stating that Diff5
is available).
But unfortunately, I have only one notebook (without serial I/F) as
non-dead computer. So I wouldn't be able to report boot logs.

Thanks in advance!


> On Saturday, 30 January 2016, Steven Hartland <steven_at_multiplay.co.uk>
> wrote:
> 
> > 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 $B".(B
> > On Saturday, 30 January 2016, Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp
> > <javascript:_e(%7B%7D,'cvml','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> 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>
> >> 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 mailing list
> >> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >> > To unsubscribe, send any mail to "
> >> freebsd-current-unsubscribe_at_freebsd.org"
> >> >
> >>
> >>
> >> --
> >> $B_at_DLZ(B $BCNL_at_(B  [Tomoaki AOKI]
> >>     junchoon_at_dec.sakura.ne.jp
> >>     MXE02273_at_nifty.com
> >> _______________________________________________
> >> 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
> >> "
> >>
> >
> _______________________________________________
> 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"
> 
> 


-- 
Tomoaki AOKI    junchoon_at_dec.sakura.ne.jp