[solved]dm_crypt/LUKS: corrupted partition

spiri13 · 06-20-2016, 11:01 AM

Hi,

I think I've corrupted my filesystem!
I did

Code:

cryptsetup luksFormat /dev/sdb2

on my partition with all my data.

Then I have corrupted the filesystem with e2fsck.
I ran e2fsck on my partition an cleaned up to 30 inodes, then I canceled the operation. Now the password does not match anymore

So first I made a backup of the damaged filesystem using ddrescue...
Then I tried to rewrite the LUKS header using the same password as before.

Code:

cryptsetup luksFormat data.img

Then I tried to mount the partition, but the filesystem type could not be found:

Code:

$ cryptdisk luksOpen data.img cryptdisk
password entered
$ mount -o ro /dev/mapper/cryptdisk /mnt
mount: wrong fs type, bad option, bad superblock on /dev/mapper/cryptdisk

I already tried to convert the filesystem back to ext4 using anyfs-tools but there is a missing program called build_e2fs which i can't find in the arch user repositories.

Where do I find the package which includes build_e2fs?
Is there alternatively any other tool for converting a LUKS filesystem back to ext4?
Otherwise, is there any recovery tool for recovering data from a LUKS encrypted device?

Please help me.

rknichols · 06-20-2016, 11:22 AM

Was the partition encrypted prior to that first "cryptsetup luksFormat" command you mentioned? Apparently not, since e2fsck managed to find remnants of a filesystem there.

Stop doing that "luksFormat" operation. All you are doing is repeatedly overwriting the first ~2 megabytes of the partition. Running "luksFormat" repeatedly with the "same password" is especially pointless. "luksFormat" generates a new random master key each time. Your password just unlocks that master key.

Rule 1 for cases like this is to immediately make an image of the affected drive or partition and then work only on the copy. If the data is really important, make at least 2 copies. The best course at this point is to let e2fsck run on one of the copies and see what you are left with. With luck, most of your data will be in subdirectories in lost+found. The subdirectory names will be lost (replaced by numbers), but the filenames within them will be intact.

spiri13 · 06-20-2016, 12:22 PM

I ran the following command:

Code:

e2fsck -y data.img

But there is nothing in the /lost+found directory
There is also no other lost+found directory on my filesystem.
/dev/mapper/cryptdisk is still not mountable.

rknichols · 06-20-2016, 12:42 PM

You need to mount the image:

Code:

mkdir /mnt/tmp
mount -o loop data.img /mnt/tmp

The lost+found directory will be in that mounted image, /mnt/tmp/lost+found.

You will not be able to mount /dev/mapper/cryptdisk. If there ever was an encrypted filesystem on that partition, you destroyed any possibility of recovering that when you ran luksFormat.

spiri13 · 06-20-2016, 01:09 PM

I tried

Code:

mount -o loop data.img /mnt

but I get the error message

Code:

mount: unknown filesystem type 'crypto_LUKS'

Isn't it even possible to convert my filesystem back to ext4 without the loss of data?
The partition was originally an ext4 filesystem.

If not, that's really bad for me. There was a lot of code on the drive.

rknichols · 06-20-2016, 02:59 PM

You said you ran e2fsck on that image. Did it claim to have repaired the filesystem? It should have found one of the backup super blocks and repaired the filesystem from that. What are the first few messages from "e2fsck data.img" when you run it now? (You can interrupt it with ctrl-c when it first asks for a y/n confirmation.)

spiri13 · 06-20-2016, 03:48 PM

Here are the first few messages when I run e2fsck:

Code:

$ sudo e2fsck data.img
[sudo] entering password
e2fsck 1.42.13 (17-May-2015)
data.img was not cleanly unmounted, check forced.
Resize inode not valid.  Recreate<y>? yes
Pass 1: Checking inodes, blocks, and sizes
Root inode is not a directory.  Clear<y>? yes
Inode 56 is in use, but has dtime set.  Fix<y>? yes
Inode 56 has imagic flag set.  Clear<y>? yes
Inode 56 has a extra size (2177) which is invalid
Fix<y>? yes
Inode 56 has INDEX_FL flag set but is not a directory.
Clear HTree index<y>? yes
Inode 56, i_size is 18027495076643673406, should be 0.  Fix<y>? yes
Inode 56, i_blocks is 129899552004926, should be 0.  Fix<y>? yes
Inode 57 is in use, but has dtime set.  Fix<y>? yes
Inode 57 has imagic flag set.  Clear<y>? yes
Inode 57 has a extra size (23411) which is invalid
Fix<y>? yes
Inode 58 is in use, but has dtime set.  Fix<y>? yes
Inode 58 has imagic flag set.  Clear<y>? yes
Inode 58 has a extra size (54115) which is invalid
Fix<y>? yes
Inode 58, i_size is 8135082117735499286, should be 0.  Fix<y>? yes
Inode 58, i_blocks is 226681310199729, should be 0.  Fix<y>? yes
Inode 59 is in use, but has dtime set.  Fix<y>? yes
Inode 59 has a extra size (19182) which is invalid
Fix<y>? yes
Inode 60 is in use, but has dtime set.  Fix<y>? yes
Inode 60 has imagic flag set.  Clear<y>? yes
Inode 60 has a extra size (37703) which is invalid
Fix<y>? yes
Inode 60 has compression flag set on filesystem without compression support.  Clear<y>? yes
Inode 60 has INDEX_FL flag set but is not a directory.
Clear HTree index<y>? yes
Inode 60, i_size is 11814005135297009439, should be 0.  Fix<y>? yes
Inode 60, i_blocks is 36916921760685, should be 0.  Fix<y>? yes
data.img: e2fsck canceled.

data.img: ***** FILE SYSTEM WAS MODIFIED *****

I don't understand the message

Code:

data.img was not cleanly unmounted, check forced.

because data.img is not mounted
When the command finishes it claims that the filesystem was modified.

When I run

Code:

e2fsck -y data.img

twice, then I get

Code:

data.img: clean, 18420/3522560 files, 10853329/14089984 blocks

rknichols · 06-20-2016, 04:07 PM

Quote:

Originally Posted by spiri13;5563781I don't understand the message
[code

data.img was not cleanly unmounted, check forced.[/code]

A cleanly unmounted filesystem would have a valid primary super block with a "0" in the needs_recovery bit. Since you overwrote the primary super block, it's no surprise that e2fsck did not find that.

Quote:

When I run

Code:

e2fsck -y data.img

twice, then I get

Code:

data.img: clean, 18420/3522560 files, 10853329/14089984 blocks

The first time you ran it with "-y" it would have repaired the filesystem. Thereafter, you have a valid primary super block with no needs_recovery bit set, so e2fsck just reports it "clean" and exits. You would need to override that with the "-f" flag to force a check (which should not turn up any problems).

You should be able to mount that image now with the "-o loop" option.

Wait! I know what might be happening. The ext2/3/4 super block is the second 1K block in the partition. There is still a piece of the LUKS header in the first 1K block. The automatic filesystem type detection can be confused by that. Try using

Code:

mount -o loop -t ext4 date.img /mnt/tmp

spiri13 · 06-20-2016, 04:16 PM

When I run

Code:

sudo e2fsck -f data.img

I get the following output:

Code:

Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
data.img: 18420/3522560 files (1.6% non-contiguous), 10853329/14089984 blocks

But the image is still not mountable:

Code:

$ sudo mount -o loop data.img /mnt
mount: unknown filesystem type 'crypto_LUKS'

"file data.img" gives me

Code:

data.img: LUKS encrypted file, ver 1 [aes, xts-plain64, sha256] UUID: 8e17a595-ba1e-44df-8703-6684df2dc273

rknichols · 06-20-2016, 04:20 PM

See my edit at the end of the above message. (I wasn't quick enough.)

spiri13 · 06-20-2016, 04:26 PM

YES, this solved my problem!
However I have to rename the directories.
A million thanks man!

rknichols · 06-20-2016, 04:27 PM

Glad you got there.

Now, about those backups you apparently don't have, ... .