From owner-freebsd-current@freebsd.org Sun Jan 31 12:02:04 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 BF2F1A73339 for ; Sun, 31 Jan 2016 12:02:04 +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 6F4567E for ; Sun, 31 Jan 2016 12:02:04 +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 u0VC21P3003372; Sun, 31 Jan 2016 21:02:02 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 31 Jan 2016 21:02:01 +0900 From: Tomoaki AOKI To: Steven Hartland Cc: freebsd-current@freebsd.org Subject: Re: ZFSROOT UEFI boot Message-Id: <20160131210201.d0813113b2c73d995c28149c@dec.sakura.ne.jp> 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> 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: Sun, 31 Jan 2016 12:02:04 -0000 Sorry. I just noticed this mail is not a duplicate of which I just responded to. :-( I built boot1.efi that is applied Diff6 with -DEFI_DEBUG, but not with -DDEBUG. Was it sufficient? Or does some info be missed with above option I set? On Sat, 30 Jan 2016 12:43:31 +0000 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 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 〓 > 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=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 " > > > > > > > > > -- > > 青木 知明 [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 > > " > > -- 青木 知明 [Tomoaki AOKI] junchoon@dec.sakura.ne.jp MXE02273@nifty.com