Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 08 Oct 2013 23:28:10 +0200
From:      Nathan Whitehorn <nwhitehorn@freebsd.org>
To:        freebsd-current@freebsd.org
Subject:   Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
Message-ID:  <525478EA.8080207@freebsd.org>
In-Reply-To: <5254774C.8030204@pix.net>
References:  <52546844.2010608@freebsd.org> <5254774C.8030204@pix.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On 10/08/13 23:21, Kurt Lidl wrote:
>
> On 10/8/2013, 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.
>> 1a. The script is broken on sparc64 in any case, which uses VTOC8
>> instead of GPT.
>> 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.
>> 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.
>> 4. What is this gnop stuff for?
>> 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).
>> -Nathan
>
> I wrote some support for adding ZFS to the partition editor a couple of
> months ago, around the time that 9.2 was branched.  One of the biggest
> things that I have not done is integrate setting up a zfs mirror between
> any disks before creating the zpool.  Nor did I do the gnop hack to
> create 4K disk blocks before creating the pool.
>
> I more or less changed the partedit program to take an argument when
> invoked with "ufs" (same as current behavior) or "zfs", which knows
> about zfs setup stuff.  The hookup to the actual scripts was, shall
> we say, much less intrusive than what has been published here.
>
> I guess it's time to dig out the patches and make them available to
> others.

That would be great! The original idea was to have a "zfs_ops.c" to go
with "gpart_ops.c" and have some fields in the disk item struct that
said which to use. Not sure if that's ultimately workable, though. I can
hack on it once the patches are there in any case.
-Nathan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?525478EA.8080207>