On Fri, 15 Jan 2010 23:18:40 +0100 Roland Smith <rsm...@xs4all.nl>
wrote:
>On Fri, Jan 15, 2010 at 01:25:50AM -0600, Scott Bennett wrote:
>>=20
>> 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 a=
>ttach"
>> 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/f=
>oo,
> 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 anoth=
>er
> 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 important point here is that one of the above methods must be used
*before* the file system is created and the data loaded into it. Attempting
either method *after* data are loaded will result in loss of the data.
>The first one seems most useful for things like automatic mounting.
Okay. Thanks for the two methods.
>
>> >Check /var/backups. There should be *.eli files there. Those are the aut=
>oma=3D
>> >tic
>>=20
>> No joy. :-(
>>=20
>> >metadata backups that 'geli init' makes (at least in 8.0). You can resto=
>re
>> >those backups with 'geli restore'.
>>=20
>> Those must be new in 8.0. I don't see any in 7.2, just {aliases,gro=
>up,
>> 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 word=
>s, =3D
>> >two
>> >inits with the same password will not generate the same key!
>>=20
>> 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 rand=
>om
>salt for the key during 'init'. Read the function 'static void eli_init(str=
>uct
>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.
Perhaps this provides a possible recovery method. As you read it,
would it be possible to build an altered version of geli(8) that would simply
use the existing key file without generating a new one to do a "geli init"
operation? If so, it would certainly be worth my trouble to do that.
>
>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.
As I wrote previously, I had backups. My error was in labeling both
the original partition *and* the partition containing the backup series at
the same time. If I hadn't tried to save a reboot and a few other trivial
operations and had instead labeled only the original data partition at first,
I would have discovered the problem in time to rebuild the original correctly
from the backups. Sigh.
>
>> >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=3D
>> >me
>> >you attach it and listed in /dev/ufs/.
>> >
>> Thank you for that information. If only it had been laid out that w=
>ay
>> in the man page of the handbook when I read it before starting on the lab=
>eling
>> procedure...sigh.
>
>It _is_ listed in the glabel manpage, at least in 8.0.=20
I don't have 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.
Well, it wasn't at all obvious to me, and reading the parts that mention
metadata being written to the last sector suggests, if anything, that labeling
and encryption are incompatible because both write to the "last sector", i.e.,
to the *same* sector. The idea of the "last sector" being different for the
two operations is not at all apparent.
>
>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 t=
>hat
>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 =A719.=
>6 in
>the latest version of the Handbook.
>
>> I have a new 1 TB drive that I will soon connect to the system and b=
>egin
>> 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.
>
True enough, but sometimes one gets lucky. Given that the storage time
might be rather long in hopes of eventually turning up a solution, I was
thinking that I would try it both ways. If there were little difference in
size between the raw and the compressed versions, then I would probably just
keep the raw version. OTOH, if the compressed version were a few percent
smaller, then I would keep that one instead.
Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet: bennett at cs.niu.edu *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
* -- Gov. John Hancock, New York Journal, 28 January 1790 *
**********************************************************************
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
