From owner-freebsd-questions@freebsd.org Sat Oct 7 11:35:55 2017 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB1A4E36156 for ; Sat, 7 Oct 2017 11:35:55 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 596FF2C68 for ; Sat, 7 Oct 2017 11:35:55 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [78.35.164.83] (helo=fabiankeil.de) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1e0nOC-000774-4x; Sat, 07 Oct 2017 13:35:28 +0200 Date: Sat, 7 Oct 2017 13:35:32 +0200 From: Fabian Keil To: Jonathan Bond-Caron Cc: "freebsd-questions@freebsd.org" Subject: Re: GELI disk and glabel label Message-ID: <20171007133532.0c647a07@fabiankeil.de> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/RS7wJZ7nbIi3BqCVEpqrNXk"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 11:35:55 -0000 --Sig_/RS7wJZ7nbIi3BqCVEpqrNXk Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Jonathan Bond-Caron wrote: > I was trying to organize hard disk using labels and labelled two geli > disks: https://marc.info/?l=3Dfreebsd-questions&m=3D147526341300616&w=3D2 Note that this post seems to be about gpt labels, not about glabel labels. They are not the same kind of label (and there are various other types of labels in FreeBSD). As you have just discovered, sometimes the difference matters. > glabel secure /dev/da1 > galbel backups /dev/da2 >=20 > The problem is now I can't mount them :/ > geli attach -k /root/geli.key > geli: Cannot read metadata from /dev/da1 As Bernt already explained, that's the expected behaviour. While it's possible to relocate the geli metadata, before adding a "glabel label", the process is a bit tedious and I wouldn't recommend trying it unless you already know that your backups work. > Is there anything I can do to 'revert' the glabel operation? If I have a > backup of these disks, can I grab the metadata from them and restore the > data? If you have a backup of the whole disk, you can extract the geli metadata with "geli backup ..." and restore it with "geli restore ..." which will also overwrite the "glabel label". See the geli man page for details. Note that "geli init ..." creates metadata backups by default, so you may want to look for those as well. Here's an example from one of my servers: [fk@elektrobier3 ~]$ ls -l /var/backups/*.eli -rw------- 1 root wheel 512 Jun 3 14:09 /var/backups/gpt_dpool-ada0.eli -rw------- 1 root wheel 512 Jun 5 21:26 /var/backups/gpt_dpool-ada1.eli -rw------- 1 root wheel 512 Jun 3 14:09 /var/backups/gpt_dpool-ada2.eli -rw------- 1 root wheel 512 Jun 3 14:09 /var/backups/gpt_dpool-ada3.eli While the system has an encrypted rpool as well, the geli metadata backups for the vdevs are located elsewhere as the pool was created at install time. Given that /var/backups is on the rpool, I can't access it without access to the rpool vdevs anyway, so it wouldn't be the greatest location for the geli metadata backups in the first place. Fabian --Sig_/RS7wJZ7nbIi3BqCVEpqrNXk Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTKUNd6H/m3+ByGULIFiohV/3dUnQUCWdi8BAAKCRAFiohV/3dU nelmAJ46M0/qt9S4uyCgNxSavEg0RWfC+gCeOkklEdX8QOj4TdgjUkPb9uweLAs= =FIV8 -----END PGP SIGNATURE----- --Sig_/RS7wJZ7nbIi3BqCVEpqrNXk--