URGENT Help needed w LUKS on KDE Neon

qelpp · 06-12-2020, 01:37 PM

Last thing I did last night was reboot and copy sda to a new 256GB thumbdrive, which I had earlier erased w/ dd urandom.

Made the copy via: sudo dd if=/dev/sda of=/dev/sdf bs=512 status=progress

I am using the original sda for these things. I set aside the backup thumbdrive.

---------
So I just realized I hadn't mounted sda today, so here are the results of your suggested commands ON A MOUNTED DRIVE:

Code:

root@neon:~# mkdir /dev/mapper/Live--OS--vg-root
root@neon:~# cryptsetup luksOpen /dev/mapper/Live--OS--vg-root /dev/mapper/Live--OS--vg-swap_1
root@neon:~# file -sL /dev/mapper/Live--OS--vg-root /dev/mapper/Live--OS--vg-swap_1
/dev/mapper/Live--OS--vg-root:   directory
/dev/mapper/Live--OS--vg-swap_1: cannot open `/dev/mapper/Live--OS--vg-swap_1' (No such file or directory)
root@neon:~#

qelpp · 06-12-2020, 01:46 PM

Noticed that I did not create the swap only root.

Code:

root@neon:~# mkdir /dev/mapper/Live--OS--vg-swap_1
root@neon:~# file -sL /dev/mapper/Live--OS--vg-root /dev/mapper/Live--OS--vg-swap_1
/dev/mapper/Live--OS--vg-root:   directory
/dev/mapper/Live--OS--vg-swap_1: directory
root@neon:~#

qelpp · 06-12-2020, 02:18 PM

Why isn't it asking for a passphrase?

Code:

root@neon:~# cryptsetup luksOpen /dev/mapper/Live--OS--vg-root  /dev/Live-OS-vg
root@neon:~#

If I use this, it does.

Code:

root@neon:~# cryptsetup luksOpen /dev/sda3 sda3_crypt
Enter passphrase for /dev/sda3:

Doesn't the last entry mean that it was opened?

Code:

root@neon:~# cryptsetup luksOpen /dev/mapper/Live--OS--vg-root
Command requires device and mapped name as arguments.
root@neon:~# cryptsetup luksOpen /dev/Live--OS--vg-root
Command requires device and mapped name as arguments.
root@neon:~# cryptsetup luksOpen /dev/Live--OS--vg-root  /dev/Live-OS-vg
Device /dev/Live--OS--vg-root doesn't exist or access denied.
root@neon:~# cryptsetup luksOpen /dev/Live-OS-vg-root  /dev/Live-OS-vg
Device /dev/Live-OS-vg-root doesn't exist or access denied.
root@neon:~# cryptsetup luksOpen /dev/Live-OS-vg  /dev/Live-OS-vg
root@neon:~#

GParted states that it isn't, that it is not accessible and closed.

---

If I supply the (thumbdrive event) passphrase for sd3_crypt, it is Open and Active --- with the VG of Live-OS-vg - Members: /dev/mapper/sda_crypt

Code:

root@neon:~# cryptsetup luksOpen /dev/sda3 sda3_crypt
Enter passphrase for /dev/sda3: 
root@neon:~#

Now that it is Open/Active it gives the same results as when it didn't ask for a passphrase, and GParted showed that it wasn't Open. ?????

Code:

root@neon:~# file -sL /dev/mapper/Live--OS--vg-root /dev/mapper/Live--OS--vg-swap_1
/dev/mapper/Live--OS--vg-root:   directory
/dev/mapper/Live--OS--vg-swap_1: directory
root@neon:~#

berndbausch · 06-12-2020, 05:55 PM

To open an encrypted device, you need to specify the name of the encrypted device as the first parameter. You, however, specify random device names, some ofwhich don't even exist.

After the second to last command, the device is open and can be accessed as /dev/mapper/sda3_crypt.

I don't see what gparted tells you, but the device dorsn't contain partitions anyway.

It's not clear to me what you want to achieve.

rknichols · 06-12-2020, 06:12 PM

Which passphrase are you using when you open those LUKS containers, your passphrase from the old system, or the one you used during the aborted installation? (I really hope you didn't use the same passphrase for both.)

Quote:

Originally Posted by qelpp

root@neon:~# file -sL /dev/mapper/Live--OS--vg-root /dev/mapper/Live--OS--vg-swap_1
/dev/mapper/Live--OS--vg-root: directory
/dev/mapper/Live--OS--vg-swap_1: directory
root@neon:~#
[/code]

That makes no sense whatsoever. There is no way those links should resolve to a directory inode. Let's trace the chain. What does "namei /dev/mapper/Live--OS--vg-root" report?

qelpp · 06-12-2020, 11:14 PM

Quote:

Originally Posted by berndbausch

I don't see what gparted tells you, but the device dorsn't contain partitions anyway.

It's not clear to me what you want to achieve.

What GParted recently showed me is what it showed me in the image file of Comment #1 on page 1 of this thread.

I want to do anything I can to recover several folders of markdown files from with the encrypted system. If I had the money I would send it to a recovery service.

I haven't done a manual install of LUKS for about two years, to create a custom sized swap, and haven't thought about LUKS, volume groups, PVs, LVs or anything of the sort since then, until last week.

Yes, I am confused of things like the why "sda3_crypt" asked for and responds to a passphrase, yet "Live-OS-vg" does not, yet it is what shows up after opening "sda3_crypt".

qelpp · 06-12-2020, 11:17 PM

Quote:

Originally Posted by rknichols

Which passphrase are you using when you open those LUKS containers, your passphrase from the old system, or the one you used during the aborted installation? (I really hope you didn't use the same passphrase for both.)

That makes no sense whatsoever. There is no way those links should resolve to a directory inode. Let's trace the chain. What does "namei /dev/mapper/Live--OS--vg-root" report?

The passphrase from the aborted installation.

Code:

root@neon:~# namei /dev/mapper/Live--OS--vg-root
f: /dev/mapper/Live--OS--vg-root
 d /
 d dev
 d mapper
 l Live--OS--vg-root -> ../dm-1
   d ..
   b dm-1
root@neon:~#

berndbausch · 06-12-2020, 11:30 PM

Quote:

Originally Posted by qelpp

haven't thought about LUKS, volume groups, PVs, LVs or anything of the sort since then, until last week.

Yes, I am confused of things like the why "sda3_crypt" asked for and responds to a passphrase, yet "Live-OS-vg" does not, yet it is what shows up after opening "sda3_crypt".

It's time to learn about LVM and LUKS, then. Plenty of introductory information is available.

Do you mean the disk was originally not encrypted? Then there are chances you can recover your data, especially if you are looking for text files.
If it was already encrypted before your accident, then you lost the master key, and no recovery service will be able to get the data back.

qelpp · 06-12-2020, 11:37 PM

Quote:

Originally Posted by berndbausch

Do you mean the disk was originally not encrypted?

It was encrypted, I had just used the LUKS/LVM check box in the KDE Neon install step because I no longer needed a larger swap so I went with their default LUKS install.

rknichols · 06-13-2020, 08:45 AM

Here's the situation:

As determined by your hexedit search, there is only one LUKS header present on the disk.
That header is unlocked by the passphrase from your aborted installation.
Thus, your original LUKS header no longer exists.

Without that original LUKS header, there is no possibility of recovering the master key that encrypts your old data. That data is forever unrecoverable.

End of story.

qelpp · 06-13-2020, 11:59 AM

Okay, I appreciate your and berndbausch's help in this matter.

Thank you.

qelpp · 06-13-2020, 12:08 PM

BTW, could you briefly explain what was unusual about these reports?

Quote:

Originally Posted by rknichols

That makes no sense whatsoever. There is no way those links should resolve to a directory inode. Let's trace the chain. What does "namei /dev/mapper/Live--OS--vg-root" report?

Re:

Code:

root@neon:~# file -sL /dev/mapper/Live--OS--vg-root /dev/mapper/Live--OS--vg-swap_1
/dev/mapper/Live--OS--vg-root: directory
/dev/mapper/Live--OS--vg-swap_1: directory
root@neon:~#

AND

Code:

root@neon:~# namei /dev/mapper/Live--OS--vg-root
f: /dev/mapper/Live--OS--vg-root
 d /
 d dev
 d mapper
 l Live--OS--vg-root -> ../dm-1
   d ..
   b dm-1
root@neon:~#

Thanks again.

rknichols · 06-13-2020, 01:55 PM

The target of the link /dev/mapper/Live--OS--vg-root is /dev/dm-1, which should be a block special device inode, not a directory. The file command should not be seeing a directory there. The output from "stat /dev/dm-1" might be interesting.

It really doesn't matter any more, since your needed LUKS header is gone.

qelpp · 06-13-2020, 06:27 PM

Quote:

Originally Posted by rknichols

The output from "stat /dev/dm-1" might be interesting.

If you tell me what to do, I'll do it for your future reference, before I erase the drive.

rknichols · 06-13-2020, 09:04 PM

Quote:

Originally Posted by rknichols

The output from "stat /dev/dm-1" might be interesting.

Quote:

Originally Posted by qelpp

If you tell me what to do, I'll do it for your future reference, before I erase the drive.

Perhaps run that stat command and post the output. I'm just vaguely curious. It really doesn't matter.