Hello,
I need urgent help :-( My data partition (150 GB aprox.) is damaged and I
cannot mount it. It was dm-encrypted and it was working ok.
I usually mount it as follows:
# cryptsetup -c aes create crypt /dev/hdd1
<enter passwd>
# mount /dev/mapper/crypt /mnt
[for recovery attemps I'm using "cryptsetup -r" for readonly mode]
Now, when I try to mount it with the correct password I could see:
[root@jupiter ~]# mount /dev/mapper/crypt /mnt -o ro
mount: you must specify the filesystem type
[root@jupiter ~]# mount -t ext3 /dev/mapper/crypt /mnt -o ro
mount: wrong fs type, bad option, bad superblock on /dev/mapper/crypt,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
[root@jupiter ~]# dmesg | tail
...
hfs: unable to find HFS+ superblock
VFS: Can't find ext3 filesystem on dev dm-4.
I know that the password I'm using is the right one, not only because I
remember it (of course), but I also tried:
# strings /dev/mapper/crypt | less
And I could see correct strings (filenames, for instance).
If I use a wrong password to create the crypt device (with -r option for
not damaging the partition more), strings doesn't show anything useful. So
I could assume the password is not the problem.
I also tried:
[root@jupiter ~]# dumpe2fs /dev/mapper/crypt
dumpe2fs 1.38 (30-Jun-2005)
dumpe2fs: Bad magic number in super-block while trying to open
/dev/mapper/crypt
Couldn't find valid filesystem superblock.
[root@jupiter ~]# dumpe2fs -ob 32768 -oB 4096 /dev/mapper/crypt
dumpe2fs 1.38 (30-Jun-2005)
dumpe2fs: No such file or directory while trying to open 32768
Couldn't find valid filesystem superblock.
Another curious issue I've seen is:
[root@jupiter ~]# hexdump < /dev/mapper/crypt | head -10
0000000 efd2 aa03 24e5 38e4 6b81 f0a6 e5df f686
0000010 9142 e97a 4390 a64f 3365 e81c 6a8d 809c
0000020 9bb5 1858 d643 2d2c 32cf 87f8 1830 d625
0000030 763e 1657 84da 6104 d902 41cf fb8f 1305
0000040 e69d 6d55 2be1 b442 f87d d800 b175 613e
0000050 838a 8746 be55 5273 4c66 e79b 9d34 c58e
0000060 5530 8fda 285b 2b71 71a5 9f6f 2b51 4e3d
0000070 abb8 ed7c 0c84 35ef 29bd f155 17be 1275
0000080 13b0 ce1c 5c6a 91d4 3f4f 4e80 5c0d 6e50
0000090 4f1a 4f29 d2b4 d369 b9a9 9351 86c3 97de
which compared with a correct ext3 fs (/dev/hda1) doesn't show 0-blocks at
the beginning, as in:
[root@jupiter ~]# hexdump < /dev/hda1 | head -10
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0000400 65f8 0000 97c4 0001 1463 0000 54b9 0001
0000410 65d4 0000 0001 0000 0000 0000 0000 0000
0000420 2000 0000 2000 0000 07d8 0000 6d72 448e
0000430 6d72 448e 000c ffff ef53 0001 0001 0000
0000440 cbf2 444f 0000 0000 0000 0000 0001 0000
0000450 0000 0000 000b 0000 0080 0000 003c 0000
0000460 0006 0000 0001 0000 60ef efc4 9cc5 724d
0000470 c381 e52e fb31 a7a3 622f 6f6f 3174 0000
(I also tried other right ext3 fs and it always shows 0-blocks)
Please, do you have any ideas / suggestions? I'm desperate.
More info: it's a 160GB HD, partitioned with one only big primary
partition: /dev/hdd1, which is dm-crypted partition (containing an ext3 fs
when "decrypted").
1) Has there been any recent change in dm-crypt / lib-devmapper or similar?
Any change in default encryption mode or things like that?
2) I have another 160 GB, where I'm performing (well, trying...) the
recovery process (I dd'ed the original HD). Perhaps it would be a good idea
to try a commercial ext3 recovery, but they run on Windows and I'd need to
decrypt the partition first. Do you see any problem if I do something like:
# fdisk /dev/hdb (2nd 160GB HD). I use the same layout as /dev/hdd (160GB
original "damaged" disk).
# dd if=/dev/mapper/crypt of=/dev/hdb1 bs=512M (I have 700+ MB RAM)
Doing so, I think I should get a disk-replica with decrypted partition, so
I could apply normal ext3 recovery methods (for instance, Windows
commercial programs working on the disk). Or I'm missing something?
Any help would be appreciated. Thanks in advance.
PS: I forgot to mention that it doesn't seem a mechanical failure or
damaged hard-disk unit. It seems that only a software failure caused
damaged partition).
Cheers,
-Román
---------------------------------------------------------------------
- http://www.saout.de/misc/dm-crypt/
To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx
For additional commands, e-mail: dm-crypt-help@xxxxxxxx
