Possibly my issue is different than described originally.
Based on the terminal results shown here and in my previous missive, can someone tell me what the name would be shown onscreen as the OS started up after a successful decryption of the drive? Would it be sd3_crypt? or Live-OS-vg? or something else?
I could search my Timeshift backups for original crypt files, headers, master key, etc. if that could help get back into the SSD from its present condition.
Also, it seems as if my LUKS volume "is" currently mounted and open, albeit through my install thumbdrive. This is after a reboot w/ my KDE neon thumbdrive.
My issue may be that I have just not found the appropriate commands to access it (showing hidden, tried Dolphin, Caja & Thundar). All "dolphin path" choices I have tried result in empty finder windows - whether I use mapper as part of the path or not. If I select in a finder the icon for a "222.4 GiB Encrypted Drive" I get this error message:
>>>>>
An error occurred while accessing 'Home', the system responded: An unspecified error has occurred: No such interface 'org.freedesktop.UDisks2.Filesystem' on object at path /org/freedesktop/UDisks2/block_devices/dm_2d0
<<<<<
So far that hasn't helped me find a solution to open the volume.
I repeated earlier commands and got this variance:
>>>>>
root@neon:~# cryptsetup open /dev/sda3 sda3_crypt -- luks
Enter passphrase for /dev/sda3:
root@neon:~# echo $?
0
root@neon:~#
<<<<<
It no longer indicated that sda3_crypt already exists and the echo $? returned a 0 instead of 5 (I don't know what that signifies, but it is different).
>>>>>
root@neon:~# mkdir /mnt/sda3_crypt && mount /dev/mapper/sda3_crypt /mnt/sda3_crypt
mkdir: cannot create directory ‘/mnt/sda3_crypt’: File exists
root@neon:~#
<<<<<
Doesn't the above indicate that it is open?
Plus GParted states that it is "Active" and "Open".
If someone can suggest a method that will enable me to open this in a finder window so I can move files to a new location off the SSD I would actually be done.
But I also realize it might not be this simple.
BTW, as previously, I cannot log into my SSD as usual, it simply takes me to GRUB2.02 and I cannot restore using Timeshift.
----
Did my brief mistake create new UUIDs and that is all that I am currently able to see with these various commands, or are they likely the original ones created when the LUKS volume was created? Does anyone know if the original UUIDs would be found on the encrypted system files? - Are the UUIDs important at all in this circumstance, or are they secondary? --- I do have the "system" files backed up in Timeshift snapshots. If someone can tell me where to look in the file system for such files, they would be there. I just don't know what to look for so far.
When everything indicates that it is Active and Open, but I cannot find it anywhere, does that mean the UUIDs are new and they just don't associate with anything meaningful?
Thank you for your help.
=============================
=============================
More specific commands and results follow:
>>>>>
neon@neon:~$ sudo -i
root@neon:~# 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
root@neon:~# echo $?
0
root@neon:~# cryptsetup open /dev/sda3 sda3_crypt --type luks
Enter passphrase for /dev/sda3:
Device sda3_crypt already exists.
root@neon:~# echo $?
5
root@neon:~#
<<<<<
>>>>>
neon@neon:~$ blkid
/dev/sda1: UUID="FDD5-2728" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="89839035-db07-4938-b0c1-10083ca8cd0f"
/dev/sda2: UUID="25bc771f-565d-4ca9-b96c-a2bf6b8e514f" TYPE="ext4" PARTUUID="8c2af1d5-4027-4801-8be3-62ef71d64bca"
/dev/sdb1: LABEL="GREY" UUID="e6c9b7ae-fc0f-4efd-bb58-bc37d4d1eac6" TYPE="ext4" PARTUUID="09a34015-0327-480a-9880-277fa745d723"
/dev/sdb2: LABEL="BLACK" UUID="c421d116-33c8-4157-80bd-886a6b0d3031" TYPE="ext4" PARTUUID="2dc30769-07d4-4468-8ff8-91f6c6c05be7"
/dev/sdb3: LABEL="RED1" UUID="c48dc388-9e6f-4c46-a1e8-d2ee1c7d1655" TYPE="ext4" PARTUUID="252160e7-ac76-4203-8c6b-e6307f323635"
/dev/sdb4: LABEL="RED2" UUID="429e33e6-98f1-4b21-8e36-bf06fd7667ec" TYPE="ext4" PARTUUID="b4fdc4b9-7767-4d85-b9f8-53d578a7700a"
/dev/sdc1: LABEL="FLAME" UUID="3b061e65-2bf5-48da-afe9-537e7cd160a3" TYPE="ext4" PARTUUID="3bb2b17f-01"
/dev/sdc2: LABEL="ASPEN" UUID="996947a2-0224-4a7c-b636-8d25ec23693d" TYPE="ext4" PARTUUID="3bb2b17f-02"
/dev/sdc3: LABEL="BIRCH" UUID="7fc3d3ab-8067-429d-8a25-199a41f4ab0f" TYPE="ext4" PARTUUID="3bb2b17f-03"
/dev/loop0: TYPE="squashfs"
/dev/sda3: UUID="df736320-c6fa-49c8-af42-7b3658b73a73" TYPE="crypto_LUKS" PARTUUID="dcdebd31-8cfa-4a7d-882e-e2a992c6563b"
/dev/sdd2: SEC_TYPE="msdos" UUID="B1F5-0A13" TYPE="vfat" PARTUUID="176f5402-02"
/dev/sde1: SEC_TYPE="msdos" LABEL_FATBOOT="TRANSPARENT" LABEL="TRANSPARENT" UUID="60DA-6A96" TYPE="vfat" PARTUUID="dfc3a854-fbd1-474f-8f81-0c6afff21a47"
/dev/mapper/sda3_crypt: UUID="grQVpf-NLQp-yubt-FKw6-0Mmc-PT1q-KSBbLD" TYPE="LVM2_member"
<<<<<
>>>>>
neon@neon:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 1.4G 1 loop /rofs
sda 8:0 0 223.6G 0 disk
├─sda1 8:1 0 512M 0 part
├─sda2 8:2 0 732M 0 part /media/root/25bc771f-565d-4ca9-b96c-a2bf6b8e51
└─sda3 8:3 0 222.4G 0 part
└─sda3_crypt 253:0 0 222.4G 0 crypt
├─Live--OS--vg-root
│ 253:1 0 221.4G 0 lvm
└─Live--OS--vg-swap_1
253:2 0 976M 0 lvm
<<<<<
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
