[dm-crypt] "not a valid LUKS device" after distro change
jonas at freesources.org
Fri Aug 22 11:08:56 CEST 2014
Am 21.08.2014 um 22:46 schrieb John Wells:
> Attached below, I've included the output of running these commands from
> first Ubuntu and then Fedora. Note, apparently they map the raid device
> numbers differently. Also, you'll note there's a cryptd mounted in
> Ubuntu. That's the one i can successfully mount from Ubuntu.
> To make things even stranger, I was ***able to luksOpen and then mount
> /dev/MORE_VG/MORE_LV this time while booted in the Fedora 20*** live cd,
> while as you recall I was unable to before. I'm also including the
> results of dumping the head of the dev file from Fedora.
Actually I don't think that your experiences make it even stranger. Now
you've a consistent behavior of both distros: Ubuntu and Fedora both
recognize your MORE_LV in MORE_VG as a valid LUKS container. For the
moment I recommend to ignore the fact that Fedora once didn't see it.
That might be due to a bug in Fedora, due to a user error or whatever.
Important is, that now both distros see one LUKS container, and don't
> I'm completely at a loss. At this point I feel I should probably backup
> the entire machine and re-install from scratch, but I'll hold off a bit
> longer. The inconsistent behavior is really disconcerting.
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.
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.
According to your hexdump it's not astonishing at all that neither of
the distros do recognize the FINALFRONTIER_VG/HOME_LV logical volume as
LUKS container. It simply doesn't start with a LUKS header.
The question rather is: what action resulted in the LUKS header being
overwritten. In the past the partition configuration in the Ubuntu
installer was kind of confusing, and some people trashed their existent
LUKS containers by reformatting them as new LUKS container, but it
doesn't look like that happened to you.
I don't want to join the rant against modern Linux distros, LVM and MD-1
format here. In fact there've been quite some serious bugs in Linux
(vanilla kernel, userspace tools as well as distro implementations) in
the past, and ranting about how fucked up everything is today compared
to the good all days doesn't help to fix them. I prefer to isolate,
identify and fix the bugs and improve the user experience that way :)
More information about the dm-crypt