LUKS corrupted disk/partition problem

How to use TestDisk to recover lost partition
Forum rules
When asking for technical support:
- Search for posts on the same topic before posting a new question.
- Give clear, specific information in the title of your post.
- Include as many details as you can, MOST POSTS WILL GET ONLY ONE OR TWO ANSWERS.
- Post a follow up with a "Thank you" or "This worked!"
- When you learn something, use that knowledge to HELP ANOTHER USER LATER.
Before posting, please read
Posts: 4
Joined: 06 Jun 2019, 19:24

LUKS corrupted disk/partition problem

#1 Post by LUKSlost19 »

First time posting here.
I can’t explain how I got to these circumstances with an attempted install of a current version of Linux Mint (I’ve used Ubuntu/Mint for years – no Windows/Mac machines/filesystems involved in my issue). I completed a functional install of Mint 19.1 on a 1 TB disk sda.
Following the Mint 19.1 install on disk sda, I found the OS on disk sdb corrupted. I had been interrupted/distracted. I don’t know how it happened. I believe that I have to unlock the 1 TB disk (disk sdb) on my machine, previously having a non-current Linux Mint OS with LVM-LUKS encryption. I need to recover either of two files, one is a database backup file and the other is a spreadsheet that has some of the same data.
None of this is of business or commercial matters. All is personal or family on one private household machine.

(1) I know the LUKS passphrase used to unlock the (now corrupted) OS on disk sdb.
(2) I first ran photorec_static on disk sdb and it found, among other files, two LUKS files that I think are LUKS header files.
(3) So I ran testdisk_static “quick search” on disk sdb with this result that displays one LUKS file.!AitciVvO-fq8hVEkOaB ... X9?e=RYohg

(4) Because photorec found two LUKS files, I then ran testdisk "deep search" and it displays two of what I suppose are LUKS header files. (same url image link - adjacent photo)!AitciVvO-fq8hVEkOaB ... X9?e=RYohg

(5) Question: Which LUKS header file do I select, press “a” and manually add a partition?? Does it matter? I need to be able to restart the PC and from disk sda (now Mint 191) run “update-grub” so on restart I can select the OS on disk sdb – meaning that I be prompted for the LUKS passphrase and “unlock” sdb and then have a decrypted volume on disk sdb with which to try to locate or recover the files I want.

Referring to a previously posted explanation by Mr. Grenier:
quote _________________________________________________________________
#2 Post by cgrenier » 13 Dec 2017, 07:12
TestDisk should detect the beginning of LUKS partition.
Identify the LUKS partition found by TestDisk.
As the LUKS unencrypted header doesn't contain the LUKS container size, TestDisk has no way to set the correct end for the partition.
Use 'a' to manually add a partition beginning at the same location than the LUKS partition found by TestDisk and ending at the end of the disk or just before the next partition.
Set this partition as MS Data, LUKS, P(rimary).
Once all partitions are listed, on next screen, choose Write, confirm, Quit.

from: viewtopic.php?t=7513
end quote________________________________________________________________

(6) If I manually add/correct the LUKS volume, upon restart will I then have a usable mounted file system, or will I likely need to do some sort of file system/SuperBlock fix (with sdb unmounted?), as stated in p. 23-24 of the testdisk PDF documentation?

Many thanks to Mr. Grenier. I have previously used PhotoRec with happy results. This is a bigger problem or complication than I’ve had with any Linux filesystem/install, and I appreciate any advice or suggestions from the forum.

Sponsored links

User avatar
Site Admin
Posts: 5327
Joined: 18 Feb 2012, 15:08
Location: Le Perreux Sur Marne, France

Re: LUKS corrupted disk/partition problem

#2 Post by cgrenier »

If you add the correct LUKS partition (my bet is on a LUKS partition starting at 158 182 25), after a reboot, you will have to unlock your LUKS volume and maybe run fsck but you should not have to fix the superblock.

Posts: 4
Joined: 06 Jun 2019, 19:24

Re: LUKS corrupted disk/partition problem

#3 Post by LUKSlost19 »

I tried adding a partition at 158 182 25 and on restart I got an identifiable LUKS encrypted partition, but after entering the LUKS passphrase (which it took OK) all I got was a 2 MiB decrypted partition with nothing in it. I opened gnome-disks just to look at the disk sdb and there was about 930 GiB labeled "unknown."

At that point I shutdown the PC and disconnected disk sdb, just to be sure I wouldn't be creating more problems. I haven't been able to spend more time on it, yet.

Should I consider adding a partition at the LUKS file 127 155 29 ?
And how could I determine the correct CHS for the end of the disk? I tried to read up on CHS determination but I feel I'm haven't been understanding much of what I read.
Also disk sda is definitely EFI GPT not "intel" ??? Of what significance might this be regarding restoring the correct partition structure?
Again, many thanks for your advice/suggestions.

Posts: 4
Joined: 06 Jun 2019, 19:24

Re: LUKS corrupted disk/partition problem

#4 Post by LUKSlost19 »

I reconnected drive sdb to take another look at possible ways to recover data from the misadventure of an errant install described in my first post. (Before reconnecting sdb I did a basic ubuntu 1804 LVM-LUKS install on sda just to be able to see the what the partition structure and other disk/filesystems characteristics *should* look like. Both sda and sdb are similar 1 TB hard disks).
I now get no files showing from any sdb partition when running testdisk (as in pressing "P" after quick search or deep search).

Here is an fdisk -l for sdb
sudo fdisk -l /dev/sdb
Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 9FB7F702-D0E8-4A7B-9761-107FB18EC7C6
Device Start End Sectors Size Type
/dev/sdb1 2048 1050623 1048576 512M EFI System
/dev/sdb2 1050624 2549759 1499136 732M Linux filesystem
/dev/sdb3 2549760 2553855 4096 2M Linux filesystem

I did a blkid grep on LUKS then LVM2 to see what the results would be
sudo blkid | grep LUKS
[sudo] password for ...:
/dev/sda3: UUID="8e47376e-6e62-400b-916c-892c319a0934" TYPE="crypto_LUKS" PARTUUID="3b3db57f-4d96-4cfa-8781-384af9c9be5b"
/dev/sdb3: UUID="f6410e21-8b9c-4c48-84ee-3f7a8954bdf7" TYPE="crypto_LUKS" PARTUUID="31343666-6530-3132-2d38-6239632d3463"
sudo blkid | grep LVM2
/dev/mapper/sda3_crypt: UUID="NMRBVU-edhX-9EX3-dOGu-PbXy-0OB5-nrEa5w" TYPE="LVM2_member"

So both disks have something identified as LUKS, but sdb has nothing identified as LVM2, sdb has no "/dev/mapper/sdb3_crypt..."

I tried e2fsck -n /dev/sdb to see what results there would be:
sudo e2fsck -n /dev/sdb
[sudo] password for ...:
e2fsck 1.44.1 (24-Mar-2018)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/sdb

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>
e2fsck -b 32768 <device>

Found a gpt partition table in /dev/sdb

So I'm uncertain as to how to proceed. Again, with the least possible overwrite of sdb, I simply need to be able to unlock the encrypted volume on sdb to then run photorec.
So is it advisable to run e2fsck for a superblock fix or try to manually re-create a LUKS-LVM filesystem as described in this URL? ... s-and-lvm/

I think the encrypted volume on sdb is still there, intact. Again, any advice or suggestions are very appreciated

Posts: 4
Joined: 06 Jun 2019, 19:24

Re: LUKS corrupted disk/partition problem -CLOSED, Thanks for the advice

#5 Post by LUKSlost19 »

I found the data I needed in a file on a saved VM. Sorry for the delay in follow-up - I just forgot to close this topic.
I never recovered the partition structure evidently overwritten when I ran a clean install on the wrong disk.
MORAL OF THE STORY: When doing an installation, don't get distracted and certainly don't walk away from the machine!! ;)