GELI disk and glabel label
Fabian Keil
freebsd-listen at fabiankeil.de
Sat Oct 7 11:35:55 UTC 2017
Jonathan Bond-Caron <jbondc at gdesolutions.com> wrote:
> I was trying to organize hard disk using labels and labelled two geli
> disks: https://marc.info/?l=freebsd-questions&m=147526341300616&w=2
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
>
> 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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20171007/476c3523/attachment.sig>
More information about the freebsd-questions
mailing list