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 -- $B_at_DLZ(B $BCNL_at_(B [Tomoaki AOKI] junchoon_at_dec.sakura.ne.jp MXE02273_at_nifty.com
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:02 UTC