From owner-freebsd-geom@FreeBSD.ORG Tue Sep 30 21:20:16 2014 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E384EB0; Tue, 30 Sep 2014 21:20:16 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id C8793ED4; Tue, 30 Sep 2014 21:20:15 +0000 (UTC) Received: from study64.tdx.co.uk (study64.tdx.co.uk [62.13.130.231]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s8ULKCxA039244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Sep 2014 22:20:12 +0100 (BST) Date: Tue, 30 Sep 2014 22:20:12 +0100 From: Karl Pielorz To: John-Mark Gurney 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: <20140928130547.GD1620@garage.freebsd.pl> <5A6D15305F99246DAE25673C@Mail-PC.tdx.co.uk> <20140930135445.GB43300@funkthat.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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: Tue, 30 Sep 2014 21:20:16 -0000 --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 :( 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