On 06/03/2016 04:42 PM, Arno Wagner wrote:
One thing is that these problems are pretty hard to debug.
Another is that LVM massively complicates things.
Now, if the LUKS container opens cleanly, anything
in it should be decrypted correctly (if it is LVM
atop of LUKS) and decryption with the wrong key is
not actually a possibility.
That also means you should be able to use LVM
recovery techniques (I assume they exist) on this.
Unfortunately, I cannot help you with LVM as I do not use
it. I consider it a badly engineered, overly complicated
thing that decreases reliablity and makes problem
diagnostics very hard.
If the ASCII strings "LABELONE" and "LVM2" cannot be seen in the first
few sectors of the volume, then that volume is either overwritten or not
being decrypted correctly. LVM keeps quite a bit of easily recognized
ASCII data in the volume header.
In this case the fragile link seems to be the LUKS detached header, as I
believe there is nothing to associate that header with a device and
precise starting point for the payload. Yes, there is a check that the
master key was reconstructed correctly. Now the question is what, if
anything, does this key decrypt.
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
