URGENT Help needed w LUKS on KDE Neon

qelpp · 06-09-2020, 11:40 PM

Based on the terminal results above, what words would have appeared each time I successfully decrypted the LUKS volume each reboot? Something about successfully decrypting sda3_crypt or Live-OS-vg or something else? What does yours say in relation to the terminal results you get?

Does a master key exist on a backup of the system files? Can it be generated from files there? - Again, I have all the system files backed up.

berndbausch · 06-09-2020, 11:48 PM

Quote:

Originally Posted by qelpp

what words would have appeared each time I successfully decrypted the LUKS volume each reboot?

I don't encrypt my data, but from tests I ran I know that you would see the logical volume listed in blkid, with a filesystem UUID and a type of XFS or ext4 (or another filesystem type, but these two are the most common ones). The lsblk output would show /dev/mapper/live-os-something mounted on /.

Quote:

Does a master key exist on a backup of the system files? Can it be generated from files there? - Again, I have all the system files backed up.

The master key is contained in the LUKS header. The header is not automatically written to a file. It is your responsibility to back it up with cryptsetup luksHeaderBackup and store the backup file outside of the encrypted filesystem (and outside of reach of anybody who has an interest in decrypting your disk).

qelpp · 06-10-2020, 12:00 AM

I know that my system used to always show that sda3_crypt had just been decrypted.

berndbausch · 06-10-2020, 12:21 AM

Quote:

Originally Posted by qelpp

what words would have appeared each time I successfully decrypted the LUKS volume each reboot?

I don't encrypt my data, but from tests I ran I know that you would see the logical volume listed in blkid, with a filesystem UUID and a type of XFS or ext4 (or another filesystem type, but these two are the most common ones). The lsblk output would show /dev/mapper/live-os-something mounted on /.

Quote:

Does a master key exist on a backup of the system files? Can it be generated from files there? - Again, I have all the system files backed up.

The master key is contained in the LUKS header. The header is not automatically written to a file. It is your responsibility to back it up with cryptsetup luksHeaderBackup and store the backup file outside of the encrypted filesystem (and outside of reach of anybody who has an interest in decrypting your disk).

berndbausch · 06-10-2020, 12:37 AM

The blkid command shows this, currently:

Code:

/dev/sda3: UUID="df736320-c6fa-49c8-af42-7b3658b73a73" TYPE="crypto_LUKS" PARTUUID="dcdebd31-8cfa-4a7d-882e-e2a992c6563b"
/dev/mapper/sda3_crypt: UUID="grQVpf-NLQp-yubt-FKw6-0Mmc-PT1q-KSBbLD" TYPE="LVM2_member"

This means that sda3 has a LUKS header with UUID df736320-c6fa-49c8-af42-7b3658b73a73. The device mapper device /dev/mapper/sda3_crypt contains an LVM header with UUID grQVpf-NLQp-yubt-FKw6-0Mmc-PT1q-KSBbLD. This is a physical volume.

lsblk shows that there are two logical volumes on that physical volume:

Code:

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

After booting from sda (if that were possible), lsblk would report Live--OS--vg-root mounted on /.

I don't know what other messages you would see.

If a filesystem existed on Live--OS--vg-root, blkid would report it. The fact that it doesn't report it makes me think there is no filesystem. You can still try to mount it: Use the lvs command to list logical volumes, and try to mount /dev/mapper/Live--OS--vg-root.

syg00 · 06-10-2020, 01:46 AM

Quote:

Originally Posted by berndbausch

If a filesystem existed on Live--OS--vg-root, blkid would report it.

Only if the command were "lsblk -f" - let's see that.

qelpp · 06-10-2020, 09:17 AM

Code:

root@Live-OS:~# lsblk -f
NAME   FSTYPE  LABEL         UUID                                   MOUNTPOINT
loop0  squashf                                                      /rofs
sda                                                                 
├─sda1 vfat                  FDD5-2728                              
├─sda2 ext4                  25bc771f-565d-4ca9-b96c-a2bf6b8e514f   
└─sda3 crypto_               df736320-c6fa-49c8-af42-7b3658b73a73   
  └─luks-df736320-c6fa-49c8-af42-7b3658b73a73
       LVM2_me               grQVpf-NLQp-yubt-FKw6-0Mmc-PT1q-KSBbLD 
    ├─Live--OS--vg-root
    │                                                               
    └─Live--OS--vg-swap_1

What does "luks-df736320-c6fa-49c8-af42-7b3658b73a73" and "LVM2_me" mean?

qelpp · 06-10-2020, 10:03 AM

Code:

root@Live-OS:~# lvs
  LV     VG         Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  root   Live-OS-vg -wi-a----- 221.35g                                                    
  swap_1 Live-OS-vg -wi-a----- 976.00m                                                    
root@Live-OS:~#

What should the other headings have listed below them? Pool, Origin, etc.

Code:

root@Live-OS:~# sudo mount /dev/mapper/Live--OS--vg-root
mount: /dev/mapper/Live--OS--vg-root: can't find in /etc/fstab.
root@Live-OS:~# 

root@Live-OS:~# sudo mount /dev/mapper/sda3_crypt
mount: /dev/mapper/sda3_crypt: can't find in /etc/fstab.

The contents of the original fstab from Timeshift are:

Code:

UUID=aea6a765-2b0f-4d73-bd71-ecebcb724465	/	ext4	errors=remount-ro	0	1
UUID=d3926945-a654-4eae-ac84-c09f7dde65df	/boot	ext4	defaults	0	2
UUID=FDD5-2728	/boot/efi	vfat	umask=0077	0	1
/dev/mapper/neon--vg-swap_1	none	swap	sw	0	0

Usually, I have had the issue of not correctly guessing what to enter as a mount point.

Code:

root@Live-OS:~# mount /dev/mapper/Live-OS-vg /sda3_crypt
mount: /sda3_crypt: mount point does not exist.
root@Live-OS:~# mount -a sda3_crypt
root@Live-OS:~# sudo mkdir /dev/mapper/Live-OS-vg-root
root@Live-OS:~# sudo mount /dev/mapper/sda3_crypt /sda3_crypt
mount: /sda3_crypt: mount point does not exist.
root@Live-OS:~# sudo mount /dev/mapper/sda3 /sda3_crypt
mount: /sda3_crypt: mount point does not exist.

berndbausch · 06-10-2020, 07:01 PM

You can mount a filesystem anywhere.

Code:

mkdir /var/tmp/anywhere
mount /dev/mapper/Live-OS-vg /var/tmp/anywhere

When you get the message that the mountpoint doesn't exist, create it and try again.

Regarding your other questions: Pool, origin etc are for LVM features like thin pools and snapshots. Irrelevant here.
luks-df... is the way of the lsblk tool to say that there is a LUKS header with UUID df...
LVM2_me: I would have to guess. LVM2 probably refers to the second revision of the LVM implementation, which is the current standard.

berndbausch · 06-10-2020, 07:10 PM

Quote:

Originally Posted by qelpp

Code:

root@Live-OS:~# mount /dev/mapper/Live-OS-vg /sda3_crypt
mount: /sda3_crypt: mount point does not exist.
root@Live-OS:~# mount -a sda3_crypt
root@Live-OS:~# sudo mkdir /dev/mapper/Live-OS-vg-root
root@Live-OS:~# sudo mount /dev/mapper/sda3_crypt /sda3_crypt
mount: /sda3_crypt: mount point does not exist.
root@Live-OS:~# sudo mount /dev/mapper/sda3 /sda3_crypt
mount: /sda3_crypt: mount point does not exist.

mount -a mounts anything that is recorded in /etc/fstab. Since your encrypted disk is not in /etc/fstab, it's not a useful command here.
sudo mkdir /dev/mapper/Live-OS-vg-root is quite irrelevant as well. You should not create subdirectories under /dev/mapper.
You repeat mount /dev/mapper/sda3 /sda3_crypt, always getting the same error message. The message is actually rather clear (better than "an unknown error occurred", for example). Before mounting a filesystem, the mountpoint (a directory) must exist. It doesn't exist, therefore the error message. You need to create it.

Better refrain from issuing random commands that you don't understand. Follow the instructions:

Code:

# mkdir /sda3_crypt
# mount /dev/mapper/sda3_crypt /sda3_crypt

My fear is that this will fail, since no filesystem seems to exist on /dev/mapper/sda3_crypt, but it's worth trying.

qelpp · 06-10-2020, 08:19 PM

Code:

root@Live-OS:~# mkdir /sda3_crypt
root@Live-OS:~# mount /dev/mapper/sda3_crypt /sda3_crypt
mount: /sda3_crypt: special device /dev/mapper/sda3_crypt does not exist.
root@Live-OS:~#

Yes, it did fail.

Is it a special device because it is a LVM/LUKS "mapper" association? Or some other reason?

berndbausch · 06-10-2020, 10:48 PM

Quote:

Originally Posted by qelpp

Code:

root@Live-OS:~# mkdir /sda3_crypt
root@Live-OS:~# mount /dev/mapper/sda3_crypt /sda3_crypt
mount: /sda3_crypt: special device /dev/mapper/sda3_crypt does not exist.
root@Live-OS:~#

Yes, it did fail.

This is strange, because earlier, your blkid output contained this line:

Code:

/dev/mapper/sda3_crypt: UUID="grQVpf-NLQp-yubt-FKw6-0Mmc-PT1q-KSBbLD" TYPE="LVM2_member"

What has changed since you entered the blkid command?

Quote:

Is it a special device because it is a LVM/LUKS "mapper" association? Or some other reason?

I don't know what you mean by special device. /dev/mapper/sda3_crypt is not a physical device, but is created by the device mapper crypto module in the kernel. sda3, the physical device, contains encrypted data. /dev/mapper/sda3_crypt decrypts data when you read from sda3, and encrypts data when you write to it.

However, as you can see it doesn't exist. A plausible explanation: You rebooted the computer and have not yet run cryptsetup open.

berndbausch · 06-10-2020, 11:06 PM

I am confused myself after all the back and forth. /dev/mapper/sda3_crypt contains a physical volume, not a filesystem. You can't mount it, even when it exists.

So:

cryptsetup open --type luks ....
mkdir /mymountpoint
mount /dev/Live-OS-vg/root /mymountpoint
(you could also mount /dev/mapper/something, but I am not sure what something might be)

As I said, the last command is probably going to fail, since I have no hope that a filesystem was created on /dev/Live-OS-vg/root.

syg00 · 06-11-2020, 01:18 AM

I must admit I got somewhat addled trying to plough through this thread. At least twice.
The "lsblk -f" should show fstype for both the root and swap. The fact that it doesn't possibly indicates that somehow you managed to retain valid LUKS and LVM metadata, but trashed (at least) the start of the actual data portion of the vg (?). I guess it's also possible some of the metadata is wrong but not invalid - I've had that happen with corrupted partition tables. Just keeps sending you up dead-ends.
I would be heading for a backup and maybe invest sometime in something like photorec to retrieve anything that had been updated. From experience I can tell you that can be a long and tedious process.

berndbausch · 06-11-2020, 02:22 AM

Quote:

Originally Posted by syg00

I would be heading for a backup

You have not read the entire thread, obviously