At Tue, 13 Jun 2006 12:46:06 +0200, Roman Medina-Heigl Hernandez <roman@xxxxxxxxxxx> wrote: > 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 Hm, lot of entropy. Have you checked the plain text for the partition start? Is it something reasonable with reasonable low-entropy? This is not going to help recovery in any way but I'm just curious. Maybe you have an intact ext3 backup superblock. I'm not sure where these things are placed by default but there seem to be plenty ext3 recovery howtos out there. You might want to try e2fsck, and further debugfs. Unfortunately both of these tools usually need a proper superblock. -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: sp4mtrap@xxxxxxxxxxxxx --------------------------------------------------------------------- - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
