From owner-freebsd-current@FreeBSD.ORG Tue Oct 8 20:56:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id ACE2AC95 for ; Tue, 8 Oct 2013 20:56:42 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from smtpauth3.wiscmail.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7B82820C5 for ; Tue, 8 Oct 2013 20:56:42 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MUD00G009KKV100@smtpauth3.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Tue, 08 Oct 2013 15:56:41 -0500 (CDT) X-Spam-PmxInfo: Server=avs-3, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.10.8.204831, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from wanderer.tachypleus.net (unknown [140.105.20.242]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MUD006ZUBIEUX40@smtpauth3.wiscmail.wisc.edu>; Tue, 08 Oct 2013 15:56:40 -0500 (CDT) Message-id: <52547185.2000009@freebsd.org> Date: Tue, 08 Oct 2013 22:56:37 +0200 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 To: "Teske, Devin" Subject: Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI References: <52531295.7090700@allanjude.com> <52546844.2010608@freebsd.org> <13CA24D6AB415D428143D44749F57D720FC46255@LTCFISWMSGMB21.FNFIS.com> In-reply-to: <13CA24D6AB415D428143D44749F57D720FC46255@LTCFISWMSGMB21.FNFIS.com> X-Enigmail-Version: 1.5.2 Cc: "" , Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Tue, 08 Oct 2013 20:56:42 -0000 On 10/08/13 22:50, Teske, Devin wrote: > On Oct 8, 2013, at 1:17 PM, Nathan Whitehorn wrote: > >> On 10/07/13 21:59, Allan Jude wrote: >>> Devin Teske and I have been working on a big patch to bsdinstall to >>> implement installing on a ZFS pool. It supports both GPT and MBR, the 4k >>> sector gnop trick, and optional GELI encryption. We would like to commit >>> this in time for 10.0-BETA1 so it needs some testing to work out any >>> obvious bugs before we send it off to re@ to get it committed. >>> >>> It includes a single configuration menu that allows you to select all of >>> the required details, including which drives to use (gets details from >>> camcontrol, also includes an inspection utility that presents the >>> detailed output of camcontrol inquiry/identify, and gpart show), what >>> ZFS RAID level to use (taking in to consideration the selected number of >>> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc. >>> >>> >>> Additional, it includes some other changes to bsdinstall: >>> 1. Change the default to the 'non-standard keyboard mapping' prompt to no >>> 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1 >>> 3. Remove the dialog asking if you wish to enable crash dumps, this >>> feature has been combined into the regular 'services to enable' dialog >>> and enabled by default >>> >>> >>> You can browse the patches here: >>> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ >>> >>> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier, >>> available compressed (48 MB) or uncompressed (211 MB): >>> >>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz >>> >>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso >>> >>> >>> We look forward to your feedback >>> >> Thanks for doing this! I had a few comments: >> 1. ZFS is not bootable on all architectures. Could you adjust that menu >> item to only display for i386, amd64, and (I think?) sparc64. Use uname >> -m, not -p, for this. > I think we can do that no problem. > > >> 1a. The script is broken on sparc64 in any case, which uses VTOC8 >> instead of GPT. > *nods* we'll have to purloin your VTOC8 code before we offer it to > sparc64. > > > >> 2. Why are you using camcontrol? That is guaranteed not to work on >> non-CAM systems. You should use the GEOM ident string if you need an ID. > I imagine we could get the info from many places, and to be honest, I never > knew about "diskinfo" until last week (but apparently it's been around since > 5.x days). > > The one place where I suspect camcontrol(8) usage is appropriate is the > mini "disk inspector" dialog. The camcontrol inquiry output is specifically > helpful if/when you're doing multipathing (and you need to identify which > da# devices are duplicates of the same device -- given Serial#). > > But I gather you mean for "disk description" in the device menu (for picking > text to go along with the device name). > > I'm open to using a different tool... or multiple tools. Do you think it would be > better to just stick to one tool? or to query a few? (which ones win-out?) Absolutely all information you could possibly want is inside GEOM, including disk serial numbers. It the Correct Place (tm) for whatever information you want to get. > >> 3. Any plans to integrate this into the regular partition editor? ZFS >> support is important enough that I will definitely not get in the way, >> even as a bolt-on, but it would be a shame for it to stay that way. The >> editor is also designed for ZFS to be added. > Yes and yes. (and didn't know the editor was designed for ZFS too) Great! >> 4. What is this gnop stuff for? > Thanks goes to Freddie Cash for his excellent explanation (I had to > admit, I didn't understand it at that level) > > >> 5. I think some substantial part of the MBR code will blow up if you are >> reinitalizing a previously formatted disk (the bsdlabel will be retasted >> and come back from the dead). > Will not some combination of "gpart destroy -F" and (insert suggestion) work? Yes, that will work just fine. -Nathan