Date: Tue, 8 Oct 2013 20:50:30 +0000 From: "Teske, Devin" <Devin.Teske@fisglobal.com> To: Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: "<freebsd-current@freebsd.org>" <freebsd-current@freebsd.org>, "Teske, Devin" <Devin.Teske@fisglobal.com>, Allan Jude <freebsd@allanjude.com> Subject: Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI Message-ID: <13CA24D6AB415D428143D44749F57D720FC46255@LTCFISWMSGMB21.FNFIS.com> In-Reply-To: <52546844.2010608@freebsd.org> References: <52531295.7090700@allanjude.com> <52546844.2010608@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >>=20 >> 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. >>=20 >>=20 >> 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 >>=20 >>=20 >> You can browse the patches here: >> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ >>=20 >> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier, >> available compressed (48 MB) or uncompressed (211 MB): >>=20 >> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz >>=20 >> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso >>=20 >>=20 >> We look forward to your feedback >>=20 >=20 > 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 wo= uld be better to just stick to one tool? or to query a few? (which ones win-out?) > 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) > 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) wor= k? --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13CA24D6AB415D428143D44749F57D720FC46255>