From owner-freebsd-current@freebsd.org Sat Jan 30 12:43:34 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 7C9E8A71D22 for ; Sat, 30 Jan 2016 12:43:34 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 1414D1C69 for ; Sat, 30 Jan 2016 12:43:33 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: by mail-wm0-x232.google.com with SMTP id 128so14869709wmz.1 for ; Sat, 30 Jan 2016 04:43:33 -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=IDESiVibyXuzpUKrmjFmckoOWzEXJC4uiW6Hn4U8Oz8=; b=eF5FqHMWAlGWKBKjQ2+Tg3rI6evWaPw8yrTKPkEHnxTzpTgRzZPop96Q2v+6jlwMrg O1aODBEVwcdsVKNPezqBXMvSm6uc5yl2BCUNtj9+duIJY04NGpEgzIHp2gKDvIKmpksJ WQUMdBgVf04kZ2HUAM43hiRbHxbW1aMIOc8/QMneGLOAUvTOolsnSyLp/sPrNrD1qi5k yf0cdkOacchHtSvIIfrn1bEDf6FexChClDybvuiRlIm9HyIOaz0gzWsrFE3Nli+RXvC2 y1irX5lBOcur+TD0Y2cmpi3VbMxxIgRE5T3P1qoDWc41G9DDnvKBTiMezd8TUftZnm8B FAQQ== 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=IDESiVibyXuzpUKrmjFmckoOWzEXJC4uiW6Hn4U8Oz8=; b=M10Z8O7BtbLshyDLJpA3Df1vFPplBB2zHS94zHjeECCjx6VQ/jCbUzX/4gPb028/hl Z76mRhWWANLWuZuH4/kHn1yGUQN7A+qVb/z7xnhSib4zzj5r1bxbkreaJyMUXQm+AOr1 Vwz7r/9Sl1j0ep6X5VSlFpePdBAI0v+Rxz/Cd+ewSoDpAJi7Zqa1wFIZOKfnp1/jrkSM IUjNHavKccIj/R+BydDURW6RwM/JITKaTqJ2UnuWpyqI3APVfRFqXJUBpBc0wMEQPpWE +5Auc9MD4xn7nPxaaTHL0G2AHvEUzLKXPYvqJ1BFYE66E6sVrrUb0Uok+ABCi9vsgU08 XSLg== X-Gm-Message-State: AG10YOQ9cgNJXSwoDfqu9dN3xjOXzp0OWOC8RDOqQee1C+dpGAV0+MvDn/EAnSWYkZbVhM4rKt2nuxgtXB/eXbhJ MIME-Version: 1.0 X-Received: by 10.28.46.87 with SMTP id u84mr2706864wmu.102.1454157812029; Sat, 30 Jan 2016 04:43:32 -0800 (PST) Received: by 10.28.90.138 with HTTP; Sat, 30 Jan 2016 04:43:31 -0800 (PST) In-Reply-To: <20160130155755.485736c8e12868663b9ccfbc@dec.sakura.ne.jp> 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:43:31 +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 13:45:54 +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:43:34 -0000 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 you will get a lot more information about which disk is being used to load from 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 to 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 disable= d > 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 pleas= e > > 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.org > " >