Luks/LVM Data Recovery

wasgurd

New Member
Joined
Oct 8, 2021
Messages
4
Reaction score
0
Credits
34
Hi there,

It seems like a have a problem with data recovery:

fdisk -l /dev/sdb Disk /dev/sdb: 58.24 GiB, 62537072640 bytes, 122142720 sectors Disk model: STORAGE DEVICE Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: C73D9BDC-1302-4608-9F55-D34ED890F3D2 Device Start End Sectors Size Type /dev/sdb1 2048 999423 997376 487M Linux filesystem /dev/sdb2 999424 122140671 121141248 57.8G Linux filesystem

In /dev/sdb2 is cryptocontainer with LVM:

sudo cryptsetup luksDump /dev/sdb2 LUKS header information Version: 2 Epoch: 3 Metadata area: 16384 [bytes] Keyslots area: 16744448 [bytes] UUID: a5f102e6-6066-4f4d-9e12-bb9a59141e86 Label: (no label) Subsystem: (no subsystem) Flags: (no flags) Data segments: 0: crypt offset: 16777216 [bytes] length: (whole device) cipher: aes-xts-plain64 sector: 512 [bytes] Keyslots: 0: luks2 Key: 512 bits Priority: normal Cipher: aes-xts-plain64 Cipher key: 512 bits PBKDF: argon2id Time cost: 4 Memory: 121927 Threads: 4 Salt: 35 79 11 3e b9 a0 65 fc ae 8e fc 9d bd a2 bc 23 ae 70 f0 c6 48 9c eb 7c eb a7 a1 74 6d 1b b0 25 AF stripes: 4000 AF hash: sha256 Area offset:32768 [bytes] Area length:258048 [bytes] Digest ID: 0 Tokens: Digests: 0: pbkdf2 Hash: sha256 Iterations: 36207 Salt: d6 33 fe e0 00 94 9f 96 63 f8 89 9e 02 46 d5 27 c6 dc 00 38 2d ec 93 0c 7e 3c 5f 44 67 45 88 d0 Digest: 6d 93 0a ec b7 69 97 d5 76 72 5e ab 34 c8 17 32 94 43 bd 09 84 d4 29 a4 d0 8b 77 0c 9d d2 40 56

I can open that, in the /dev/mapper I have:

sudo ls /dev/mapper | grep pbp pbp--vg-home pbp--vg-root pbp--vg-swap_1 pbp--vg-tmp pbp--vg-var

However, I can't mount anything:

sudo mount /dev/mapper/pbp--vg-home /mnt mount: /mnt: wrong fs type, bad option, bad superblock on /dev/mapper/pbp--vg-home, missing codepage or helper program, or other error.
sudo fsck.ext4 /dev/mapper/pbp--vg-home e2fsck 1.46.2 (28-Feb-2021) ext2fs_open2: Bad magic number in super-block fsck.ext4: Superblock invalid, trying backup blocks... fsck.ext4: Bad magic number in super-block while trying to open /dev/mapper/pbp--vg-home The superblock could not be read or does not describe a valid ext2/ext3/ext4 filesystem. If the device is valid and it really contains an ext2/ext3/ext4 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 <device> or e2fsck -b 32768 <device>

e2fsck doesn't help as well.

Is there anyway to mount/recover data? Thank you very much in advance!
 


What Linux distro, @wasgurd ?

I am not familiar with the subject, but someone else may want to know.

Good luck, and welcome to linux.org :)

Chris Turner
wizardfromoz
 
Never, ever, ever, ever do anything to an encrypted file container/partition without cloning it with dd.
That said, because it is encrypted, fsck may bring up errors.
Try installing "crypt setup". Makes it easier.
After you clone it, if not too late, we can try messing with it.
Phone is dying, but I'll take a gander in the meantime on my PC if nobody else can help. Cheers.
 
Never, ever, ever, ever do anything to an encrypted file container/partition without cloning it with dd.
That said, because it is encrypted, fsck may bring up errors.
Try installing "crypt setup". Makes it easier.
After you clone it, if not too late, we can try messing with it.
Phone is dying, but I'll take a gander in the meantime on my PC if nobody else can help. Cheers.

Hi and thank you :)

I already made an image with dd, cryptsetup is also installed. Looking forward to see if we can do something with that.

N.B. it's eMMC with debian installed, now I moved it to another laptop.
 
I'm assuming everything went smooth with cryptsetup luksOpen...

wasgurd said:
sudo ls /dev/mapper | grep pbp
pbp--vg-home
pbp--vg-root
pbp--vg-swap_1
pbp--vg-tmp
pbp--vg-var

So now you need to mount what's been mapped. I looked through the output and noticed you trying e2fsck on 2 different blocks to no avail. That seems parculiar. What if you just try and force it to mount (I suggest ro to begin with):
Code:
// Assuming pbp-root is the 1st LVM partition
// Otherwise, substitute.
// 32768 is AFAIK the first backup SB on a LUKS

// Escalate
sudo -i

// Test mount
mount sb=32768 -o ro /dev/mapper/pbp--vg-root/ /mnt

// If that works, LVMs are good. Otherwise, find
// every SB and try mounting
dumpe2fs /dev/sdb2 | grep superblock
Collect the output of everything, and if things go wrong, dump it here, but put it in spoiler tags like so:
[spoiler ]
my dump
[/sloiler ]
...but without spaces in the spoiler tags.
 
I'm assuming everything went smooth with cryptsetup luksOpen...

Hi there and thanks for the advice, unfortunately, no luck by now:

cryptsetup luksOpen /dev/sdb2 123 works fine, however:

dumpe2fs /dev/sdb1 | grep superblock
dumpe2fs 1.46.2 (28-Feb-2021)
Primary superblock at 1, Group descriptors at 2-3
Backup superblock at 8193, Group descriptors at 8194-8195
Backup superblock at 24577, Group descriptors at 24578-24579
Backup superblock at 40961, Group descriptors at 40962-40963
Backup superblock at 57345, Group descriptors at 57346-57347
Backup superblock at 73729, Group descriptors at 73730-73731
Backup superblock at 204801, Group descriptors at 204802-204803
Backup superblock at 221185, Group descriptors at 221186-221187
Backup superblock at 401409, Group descriptors at 401410-401411

dumpe2fs /dev/sdb2
dumpe2fs 1.46.2 (28-Feb-2021)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sdb2
Couldn't find valid filesystem superblock.
/dev/sdb2 contains a crypto_LUKS file system

dumpe2fs /dev/mapper/123
dumpe2fs 1.46.2 (28-Feb-2021)
dumpe2fs: Bad magic number in super-block while trying to open /dev/mapper/123
Couldn't find valid filesystem superblock.
/dev/mapper/123 contains a LVM2_member file system

dumpe2fs /dev/mapper/pbp--vg-tmp
dumpe2fs 1.46.2 (28-Feb-2021)
dumpe2fs: Bad magic number in super-block while trying to open /dev/mapper/pbp--vg-tmp
Couldn't find valid filesystem superblock.

mke2fs -n /dev/mapper/pbp--vg-tmp
mke2fs 1.46.2 (28-Feb-2021)
Creating filesystem with 195584 4k blocks and 48960 inodes
Filesystem UUID: 81a34450-591d-4d82-aebe-9ef3a5f80d17
Superblock backups stored on blocks:
32768, 98304, 163840

mount -o sb=98304 /dev/mapper/pbp--vg-tmp /mnt and other SB:
mount -o sb=98304 /dev/mapper/pbp--vg-tmp /mnt
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/mapper/pbp--vg-tmp, missing codepage or helper program, or other error.

Is everything gone? :)
 
Gone? No. Encrypted, yes. Problem here is rescuing files and dd'ing fragments won't work on encrypted partitions. Comparing the differences in health between partitions is troublesome. I wouldn't give up completely, I mean the data is still there. From a forensics POV, the encrypted data is fine, but the FS is buggered. I wish I'd done that forensics course a few years back. Anyway, I'll look into it some more. I can't promise much, but see if you can find a place to store a dd image of sdb2 (cheap external hdd) and watch the thread. Maybe someone else will come up with a plan, too. Never give up if the data is there. I lost (as in paper fell in water) my password to a True Crypt (now Vera Crypt) container over 10 years ago. A few years ago, I took what was legible of the 30 odd characters and generated a dictionary. Now I'm just hitting it with that wordlist whenever I remember to run it when I'm away from my PC.
So if the data is important, just don't give in. You got nothing to lose.
 
Well, I thought if I can open luks-container, it means the data is decrypted and problem how to mount/open what's inside. :)
Thank you again, the data there is really important and I don't want lose that.
 

Members online


Top