From owner-freebsd-geom@FreeBSD.ORG Wed Oct 1 08:10:15 2014 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C27FE622; Wed, 1 Oct 2014 08:10:15 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9B3CDA66; Wed, 1 Oct 2014 08:10:15 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s918AEac055862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Oct 2014 01:10:15 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s918AE5s055861; Wed, 1 Oct 2014 01:10:14 -0700 (PDT) (envelope-from jmg) Date: Wed, 1 Oct 2014 01:10:14 -0700 From: John-Mark Gurney To: Karl Pielorz Subject: Re: GELI created on a GPT labelled partition doesn't work 2nd time around... Message-ID: <20141001081014.GP43300@funkthat.com> Mail-Followup-To: Karl Pielorz , Pawel Jakub Dawidek , freebsd-geom@freebsd.org References: <20140928130547.GD1620@garage.freebsd.pl> <5A6D15305F99246DAE25673C@Mail-PC.tdx.co.uk> <20140930135445.GB43300@funkthat.com> <681D2CABAA14DC8E36AA60F0@study64.tdx.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <681D2CABAA14DC8E36AA60F0@study64.tdx.co.uk> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 01 Oct 2014 01:10:15 -0700 (PDT) Cc: Pawel Jakub Dawidek , freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 08:10:16 -0000 Karl Pielorz wrote this message on Tue, Sep 30, 2014 at 22:20 +0100: > --On 30 September 2014 06:54:45 -0700 John-Mark Gurney > wrote: > > >gpt doesn't let you do gpt in gpt.. which explains why you can't > >create the second level of gpt... > > > >Why do you want/need to partition again? You could possibly use bsd > >as the second layer... > > Ok, if GPT in GPT isn't supported - I can live with that. Annoyingly - the > setup did work *once* when I first did it - but didn't subsequently... > > I've kind of worked around the problem now by using shell script to do the > GELI attach - which gets a list of all drives on the system - then ties > them by serial number (fetched from the drive) to their keys. > > I needed to do this as the drives can 'move' (so da6 this boot, may not be > da6 next boot). This also happens when new drives are added to the > controller (others may get 'shuffled' aside next boot). Using GPT let me > abstract that away (by giving each drive a GPT labeled partition the same > as it's serial number, which is written on the caddy). I've already tried > wiring the bays down - but you can't with this controller :( So, I've been using glabel and gpt labels for this... I have a script that does: (cd $keydir && for i in *.key; do geli attach -p -k "$i" "label/${i%.key}" geli attach -p -k "$i" "gpt/${i%.key}" done) || exit 5 > The attach-2-serial-number workaround works for now - and at least I know > why GPT doesn't work (reliably/at all now!) when nested. We definately need to think about how to manage keys in a better, more reliable way on FreeBSD... Your serial number way is one way to handle it, though it appears that there is also an md5 hash that you can obtain via geli dump... Though this hash will change if you change keys on the device... So, you could possible use this instead of serial numbers... We might want to create a random uuid or we could do a uuid based upon the WWN + geom path to the provider and in that case would be globally unique and solve the "problem" of when a geli drive is duplicated that we'd have the same uuid for potentially two different sets of data... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."