Re: ZFSROOT UEFI boot

From: Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp>
Date: Thu, 4 Feb 2016 00:17:56 +0900
Performed remaining tests below using "without -DEFI_DEBUG" binary and
confirmed all boots as expected. Also tested already-reported tests
with the binary and confirmed that boot just as EFI_DEBUG binary did.

 *Boot from ada0, ZFS doesn't have /boot/loader.efi, while UFS has.
   -> Loads /boot/loader.efi, then kernel from ada0 UFS partition,
      and mounts root as /boot/loader.conf there specifies.

 *Boot from ada1, ZFS doesn't have /boot/loader.efi, while UFS has.
   -> Loads /boot/loader.efi, then kernel from ada1 UFS partition,
      and mounts root as /boot/loader.conf there specifies.

I intentionally installed different revision of kernels on each pool /
partition, so I could determine from which pool/partition kernel was
loaded from.

If logs are needed for them, I'll re-test using EFI_DEBUG binary.

Regards.


On Wed, 3 Feb 2016 00:46:01 +0900
Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp> wrote:

> Thanks! The behavior is fixed and now boots as expected. :-)
> Please see attached.
> 
> What's not tested yet is:
>   *Fallback to UFS from ZFS in the same disk works or not.
>   *Without -DEFI_DEBUG binary.
> 
> Regards.
> 
> 
> On Mon, 1 Feb 2016 18:06:14 +0000
> Steven Hartland <killing_at_multiplay.co.uk> wrote:
> 
> > Ok thanks, I hoped as much, otherwise we where looking a very broken EFI 
> > firmware ;-)
> > 
> > I've found and fixed the match issue, so if you could re-test 2 and 3 we 
> > should be able confirm all is good.
> > 
> > If all is good a confirmation that there's no issues with the rest, but 
> > no need for output, needed.
> > 
> >      Regards
> >      Steve
> > 
> > On 01/02/2016 16:19, Tomoaki AOKI wrote:
> > > Woops! Found mistype in Diff8 report. Sorry. :-(
> > > Attached is the fixed one. [imagepath line of 1) is fixed.]
> > >
> > >
> > > On Mon, 1 Feb 2016 23:36:27 +0900
> > > Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp> wrote:
> > >
> > >> Thanks in advance.
> > >> But unfortunately, the boot behavior of Diff7 and Diff8 are changed
> > >> from Diff6. Back to old problematic behavior.
> > >>
> > >> FYI, I re-tested Diff6 (previously built binary) and reproduced the
> > >> behavior I already reported. (So no new logs for it.)
> > >>
> > >> Please see attached 2 files (for Diff7 and Diff8 respectively).
> > >> In addition to test 2) and 3), 5) [USB boot] for Diff7 and 1) [single
> > >> drive] for Diff8 are done.
> > >>
> > >> Regards.
> > >>
> > >>
> > >> On Sun, 31 Jan 2016 13:58:23 +0000
> > >> Steven Hartland <killing_at_multiplay.co.uk> wrote:
> > >>
> > >>> Thanks for doing that it was very helpful, and I know transcribing from
> > >>> video would have been quite a time consuming task.
> > >>>
> > >>> I noticed a few interesting facts:
> > >>> 1. It looks like when you boot from ada0 and ada1 its still picking the
> > >>> same device (according to device order).
> > >>> Its not 100% clear as your devices are sata which Diff 6 didn't have
> > >>> decoding for. I've added that now so hopefully we can confirm, also
> > >>> added output of boot1 imgpath: so we can see what the EFI thinks the
> > >>> boot device is.
> > >>> 2. Your usb device path has two message path entries which means
> > >>> msg_paths_match would result in a false positive for usb devices, this
> > >>> is now fixed by matching until we see a media path.
> > >>>
> > >>> If you can now re-test the following two cases:
> > >>> 2) Boot from ada0 without USB memstick attached (2 drives).
> > >>> 3) Boot from ada1 without USB memstick attached (2 drives).
> > >>>
> > >>> I'm interested to confirm two things:
> > >>> 1. If the boot1 imgpath lines do indeed vary
> > >>> 2. If the "load: '/boot/loader.efi'" line devpath matches the boot1 imgpath.
> > >>>
> > >>> The changes from Diff 7 shouldn't effect the outcome of the other tests,
> > >>> but confirming that too wouldn't hurt but no need for the output.
> > >>>
> > >>>       Regards
> > >>>       Steve
> > >>> On 31/01/2016 11:43, Tomoaki AOKI wrote:
> > >>>> I found Diff6 you uploaded to PHABRICATOR. So my report below is based
> > >>>> on it.
> > >>>>
> > >>>> The patched boot1.efi runs as expected (== as you wrote) for me.
> > >>>>     *boot1.efi without -DEFI_DEBUG isn't tested. Needed?
> > >>>>
> > >>>> As I mentioned in my previous post, I have no serial console
> > >>>> environment. So I took movie of limited tests and typed it.
> > >>>>
> > >>>> Which of the tests are typed:
> > >>>>
> > >>>>     1) Boot from ada0 removing ada1, no USB memstick attached, ZFS in
> > >>>>        ada0 has loader.efi. (Single drive config.)
> > >>>>
> > >>>>     2) Boot from ada0, no USB memstick attached, ZFS in ada0 has
> > >>>>        loader.efi.
> > >>>>
> > >>>>     3) Boot from ada1, no USB memstick attached, ZFS in ada1 has
> > >>>>        loader.efi.
> > >>>>
> > >>>>     4) Boot from ada1, no USB memstick attached, only UFS in ada0 has
> > >>>>        loader.efi.
> > >>>>
> > >>>>     5) Boot from da0 (USB memstick with memstick.img of head).
> > >>>>        UFS in da0 has loader.efi and ZFS isn't present in da0.
> > >>>>        (3 drives [2 drives + USB memstick] config.)
> > >>>>
> > >>>> Please see attached text for detail. Are more outputs needed?
> > >>>>
> > >>>> Thanks in advance! I'm looking forward to see this MFC'ed before
> > >>>> releng/10.3 is branched. (Relies on imp_at_'s test?)
> > >>>>
> > >>>>    *Will need to be in conjunction with changes after r294265 in head, as
> > >>>>     currently Diff6 doesn't apply to stable/10.
> > >>>>
> > >>>> Regards.
> > >>>>
> > >>>>
> > >>>> On Sat, 30 Jan 2016 19:12:34 +0000
> > >>>> Steven Hartland <killing_at_multiplay.co.uk> wrote:
> > >>>>
> > >>>>> I believe, based on testing, that the from Diff 5 onwards of
> > >>>>> https://reviews.freebsd.org/D5108 this should work as you expect it i.e.
> > >>>>>
> > >>>>> If boot1 is loaded from a device which has either a UFS or ZFS bootable
> > >>>>> install then this is the device that will be used to boot.
> > >>>>>
> > >>>>> If said device has both then the ZFS setup will still be tried first.
> > >>>>>
> > >>>>> If you can test in your setup and confirm either way that would be most
> > >>>>> appreciated.
> > >>>>>
> > >>>>>        Regards
> > >>>>>        Steve
> > >>>>>
> > >>>>> On 30/01/2016 06:57, Tomoaki AOKI 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"
> > >>>>>>>
> > >>>>> _______________________________________________
> > >>>>> 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"
> > >>> _______________________________________________
> > >>> 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
> > >
> > 
> > _______________________________________________
> > 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


-- 
Tomoaki AOKI    junchoon_at_dec.sakura.ne.jp
Received on Wed Feb 03 2016 - 14:18:02 UTC

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