LUKS corrupted disk/partition problem
Posted: 07 Jun 2019, 21:45
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.
https://1drv.ms/u/s!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)
https://1drv.ms/u/s!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.
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.
https://1drv.ms/u/s!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)
https://1drv.ms/u/s!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.