Date: Wed, 1 Oct 2014 01:10:14 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: Karl Pielorz <kpielorz_lst@tdx.co.uk> Cc: Pawel Jakub Dawidek <pjd@freebsd.org>, freebsd-geom@freebsd.org Subject: Re: GELI created on a GPT labelled partition doesn't work 2nd time around... Message-ID: <20141001081014.GP43300@funkthat.com> In-Reply-To: <681D2CABAA14DC8E36AA60F0@study64.tdx.co.uk> References: <FB80B30D52FBD7A0500EF984@study64.tdx.co.uk> <20140928130547.GD1620@garage.freebsd.pl> <5A6D15305F99246DAE25673C@Mail-PC.tdx.co.uk> <20140930135445.GB43300@funkthat.com> <681D2CABAA14DC8E36AA60F0@study64.tdx.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jmg@funkthat.com>
> 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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141001081014.GP43300>