Quote:
Originally Posted by carlitoco
no its totaly a deifferent thing!
|
OK. On a different machine?
Quote:
Originally Posted by carlitoco
i've make a testdisk run on the crypted /dev/sdc1, ! I dont decrypted it before!
|
You mean you ran 'testdisk' and allowed it to "correct" (perceived) errors?
Quote:
Originally Posted by carlitoco
TestDisk 6.10, Data Recovery Utility, July 2008
|
That's an old version. In this case newer == bug fixes, more features == better.
* BTW it would be more efficient/better to post/attach the unobfuscated "testdisk.log" from running 'testdisk /debug /log /dev/sdc'.
Quote:
Originally Posted by carlitoco
Code:
Partition table type (auto): None
Partition table type: Intel
|
I don't know if it's a telltale sign but detection did not automagically see the disk as having a Intel partition table.
* Please post output from running 'fdisk -l /dev/sdc'.
Quote:
Originally Posted by carlitoco
Code:
Geometry from i386 MBR: head=116 sector=52
|
Maybe somebody else could comment if CHS/LBA translation looks OK.
Quote:
Originally Posted by carlitoco
Code:
check_part_i386 1 type 6B: no test
check_part_i386 2 type 75: no test
check_part_i386 3 type 41: no test
|
AFAIK the PT (partition table) should list one partition (or one used and 3 empty as per default DOS PT?), so to me this looks like partition table corruption or guesswork filling it in.
Quote:
Originally Posted by carlitoco
Code:
search_part()
Disk /dev/sdc - 400 GB / 372 GiB - CHS 48641 255 63
D Linux 0 1 1 0 33 40 2056
LUKS 1 (Data size unknown), 1052 KB / 1028 KiB
|
OK, so at least it found *something*... What I'd do is confirm 'testdisk' is using the right disk geometry as advertised by your BIOS and verify that with 'dmesg' output when booting from Live CD or from previosuly saved 'sfdisk -' or 'fdisk -' output. Then I'd make a 'dd' backup of the whole disk before mucking around. Better safe than sorry. Then, if you have a backup of your MBR/PT, restore that. If you don't have a backup you could let 'testdisk' (or 'fdisk') write a pristine MBR and PT (that's why you make backups). This should not affect the encrypted volume (as it starts after PT+some bytes) so this should also not affect the LUKS phdr and keys as they reside inside the partition (the phdr being written before the payload but is there a backup phdr written by default? Hopefully somebody could chip in details). Anyway, first things first: best post full output as requested.
