From owner-freebsd-current@freebsd.org Fri Feb 5 17:25:06 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EB3EEA9C26F for ; Fri, 5 Feb 2016 17:25:06 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B8195BCD for ; Fri, 5 Feb 2016 17:25:06 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from fortune.joker.local (123-48-23-227.dz.commufa.jp [123.48.23.227]) (authenticated bits=0) by dec.sakura.ne.jp (8.15.2/8.15.2/[SAKURA-WEB]/20080708) with ESMTPA id u15HOuMK018850; Sat, 6 Feb 2016 02:24:57 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sat, 6 Feb 2016 02:24:56 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Cc: killing@multiplay.co.uk Subject: Re: ZFSROOT UEFI boot Message-Id: <20160206022456.57c4863d80eda9253d0b0ddd@dec.sakura.ne.jp> In-Reply-To: <56AF9E96.3040306@multiplay.co.uk> References: <8991747525093115430@unknownmsgid> <20160124215300.4cd7f1207f5a4c7b28ef7ffc@dec.sakura.ne.jp> <56A51A4C.1040808@multiplay.co.uk> <20160129000344.feaf5f828e5d43d5fbbb652a@dec.sakura.ne.jp> <56AAD552.9090202@multiplay.co.uk> <20160130155755.485736c8e12868663b9ccfbc@dec.sakura.ne.jp> <56AD0B22.1050704@multiplay.co.uk> <20160131204356.f863901e7125456b5586b215@dec.sakura.ne.jp> <56AE12FF.9080404@multiplay.co.uk> <20160201233627.b02ada486133cca3c2eec9ad@dec.sakura.ne.jp> <20160202011951.fac68e935a3f0b414a8f34cb@dec.sakura.ne.jp> <56AF9E96.3040306@multiplay.co.uk> Organization: Junchoon corps X-Mailer: Sylpheed 3.5.0 (GTK+ 2.24.29; amd64-portbld-freebsd10.3) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 17:25:07 -0000 I got a feedback from Yuichiro NAITO at freebsd-users-jp ML. Boots fine using memstick created using release/release.sh on patched head. (Diff9) Properly shows up installer screen. The system is Macbook Air 2012 having root-on-UFS 10.2-RELEASE without ZFS. I think feedbacks using different firmware/platform would be valuable. Regards. On Mon, 1 Feb 2016 18:06:14 +0000 Steven Hartland 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 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 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@'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 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 wrote: > >>>>>> > >>>>>>> On 28/01/2016 16:22, Doug Rabson wrote: > >>>>>>>> On 28 January 2016 at 15:03, Tomoaki AOKI 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@freebsd.org mailing list > >>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >>>>>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > >>>>>>> > >>>>> _______________________________________________ > >>>>> freebsd-current@freebsd.org mailing list > >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >>>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > >>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> freebsd-current@freebsd.org mailing list > >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > >>> _______________________________________________ > >>> freebsd-current@freebsd.org mailing list > >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > >>> > >> > >> -- > >> Tomoaki AOKI junchoon@dec.sakura.ne.jp > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- 青木 知明 [Tomoaki AOKI] junchoon@dec.sakura.ne.jp MXE02273@nifty.com