From owner-freebsd-current@freebsd.org Mon Feb 1 16:18:53 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 497F3A97FB2 for ; Mon, 1 Feb 2016 16:18:53 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CFC95FF4 for ; Mon, 1 Feb 2016 16:18:52 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wm0-x233.google.com with SMTP id 128so78797069wmz.1 for ; Mon, 01 Feb 2016 08:18:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=30KwSzOkt9HCeEbMGKjCziQd8MDxPazaC2jexc4im64=; b=ldB/7+UkDrRmrsQ4zDO+FpQC2AQ3NmZ93VNnLC+R4Fc9S/2+6s+4zqjGRKUQWDCU2t Az7MbWvz8+LVeSSsA5DteA5mr27j4hAMz0Dt2rHXH7lrjLUF/r7lirIcnOj4YCcUhGgo BylNuFn7y7eDMqvrM51rHtKgIfSiFm5yJpUXPtqL8Sw+suRQvxV/8CXjrxWmyU/g2bTb /IPzLy4RQXhsqulOxJu6S6iqrNi8bVqbQC3Np0zMtJtlvRcTfwHGq7eMOf1Gs72MNAVs pDzdm5qk8Ww1tOOd04WRmZs28xKwPfNluYeDGw5nxQuTFWEKjPFaFT4A4F2rnrgr9Myh stGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=30KwSzOkt9HCeEbMGKjCziQd8MDxPazaC2jexc4im64=; b=AAgJvm/svWWXVamLMKvrYJAyqQS6RjN8ZRf/aN9fLkWbqQcvVEDbZ6amsaq3MLLvuW juhvLF2tWqaBmZHk5sgEKyOVCwfwindz5hsFY/7xYDScB4axKX0MwRSy694PkUt9qcXU 8oQv7sFb6EWf+Px6/lPHI0mjta8PPe3RijlKwtW1DgG9Qi+aUpQMTAC80AIjO5mYyao+ TEgyRKX29cLUEuVvzlEKJesOlMzd2Yog+tMZHHCcfZ99w08cVcncpbUfmpbY57BR39EN 6GvmrsuIUejoVzFDdONq9ngdK/vGrvCP2R5kdDJroMPSijyuko1IhFk1dE2AJj/j6T2s WIjQ== X-Gm-Message-State: AG10YOSd9vFo6ns9nk56RV6/CloT3tVrupQOYHN9D0z/iJZR0d7nyB7NFBHFC7FOE4/beehf X-Received: by 10.28.1.210 with SMTP id 201mr12980368wmb.90.1454343531278; Mon, 01 Feb 2016 08:18:51 -0800 (PST) Received: from [10.10.1.58] (liv3d.labs.multiplay.co.uk. [82.69.141.171]) by smtp.gmail.com with ESMTPSA id cb2sm29952454wjc.16.2016.02.01.08.18.50 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Feb 2016 08:18:50 -0800 (PST) Subject: Re: ZFSROOT UEFI boot To: Tomoaki AOKI , freebsd-current@freebsd.org 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> From: Steven Hartland Message-ID: <56AF857E.5020203@multiplay.co.uk> Date: Mon, 1 Feb 2016 16:19:10 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160201233627.b02ada486133cca3c2eec9ad@dec.sakura.ne.jp> Content-Type: text/plain; charset=windows-1252; format=flowed 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: Mon, 01 Feb 2016 16:18:53 -0000 Hmm, this doesn't look right:- 1) Boot from ada0 WITHOUT USB memstick and ada1 attached (single drive). boot1 imagepath: pciroot(0x0):pci(0x1f,0x02):sata(0x1,0x0,0x0):hd(1) probing: pciroot(0x0):pci(0x1f,0x02):sata(0x0,0x0,0x0) probe: . not supported probing: pciroot(0x0):pci(0x1f,0x02):sata(0x1,0x0,0x0) probe: . not supported probing: pciroot(0x0):pci(0x1f,0x02):sata(0x0,0x0,0x0):hd(1) probe: . not supported probing: pciroot(0x0):pci(0x1f,0x02):sata(0x0,0x0,0x0):hd(2) probe: . not supported probing: pciroot(0x0):pci(0x1f,0x02):sata(0x0,0x0,0x0):hd(3) probe: . not supported probing: pciroot(0x0):pci(0x1f,0x02):sata(0x0,0x0,0x0):hd(4) probe: + supported probing: pciroot(0x0):pci(0x1f,0x02):sata(0x0,0x0,0x0):hd(5) probe: + supported This is saying you booted from ada0 "pciroot(0x0):pci(0x1f,0x02):sata(0x1,0x0,0x0):hd(1)" but then the device list didn't find that but it did find: "pciroot(0x0):pci(0x1f,0x02):sata(0x0,0x0,0x0):hd(1)" so sata(0x1,... vs sata(0x0,.... could you double check this result please? This is re-enforced by the fact the test 2 booted from ada0 "boot1 imagepath: pciroot(0x0):pci(0x1f,0x02):sata(0x0,0x0,0x0):hd(1)". The missing "supported (preferred)" even when there looks like there should be match is something I need to check. Regards Steve It says t On 01/02/2016 14:36, 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" >> >