Date: Tue, 30 Sep 2014 22:20:12 +0100 From: Karl Pielorz <kpielorz_lst@tdx.co.uk> To: John-Mark Gurney <jmg@funkthat.com> 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: <681D2CABAA14DC8E36AA60F0@study64.tdx.co.uk> In-Reply-To: <20140930135445.GB43300@funkthat.com> References: <FB80B30D52FBD7A0500EF984@study64.tdx.co.uk> <20140928130547.GD1620@garage.freebsd.pl> <5A6D15305F99246DAE25673C@Mail-PC.tdx.co.uk> <20140930135445.GB43300@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 :( 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. -Karl
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?681D2CABAA14DC8E36AA60F0>