20

I accidentally created a new physical volume over my LUKS partition; nothing else happened. The LUKS partition contains a LVM setup and the root partition (this setup was initially created by the debian installer).

I can see that the LUKS partition is mostly intact:

00000200: 4c41 4245 4c4f 4e45 0100 0000 0000 0000 LABELONE........ 00000210: 0ccb b873 2000 0000 4c56 4d32 2030 3031 ...s ...LVM2 001 00000220: 4b48 5047 5667 6465 477a 7831 306a 6649 KHPGVgdeGzx10jfI 00000230: 7635 4432 4637 6966 446a 7172 3339 4863 v5D2F7ifDjqr39Hc 00000240: 0000 40a2 e800 0000 0000 1000 0000 0000 ..@............. .... 00005000: 7b22 6b65 7973 6c6f 7473 223a 7b22 3022 {"keyslots":{"0" 00005010: 3a7b 2274 7970 6522 3a22 6c75 6b73 3222 :{"type":"luks2" 00005020: 2c22 6b65 795f 7369 7a65 223a 3634 2c22 ,"key_size":64," 00005030: 6166 223a 7b22 7479 7065 223a 226c 756b af":{"type":"luk 00005040: 7331 222c 2273 7472 6970 6573 223a 3430 s1","stripes":40 00005050: 3030 2c22 6861 7368 223a 2273 6861 3235 00,"hash":"sha25 00005060: 3622 7d2c 2261 7265 6122 3a7b 2274 7970 6"},"area":{"typ 00005070: 6522 3a22 7261 7722 2c22 6f66 6673 6574 e":"raw","offset 00005080: 223a 2233 3237 3638 222c 2273 697a 6522 ":"32768","size" 00005090: 3a22 3235 3830 3438 222c 2265 6e63 7279 :"258048","encry 000050a0: 7074 696f 6e22 3a22 6165 732d 7874 732d ption":"aes-xts- 000050b0: 706c 6169 6e36 3422 2c22 6b65 795f 7369 plain64","key_si 000050c0: 7a65 223a 3634 7d2c 226b 6466 223a 7b22 ze":64},"kdf":{" 000050d0: 7479 7065 223a 2261 7267 6f6e 3269 222c type":"argon2i",

However, the characteristic "LUKS" is missing.

Is there any way to access the LUKS partition to retrieve the data? I tried testdisk, but without success.

Update, since I did not include this originally: Here is the LUKS header backup @ 0x4000:

00004000: 0000 0000 0000 0002 0000 0000 0000 4000 ..............@. 00004010: 0000 0000 0000 0005 0000 0000 0000 0000 ................ 00004020: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004030: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004040: 0000 0000 0000 0000 7368 6132 3536 0000 ........sha256.. 00004050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004060: 0000 0000 0000 0000 735b 6f53 2466 e2bb ........s[oS$f.. 00004070: abcf fb4a d5ea d395 70ab f4e8 1f99 a173 ...J....p......s 00004080: 2303 93a0 7582 eb4a 77fe 28f8 3e01 b246 #...u..Jw.(.>..F 00004090: e9eb cd58 8a7a afd5 4e45 319a c007 906b ...X.z..NE1....k 000040a0: b22a c393 1918 981c 6636 6333 6461 3534 .*......f6c3da54 000040b0: 2d63 6435 362d 3433 3036 2d38 6330 312d -cd56-4306-8c01- 000040c0: 3534 3334 3366 6265 6564 3236 0000 0000 54343fbeed26.... 000040d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000040e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000040f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004100: 0000 0000 0000 4000 0000 0000 0000 0000 ......@......... 00004110: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004120: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004130: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004140: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004150: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004160: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004170: 0000 0000 0000 0000 0000 0000 0000 0000 ................
Improve this question

1 Answer 1

Reset to default
38
+200

cryptsetup repair, Part One — Magic Bytes Recovery

This looks like a LUKS 2 header that was directly overwritten with LVM metadata. So the LUKS device became a LVM Physical Volume. So this is a damaged LUKS header recovery problem. Depending on the damage, it might be irrecoverable.

For LUKS1, it's usually game over, but LUKS2 has a secondary header at offset 0x4000. You inconveniently did not include that offset range in your output, but the LUKS2 JSON data at offset 0x5000 is still there.

So you can try the following experiment:

Copy the first 16 MiB of the device (the LUKS 2 header):

# head -c 16M /dev/yourdevice > luksheaderdamage.img

Restore LUKS 2 header magic byte signatures (wiped by LVM):

--- Primary: 0x0000 » LUKS\xba\xbe\x00\x02 --- # printf 'LUKS\272\276\0\2' | dd bs=1 count=8 conv=notrunc of=luksheaderdamage.img --- Secondary: 0x4000 » SKUL\xba\xbe\x00\x02 --- # printf 'SKUL\272\276\0\2' | dd bs=1 count=8 seek="$((0x4000))" conv=notrunc of=luksheaderdamage.img

Try to repair the LUKS 2 header:

# cryptsetup repair luksheaderdamage.img WARNING: Device luksheaderdamage.img already contains a 'LVM2_member' superblock signature. WARNING! ======== Really try to repair LUKS device header? Are you sure? (Type 'yes' in capital letters): YES

Check the result:

# cryptsetup luksDump luksheaderdamage.img

If successful, open the device:

# cryptsetup open --readonly --header=luksheaderdamage.img /dev/yourdevice cryptyourdevice

Then see what can be found...

# file -s /dev/mapper/cryptyourdevice

If any of these steps fail, you might not have much hope left...

(The hoop jumping with all these commands is only necessary because cryptsetup repair is not flexible and refuses to repair LUKS 2 headers even if the damage is limited to the magic bytes. Hence the restoring of the magic byte signature is a manual process.)

Improve this answer
4
  • 12
    Unbelievable. This worked exactly as you described it. In the process I found out that my initial question was incorrect – I had a LVM setup within LUKS, not the other way around. I am currently copying the data to another drive, thank you very much! I will edit my question to reflect my initial problem and your answer in a better way. Commented Jun 14, 2022 at 4:27
  • 4
    Brilliant answer - just for completeness, there is another tool that can be used to rescue data from a disk: linuxconfig.org/how-to-recover-partition-table-in-linux. I've only used it once, thankfully, but it enabled me to find important files and copy them off. Commented Jun 14, 2022 at 7:58
  • 1
    @j4nd3r53n Looks like they are using testdisk in this howto. As I stated in my original question, that did not work for me. Commented Jun 16, 2022 at 7:02
  • You sir are a LIFESAVER!!! This is the best answer in the entire StackExchange Network!!! Thank you soooo much @frostschutz!!!! Commented Aug 10, 2023 at 18:13

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.