I am seeking help in recovering the contents of a LUKS volume on a
KDE Neon kept up to date on a 230GB SSD. I joined the mailing list but
don't understand how it works so I am sending this to you for your help
or if you can explain how to use the mailing list I would do as you
suggest.
The EVENT happened the evening of
the 4th of June, when I was creating a different OS on a thumbdrive. At
the point where you choose where to install, I chose the appropriate sd
and moved to the next step but it did not have the LVM I wanted so I
clicked back to choose again, I chose LVM w LUKS and started the
install, but in one second or less I noticed and clicked Back again -
because it had reset to my sda drive and I hadn't noticed prior to
begining the install. So in one second or less I tried to stop the
process and it took a few seconds before it went back to where to choose
to install -- I chose the correct sd and created a successful bootable
thumbdrive of another OS. That is when the EVENT happened.
Does
my description of what happened suggest to you that more than the LUKS
header was damaged, it and the GRUB2 files; OR is it truly unrecoverable
and I need to try to re-create several months of work from scratch?
Upon
booting back to Neon, all I got was the GRUB 2.02 screen, Exit-ing
didn't do anything. End of the day. The next morning I had a recent KDE
Neon thunbdrive available and installed Timeshift on it and attempted
to restore to the 30th of May backup but it fails when prompted for the
passphrase.
I have the correct passphrase, but cannot get it into the process.
I did try the LUKS passphrase I created along with the other distro thumbdrive during the EVENT - it doesn't work either.
Since
it happened I used the machine several times to get a copy of
Clonezilla that worked and to then make two image copies of the sda3. I
also used install thumbdrives of Neon and 18.04 Ubuntu (Server &
Desktop) to try to reinstall Grub w/o success (had no clue how to access
the install OSes' features to re-install Grub) and used Neon again to
get the details of the LUKS & sda3 partition.
I
stopped using Deja Dup & Duplicity to make encremental backups of
the critical folders of mine a few months ago because that never worked,
they kept creating massive files totalling very many times more data
than the size of my whole OS' SSD. So I continually ran out of space and
therefore had no confidence in whatever was being saved. I had
specifically chosen to have encremental backups, which the apps claimed
would overwrite earlier versions, but both just stopped once their large
partition was full and simply put up notifications that it was full -
never deleted any of the huge number of files they had produced.
I
had been making space on an external drive to copy over all my personal
data, screen recording of all installed apps and ppa lists; and
probablt this week do a clean install of the latest KDE Neon, having
tried and deleted various apps, and wanted to thin it out of pointless
files. Like everyone who has just lost access to their files, I am also
saying that it is months of valuable work that I do not want to try to
replace - I just didn't find a backup app that appealed to me or
actually worked and just kept putting off trying another one.
I
install Timeshift whenever I do a clean install because it has always
worked as claimed. So I do have a 30may2020 backup of the system, along
with prior dates - but no personal files.
- - -
https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#6-backup-and-data-recovery
I
have read the Backup and Data Recovery section, some of which reads
like I can possibly create a new header and it may be alright, but some
parts sound like it will make it absolutely unrecoverable.
My
goal in openning the LUKS volume is to immediately copy the personal
data files from it and then urandom wipe it and install a new LUKS
encrypted KDE Neon AND THEN BACK UP THE LUKS FILES suggested on the
gitlab-cryptsetup website and purchase another drive to try some other
backup software and give it huge space to duplicate files. So if you
have a suggestion that won't make the volume function as it used to but
will allow me to access the files in the finder of an USB install drive -
that is all I need.
I just thought of a question. Does the fact that I have Timeshift
backups offer any help in getting a header or whatever out of them to
open the SSD which is currently inaccessible; i.e. original undamaged LUKS headers. Or is it a matter that the encrypted SSD cannot be accessed deep enough to replace the one that is assumed to be damaged.
Thank you for your help.
- - -
Miscellaneus terminal entries/results are listed below:
I have done this: sudo cryptsetup luksDump /dev/sda3
And I assume that "Version: 1" means this is a LUKS1 installation. Is that true?
The luksDump returns this:
Crypto backend (gcrypt 1.8.1) initialized in cryptsetup library version 2.0.2.
sudo cryptsetup luksOpen /dev/sda3/ sda3_crypt
Results in: Device /dev/sda3/ doesn't exist or access denied.
Despite the fact that "sudo blkid | grep crypto" lists sda3 as the LUKS volume.
----------
neon@neon:~$ dmsetup ls
/dev/mapper/control: open failed: Permission denied
Failure to communicate with kernel device-mapper driver.
Incompatible libdevmapper 1.02.145 (2017-11-03) and kernel driver (unknown version).
Command failed
Name: sda3_crypt
State: ACTIVE
Read Ahead: 256
Tables present: LIVE
Open count: 2
Event number: 0
Major, minor: 253, 0
Number of targets: 1
UUID: CRYPT-LUKS1-df736320c6fa49c8af427b3658b73a73-sda3_crypt
neon@neon:~$
----------
neon@neon:~$ sudo dmsetup status /dev/dm-0
0 466307072 crypt
---------
neon@neon:~$ sudo cryptsetup open /dev/sda3 sda3_crypt -- type luks
Enter passphrase for /dev/sda3: Error reading passphrase from terminal.
neon@neon:~$ blkid -t TYPE=crypto_LUKS -o device
/dev/sda3
neon@neon:~$ dmsetup table /dev/mapper/sda3_crypt --showkeys
/dev/mapper/control: open failed: Permission denied
Failure to communicate with kernel device-mapper driver.
Incompatible libdevmapper 1.02.145 (2017-11-03) and kernel driver (unknown version).
Command failed
neon@neon:~$ sudo cryptsetup -v isLuks /dev/sda3
Command successful.
neon@neon:~$ sudo dmsetup table --target crypt --showkey /dev/mapper/sda3
Device /dev/mapper/sda3 not found
Command failed
neon@neon:~$ sudo dmsetup table --target crypt --showkey /dev/mapper/sda3_crypt
0
466307072 crypt aes-xts-plain64
e01b2791aa73d65c1b5b0d5d47afa3edabcd54252be070a4eecf88ae2ce968ab505d5f8d19177589c9a4514b2547c2e78c4a01e52ed5b74d957fbbe5487bb86d
0 8:3 4096
neon@neon:~$
----------
neon@neon:~$ sudo cryptsetup luksDump /dev/sda3 --debug | grep backend
# Initialising device-mapper backend library.
# Crypto backend (gcrypt 1.8.1) initialized in cryptsetup library version 2.0.2.
# Releasing device-mapper backend.
neon@neon:~$
----------
neon@neon:~$ sudo cryptsetup luksDump /dev/sda3
LUKS header information for /dev/sda3
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha256
Payload offset: 4096
MK bits: 512
MK digest: 8e d7 1b 4a a0 de ee 10 18 e4 42 31 9c dd 7d 34 15 c9 52 55
MK salt: b4 4c df 25 ca 08 82 13 c0 c8 94 0a a1 fc ac 17
0a be 4e b4 a3 f0 f2 97 77 da 0f 34 a6 ab 82 c9
MK iterations: 108145
UUID: df736320-c6fa-49c8-af42-7b3658b73a73
Key Slot 0: ENABLED
Iterations: 1730322
Salt: 9a e3 7f 43 9c 43 cc 3f bc 80 41 b9 38 b4 63 85
ac dd 7f 5c 2b cf 2a 79 15 d6 5f 8f 89 59 e7 55
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
neon@neon:~$ sudo cryptsetup luksDump /dev/sda3
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
