From owner-freebsd-current@freebsd.org Sat Jan 30 19:12:25 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 772EEA73ED0 for ; Sat, 30 Jan 2016 19:12:25 +0000 (UTC) (envelope-from killing@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 0ABE01647 for ; Sat, 30 Jan 2016 19:12:25 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wm0-x231.google.com with SMTP id r129so20778604wmr.0 for ; Sat, 30 Jan 2016 11:12:24 -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=ePQqPqEhPFUMMCxL/4WvUNsFSQ4ltUPI/DjP2KCG/EE=; b=RbIwbr7jFoyTS6w5tfSlbnOslxnVOGHr9lm2mT8sO6RqDDdUilc7W08m+bRpNLOlJ6 9AYZ+eZKSOXTb67QMtYyqRtABKrSoJwni8W4h8uyN5aL6GaRjCh6yjCBapwHOgc/l9xC 9XNkR0cY9/R9Ldtqfka6OUXFuXLCRLfweLN9zg/0vXPDmPqGNgr4XmcLKxVUoRucVtFr w0ovyvZdV/jYNvbRnzTbHIrg9gEcsmfSD4WtPE4WD5XaEWhKIRXT4kxZNHwCBBfkR+7k kwQtXm+jAAMHRlo/ismePg4QBU/154G/Zy3EAN7XJD4XrQcAHzB9R7fgqms5lCLKcVYU quhw== 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=ePQqPqEhPFUMMCxL/4WvUNsFSQ4ltUPI/DjP2KCG/EE=; b=SCLi/rUQWtEH8/cgVn6LGdOW2tIfC0qxGgOIXzai9K3NvzRhMzyg+zE+0NivnYBxnf 9vmwzZp5E6uW1DeHdx31L34PRFK6EOiyRXGECcRx+oQJNSAiMllGLHnZkTReHRQ55tL4 cK1q5PELSSq/vMJVNq9GRmr7EAGcGHLWxorRvrTV7BggOC7ryi6VY+Ypkya+GNdu0bsE RzHDrnFwdEobLcpJWARvoCZoPpsD4Uj8JPeQ+QHETG8rOb83+RQN7Y6N0QRdCryF2N3R THERcEFOrl66c6R3bxNNeoDKQYksTqiAA09p/JM/7fYKilMQaaaN+zvIgHe4USAjbnkt DnBw== X-Gm-Message-State: AG10YOTwMq7INbIHoziYkt+k4mkJ7+uP3nQsM3kB/vupMKYwgxge6aX4TK7Fm/DV6uenzjT8 X-Received: by 10.28.22.199 with SMTP id 190mr3928346wmw.54.1454181142656; Sat, 30 Jan 2016 11:12:22 -0800 (PST) Received: from [10.10.1.58] (liv3d.labs.multiplay.co.uk. [82.69.141.171]) by smtp.gmail.com with ESMTPSA id u69sm3667514wmu.20.2016.01.30.11.12.21 for (version=TLSv1/SSLv3 cipher=OTHER); Sat, 30 Jan 2016 11:12:21 -0800 (PST) Subject: Re: ZFSROOT UEFI boot To: 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> From: Steven Hartland Message-ID: <56AD0B27.6030204@multiplay.co.uk> Date: Sat, 30 Jan 2016 19:12:39 +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: <20160130155755.485736c8e12868663b9ccfbc@dec.sakura.ne.jp> Content-Type: text/plain; charset=UTF-8; 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: Sat, 30 Jan 2016 19:12:25 -0000 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" >> >