From owner-freebsd-current@freebsd.org Sat Jan 30 12:53:48 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 247CFA7204E for ; Sat, 30 Jan 2016 12:53:48 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 A77561EE7 for ; Sat, 30 Jan 2016 12:53:47 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: by mail-wm0-x231.google.com with SMTP id l66so13808265wml.0 for ; Sat, 30 Jan 2016 04:53:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AnQ56y1x5Qd6io79tMT/tJ1N3xvwnpfQ7sDklI37sj8=; b=EY6nW2CuhmwrFYYxMafd8Jq6IohAver9Hp3BnKxvn/IthAaNzrvene7kxNYpHXXwqM 7mxfvExwmMVUk0cFjmsB8DNX0/OR8cTSTZ2tXiLeoq7iKncYGPI8o0TO2rgR5UfClRZ3 OwJE+ACSX6IE5QfJrbn11P9D3pmOBu26cGest7+sAeKTOgnKII5tIpP1MbmIhSzWZoww eNMOyJ76wtqSX9U3b8nmhjWK7/V0vd226RumlmC5/uxeaOipnk9eKgiIgJKp88PVvVkF LmZGyQsNOzi6DXw/PbnLLclsU2oDl1Zh0s9jKWaBj2wZ+I1t/8Dwd1WKB/qoLd6YPukT 6Q9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AnQ56y1x5Qd6io79tMT/tJ1N3xvwnpfQ7sDklI37sj8=; b=e5ce6escHAKHip3MzLA5eLx7rRj478MesQVuxNn37eMkcy9+qlbv0MAQfBRusrnvL5 Wwaw7AkPo60hEb+WmodBfLF6knASLoPUV+9sebqEUBvYNbrp8ODD0QLfDlJfyKJZqoDX XQRe7vs0uKKmBlDqn0vanf9xZhgXdnCcW6z8sN8EQCV3NyGO/TQPtj8Nka5i6ltUfqck tMOVgsPVijOIPT13cts5CuqcD5kY+9ZGuL9t0XmNaecTsU4S0bjcofAhMWb2M+2+W3/R NmNLWDkae/+O5A0ngAgdZ1ainf9WUbPsnClY6jwNDnYTPWgwAfFHn6c28J0Mvqnz2SkS lp6Q== X-Gm-Message-State: AG10YOQsEx2XQmysqRMVHdJKNQZIER9Y5CsM3bvSaoCr6B9PlS6bmqXTyk4zLQgOYzMvxtRXUGa/vkSZu/HHTYIW MIME-Version: 1.0 X-Received: by 10.28.101.131 with SMTP id z125mr2477726wmb.60.1454158426176; Sat, 30 Jan 2016 04:53:46 -0800 (PST) Received: by 10.28.90.138 with HTTP; Sat, 30 Jan 2016 04:53:46 -0800 (PST) In-Reply-To: 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> Date: Sat, 30 Jan 2016 12:53:46 +0000 Message-ID: Subject: Re: ZFSROOT UEFI boot From: Steven Hartland To: Tomoaki AOKI Cc: "freebsd-current@freebsd.org" X-Mailman-Approved-At: Sat, 30 Jan 2016 14:17:45 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Sat, 30 Jan 2016 12:53:48 -0000 I just realised an important point, does your usb disk have a UFS root partition and your internal disk ZFS root partition? If so then I know what the issue is, I'll have quick look now, so wait for a diff5 to appear before testing. On Saturday, 30 January 2016, Steven Hartland 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 yo= u > will get a lot more information about which disk is being used to load fr= om > 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 t= o > capture the output easily. > > Thanks for testing so far hopefully we can nail this soon =F0=9F=98=8A > On Saturday, 30 January 2016, 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=3Dno` in sys/boot/efi/boot1 didn't disabl= ed >> 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 correc= t >> > > 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 plea= se >> > 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" >> > >> >> >> -- >> =E9=9D=92=E6=9C=A8 =E7=9F=A5=E6=98=8E [Tomoaki AOKI] >> junchoon@dec.sakura.ne.jp >> MXE02273@nifty.com >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g >> " >> >