ZFSROOT UEFI boot

Tomoaki AOKI junchoon at dec.sakura.ne.jp
Sun Jan 31 12:02:04 UTC 2016


Sorry. I just noticed this mail is not a duplicate of which I just
responded to. :-(

I built boot1.efi that is applied Diff6 with -DEFI_DEBUG, but not with
-DDEBUG.
Was it sufficient? Or does some info be missed with above option I set?


On Sat, 30 Jan 2016 12:43:31 +0000
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 〓
> 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:;>"
> >


-- 
青木 知明  [Tomoaki AOKI]
    junchoon at dec.sakura.ne.jp
    MXE02273 at nifty.com


More information about the freebsd-current mailing list