GELI file systems unusable after "glabel label" operations

[Roland Smith]

On Fri, Jan 15, 2010 at 01:25:50AM -0600, Scott Bennett wrote:
> 
>      It has been a long time since I created those GELI partitions, but I
> think I used the "geli init -K keyfilename /dev/daXsYP", where P is the
> partition identifier in slice Y of drive X.  What I did when I screwed the
> pooch on this was of the form "glabel label fsname /dev/daXsYP", which I had
> thought would produce a /dev/label/fsname device and that doing a "geli attach"
> afterward would produce a /dev/label/fsname.eli device.

You could have done two things to create a nested label/geli configuration;

1) Create a labeled device from /dev/daXsYP, which would yield /dev/label/foo,
   then create a geli device _on the labeled device_, creating
   /dev/label/foo.eli. This will work because the labeled device will be one
   sector shorter than the raw da device. The .eli device will be yet another
   sector shorter, leaving two adjacent metadata sectors for the nested
   providers. This is the key point.

2) Create the geli device /dev/daXsYP.eli, and then create a label on that,
   yielding /dev/label/bar. [not sure what the utility of this is, since the
   label will only appear after the geil provider has been attached]

The first one seems most useful for things like automatic mounting.

> >Check /var/backups. There should be *.eli files there. Those are the automa=
> >tic
> 
>      No joy. :-(
> 
> >metadata backups that 'geli init' makes (at least in 8.0). You can restore
> >those backups with 'geli restore'.
> 
>      Those must be new in 8.0.  I don't see any in 7.2, just {aliases,group,
> master.passwd}.bak{,2} in /var/backups.

Probably. I didn't see them when I was running 7.2, and I only noticed it in
the 8.0 manpage.

> >Running 'geli init' again with the same parameters will not work, because
> >'geli init' uses a random component in the key generation. In other words, =
> >two
> >inits with the same password will not generate the same key!
> 
>      Is there some way to recover using the existing key files, which I do
> still have?  And of course, I do know the passphrases.

Not as I read the geli source. It _always_ uses arc4rand to generate a random
salt for the key during 'init'. Read the function 'static void eli_init(struct
gctl_req *req)' in /usr/src/sbin/geom/class/eli/geom_eli.c. This means that
subsequent 'geli init' calls with the same password or keyfile will still
yield a different key. I'm afraid your data is lost.

You should always make a backup before playing with filesystems. Most people
learn this the hard way, although I realize that this is small consolation.

> >What you should have done (for future refrence) is use geli(8) to create the
> >encrypted device, then create a filesystem on that encrypted device with
> >newfs(8) using the '-L' flag to set the volume name. Or use tunefs(8) to set
> >the volume name later. These names will be automatically recognized next ti=
> >me
> >you attach it and listed in /dev/ufs/.
> >
>      Thank you for that information.  If only it had been laid out that way
> in the man page of the handbook when I read it before starting on the labeling
> procedure...sigh.

It _is_ listed in the glabel manpage, at least in 8.0. 

And I think that the proper way to nest geoms is too obvious (at least for the
developers/maintainers) to explicitly list in the handbook. If you know that
geoms store metadata in their last sector, the proper way to nest them is to
use the different devices for each geom "stage", so that each has their own
metadata sector.

Procedure #1 that I outlined above should be easier to automate, should you
want to,  because you can then just use 'geli init /dev/label/foo'.

As of 7.2, each UFS filesystem automatically has an unique file system id that
is automatically created during boot in /dev/ufsid. These labels are unique
and do not change. You can use those to mount these filesystems. See §19.6 in
the latest version of the Handbook.

>      I have a new 1 TB drive that I will soon connect to the system and begin
> creating file systems.  I will make gzipped image files with dd(1) of the
> damaged partitions and store them on the new drive for a while in case a
> workable idea turns up.

Since the partitions are encrypted, don't bother with gzip. Encrypted data is
pretty close to random noise. No compression program can compress that vey
much. With the gzip header, it might even become bigger.

Roland
-- 
R.F.Smith                                   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20100115/964b2fca/attachment.pgp