From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <jonas@freesources.org>
Received: from mail01.freesources.org (mx01.freesources.org [80.237.252.132])
 (using TLSv1 with cipher AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mail.server123.net (Postfix) with ESMTPS
 for <dm-crypt@saout.de>; Fri, 22 Aug 2014 14:55:19 +0200 (CEST)
Received: from cb-hafen-75-9.rz.uni-frankfurt.de ([141.2.75.9])
 by mail01.freesources.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16)
 (Exim 4.72) (envelope-from <jonas@freesources.org>)
 id 1XKoNA-0003yu-Rp
 for dm-crypt@saout.de; Fri, 22 Aug 2014 12:55:19 +0000
Message-ID: <53F73DB4.8040804@freesources.org>
Date: Fri, 22 Aug 2014 14:55:16 +0200
From: Jonas Meurer <jonas@freesources.org>
MIME-Version: 1.0
References: <CADt3ZtscYzfFb2nhAfz8VYwMFf0jzWx8w5OzycfX2h7oaaPe9A@mail.gmail.com>
 <20140820090956.GA25262@tansi.org>
 <CADt3ZtscbX-rmMt++aXme9Oiu3sxiBW_MD_CGJM_b=t+iMaerQ@mail.gmail.com>
 <20140820211528.GA450@tansi.org>
 <CADt3Ztvq7OxX9Tn=k_anKkDXQ+viyXM6b8g+zQEc_yt=M96vSw@mail.gmail.com>
 <lt4vh4$uvc$1@ger.gmane.org>
 <CADt3Ztv0QKLAET_uo4cn06qi_z90jMVdfomJPbLH_rFN4PoTzw@mail.gmail.com>
 <53F61AA4.70309@freesources.org>
 <CADt3Ztsi2p_nA4h8mDeGanh3zr0RbLmi+qJ+t7NcBjt1QhTR=Q@mail.gmail.com>
 <53F708A8.8050705@freesources.org> <20140822115516.GC3837@tansi.org>
In-Reply-To: <20140822115516.GC3837@tansi.org>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [dm-crypt] "not a valid LUKS device" after distro change
List-Id: <dm-crypt.saout.de>
List-Unsubscribe: <http://www.saout.de/mailman/options/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=unsubscribe>
List-Archive: <http://www.saout.de/pipermail/dm-crypt/>
List-Post: <mailto:dm-crypt@saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Subscribe: <http://www.saout.de/mailman/listinfo/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=subscribe>
To: dm-crypt@saout.de

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,=20
>> 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.
>=20
> Not necessarily. The other container had that in it the one time as=20
> well, but it fixed itself ...

I'm not sure about that one. Event though John wrote earlier, that =BBboth
had the same "GNU Parted Loopback 0" in the output of "head -c 1024
/volume | hd"=AB, 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.
>=20
> I second searching for that. It may not be the only way though.
> Easy way to search:
>=20
> hd <partition> | grep "LUKS"
>=20
> That gives you hex offset(s) to examine further.=20

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.

Kind regards,
 jonas