[dm-crypt] "not a valid LUKS device" after distro change

John Wells jbwellsiv at gmail.com
Thu Oct 30 01:37:41 CET 2014


Regarding using any tool like parted or gparted, no. Not directly that I
recall.

Regarding the use of /etc/crypttab, I wasn't using it. Since the first
failure, I've been very busy (as I mentioned), so each time I had to
reboot, I'd manually use "cryptsetup luksOpen /dev/MORE_VG/MORE_LV
cryptdev" and then "mount /dev/mapper/cryptdev /home", and then login.

Thanks for all the help. I'm back on the road but will investigate all
recommendations when I return. I'd be very, very interested to know the
culprit so that I know what and what not to trust in the future.

Thanks guys.

John

On Wed, Oct 29, 2014 at 7:49 PM, Sven Eschenberg <sven at whgl.uni-frankfurt.de
> wrote:

> Hi,
>
> I wanna jump in with some more hints:
>
> what actually was written to the disk is a loop device signature by
> libparted. This will be written, if you'd issue a parted mklabel loop
> /dev/MORE_VG/MORE_LV.
>
> If any other tool would write such a signature, it would have to use
> libparted most certainly.
>
> If the device given is a (virtual) disk and has any partition table with
> partition and fs on it the signature will not be written. (Well that
> explains why the LUKS header won't keep write_loop() from libparted from
> doing it's work).
>
> Anyway, if any other tool destroys the data it would have to call
> write_loop().
>
> ---
>
> Referring to Arno's mail:
>
> partx is non destructive and uses the code from util-linux'es libblkid.
> Probably not a cadidate.
>
> kpartx uses the device-mapper to create partition nodes on arbitary
> devices and is non destructive as far as the symbol table is concerned.
> Probably not a candidate either.
>
> I cannot guarantee for Ubuntu though - if they changed the code.. - you
> could do an objdump/ldd on these tools just to make sure.
>
> ---
>
> Anyhow, back on topic: udisks2 uses parted directly (calling out on it)
> and does destructive operations, but no trace of loop labels.
>
> Did you use any tool like parted or gparted between backup restore and
> failure?
>
> Regards
>
> -Sven
>
>
> On Tue, October 28, 2014 16:34, John Wells wrote:
> > Hi guys, I know I went silent on this. I ended up being on the road a
> good
> > bit and just restored from back up and accepted it as an isolated
> > incident.
> >
> > However, today I received some odd messages and the inability to write to
> > files.
> >
> > Now, after reboot, /dev/MORE_VG/MORE_LV is suddenly missing it's Luks
> info
> > as well.
> >
> > $ sudo cryptsetup luksOpen /dev/MORE_VG/MORE_LV cryptd
> > Device /dev/MORE_VG/MORE_LV is not a valid LUKS device.
> > $ sudo head -c 1024 /dev/MORE_VG/MORE_LV | hexdump -C
> > 00000000  47 4e 55 20 50 61 72 74  65 64 20 4c 6f 6f 70 62  |GNU Parted
> > Loopb|
> > 00000010  61 63 6b 20 30 00 00 00  00 00 00 00 00 00 00 00  |ack
> > 0...........|
> > 00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >  |................|
> > *
> > 00000400
> >
> > Recall, before this happened, it looked like this:
> >
> > # head -c 1024 /dev/MORE_VG/MORE_LV | hexdump -C
> > 00000000  4c 55 4b 53 ba be 00 01  61 65 73 00 00 00 00 00
> >  |LUKS....aes.....|
> > 00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >  |................|
> > 00000020  00 00 00 00 00 00 00 00  78 74 73 2d 70 6c 61 69
> >  |........xts-plai|
> > 00000030  6e 36 34 00 00 00 00 00  00 00 00 00 00 00 00 00
> >  |n64.............|
> > 00000040  00 00 00 00 00 00 00 00  73 68 61 31 00 00 00 00
> >  |........sha1....|
> > 00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >  |................|
> > 00000060  00 00 00 00 00 00 00 00  00 00 10 00 00 00 00 40
> >  |...............@|
> > 00000070  4e 94 98 c0 51 a9 25 bb  74 73 88 a4 a7 6e c7 d3
> >  |N...Q.%.ts...n..|
> > 00000080  6f 18 71 fa 94 9a f4 5e  d1 e8 5b 1a 34 3a 9f 9f
> >  |o.q....^..[.4:..|
> > 00000090  1d 79 1f 61 f5 dd 98 09  e1 d6 2e ed c4 29 af 1a
> >  |.y.a.........)..|
> > 000000a0  23 c9 59 da 00 00 77 a1  36 63 63 31 38 38 64 62
> >  |#.Y...w.6cc188db|
> > 000000b0  2d 63 63 64 62 2d 34 63  38 66 2d 39 37 62 32 2d
> >  |-ccdb-4c8f-97b2-|
> > 000000c0  65 34 31 31 39 38 65 63  36 65 34 34 00 00 00 00
> >  |e41198ec6e44....|
> > 000000d0  00 ac 71 f3 00 01 df d7  79 85 dd f0 29 59 98 63
> >  |..q.....y...)Y.c|
> > 000000e0  0b 69 80 fe 48 61 8c 40  5b 3b 57 0f 82 9c ae 90  |.i..Ha.@
> > [;W.....|
> > 000000f0  36 57 45 e2 03 82 26 c5  00 00 00 08 00 00 0f a0
> >  |6WE...&.........|
> > 00000100  00 00 de ad 00 00 00 00  00 00 00 00 00 00 00 00
> >  |................|
> > 00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >  |................|
> > 00000120  00 00 00 00 00 00 00 00  00 00 02 00 00 00 0f a0
> >  |................|
> > 00000130  00 00 de ad 00 00 00 00  00 00 00 00 00 00 00 00
> >  |................|
> > 00000140  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >  |................|
> > 00000150  00 00 00 00 00 00 00 00  00 00 03 f8 00 00 0f a0
> >  |................|
> > 00000160  00 00 de ad 00 00 00 00  00 00 00 00 00 00 00 00
> >  |................|
> > 00000170  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >  |................|
> > 00000180  00 00 00 00 00 00 00 00  00 00 05 f0 00 00 0f a0
> >  |................|
> > 00000190  00 00 de ad 00 00 00 00  00 00 00 00 00 00 00 00
> >  |................|
> > 000001a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >  |................|
> > 000001b0  00 00 00 00 00 00 00 00  00 00 07 e8 00 00 0f a0
> >  |................|
> > 000001c0  00 00 de ad 00 00 00 00  00 00 00 00 00 00 00 00
> >  |................|
> > 000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >  |................|
> > 000001e0  00 00 00 00 00 00 00 00  00 00 09 e0 00 00 0f a0
> >  |................|
> > 000001f0  00 00 de ad 00 00 00 00  00 00 00 00 00 00 00 00
> >  |................|
> > 00000200  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >  |................|
> > 00000210  00 00 00 00 00 00 00 00  00 00 0b d8 00 00 0f a0
> >  |................|
> > 00000220  00 00 de ad 00 00 00 00  00 00 00 00 00 00 00 00
> >  |................|
> > 00000230  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >  |................|
> > 00000240  00 00 00 00 00 00 00 00  00 00 0d d0 00 00 0f a0
> >  |................|
> > 00000250  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> >  |................|
> >
> > This has happened even though I haven't changed OSes. This is on Ubuntu
> > 14.04.
> >
> > And, sadly for me, my backup software was silently malfunctioning, so I
> > have lost a good bit of data in this case.
> >
> > Any ideas why a LUKS device would suddenly appear as a loopback device?
> > I'm
> > totally at a loss and not sure if I can trust luks any more with my data,
> > which is sad but understand considering what I paid for it. ;-)
> >
> > Thanks,
> > John
> >
> > On Fri, Aug 22, 2014 at 8:55 AM, Jonas Meurer <jonas at freesources.org>
> > wrote:
> >
> >> 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.
> >>
> >> Kind regards,
> >>  jonas
> >>
> >>
> >> _______________________________________________
> >> dm-crypt mailing list
> >> dm-crypt at saout.de
> >> http://www.saout.de/mailman/listinfo/dm-crypt
> >>
> > _______________________________________________
> > dm-crypt mailing list
> > dm-crypt at saout.de
> > http://www.saout.de/mailman/listinfo/dm-crypt
> >
>
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt at saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20141029/d4e15449/attachment-0001.html>


More information about the dm-crypt mailing list