[dm-crypt] "not a valid LUKS device" after distro change
jonas at freesources.org
Fri Aug 22 14:55:16 CEST 2014
Am 22.08.2014 um 13:55 schrieb Arno Wagner:
> On Fri, Aug 22, 2014 at 11:08:56 CEST, Jonas Meurer wrote:
>> Hi John,
>> Am 21.08.2014 um 22:46 schrieb John Wells:
>> As Arno already wrote, the hexdump from your meant-to-be LUKS container
>> on HOME_LV in FINALFRONTIER_VG doesn't look too promising. I've never
>> heard about 'GNU Parted Loopback 0' before, but it sounds like something
>> caused Parted to overwrite your LUKS header.
> Not necessarily. The other container had that in it the one time as
> well, but it fixed itself ...
I'm not sure about that one. Event though John wrote earlier, that »both
had the same "GNU Parted Loopback 0" in the output of "head -c 1024
/volume | hd"«, so maybe you're correct.
>> Last hope is to find the LUKS header with an offset on the partition.
>> Try to search for 'LUKS' by grepping the output of 'strings
>> /dev/FINALFRONTIER_VG/HOME_LV'. If you don't find the string 'LUKS'
>> followed by something describing your cipher and hash algorithm, I fear
>> that this second partition is lost.
> I second searching for that. It may not be the only way though.
> Easy way to search:
> hd <partition> | grep "LUKS"
> That gives you hex offset(s) to examine further.
Maybe the best is to grep the whole physical partition for "LUKS"
instead of just searching on the LVM logical volume device. If it's
really linux-md or lvm that mix things up here, then one should not
trust in alignment and layering by them.
So, John, best would be to do
# hd /dev/sdc | grep "LUKS"
# hd /dev/sdd | grep "LUKS"
(given that sdc and sdd are the disks with md raid-1 and lvm on top).
If I got your setup right, then FINALFRONTIER_VG-HOME_LV is the only
LUKS-encrypted lv on these disks. Thus, when you get a result, try to
extract the LUKS header from it using the offset and check its validity.
More information about the dm-crypt