Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
root@neon:~# cryptsetup open /dev/sda3 sda3_crypt -- luks
Enter passphrase for /dev/sda3:
root@neon:~#
FIRSTLY I have to note that in the past I was quickly following your suggested commands and had forgotten that at the above step the passphrase was the one I had chosen for the install thumbdrive which I created that was the start of this issue. i had just tried the original passphrase, it failed, I automatically tried the thumbdrive passphrase, it worked, I moved on to your other suggestions... I apologize for not noting that significant difference.
root@neon:~# mkdir /sda3_crypt
root@neon:~# mount /dev/sda3_crypt/root /sda3_crypt
mount: /sda3_crypt: special device /dev/sda3_crypt/root does not exist.
root@neon:~# mount /dev/Live-OS-vg/root /sda3_crypt
mount: /sda3_crypt: wrong fs type, bad option, bad superblock on /dev/mapper/Live--OS--vg-root, missing codepage or helper program, or other error.
root@neon:~# mount /dev/mapper/Live--OS--vg-root /sda3_crypt
mount: /sda3_crypt: wrong fs type, bad option, bad superblock on /dev/mapper/Live--OS--vg-root, missing codepage or helper program, or other error.
root@neon:~# mkdir /Live-OS
root@neon:~#
root@neon:~# mount /dev/mapper/Live--OS--vg-root /Live-OS
mount: /Live-OS: wrong fs type, bad option, bad superblock on /dev/mapper/Live--OS--vg-root, missing codepage or helper program, or other error.
I will wait for a suggestion before using the terminal again.
root@neon:~# mount /dev/mapper/Live--OS--vg-root /Live-OS
mount: /Live-OS: wrong fs type, bad option, bad superblock on /dev/mapper/Live--OS--vg-root, missing codepage or helper program, or other error.
Thats's what I feared. /dev/mapper/Live--OS--vg-root contains no filesystem. I am afraid the data on this disk is lost.
It could wipe out all the files in a 230MB disk in a few seconds? I use dd urandom, which I know takes a long time, but a few seconds to wipe all the files off? Not just some header or indices or whatever, everything?
Code:
neon@neon:~$ sudo mount /dev/mapper/sda3_crypt/root /sda3_crypt
mount: /sda3_crypt: special device /dev/mapper/sda3_crypt/root does not exist (a path prefix is not a directory).
Specifically what is the difference? Why exactly does "(a path prefix is not a directory)" mean the files were deleted?
Code:
neon@neon:~$ sudo mount /dev/mapper/Live-OS-vg/root /sda3_crypt
mount: /sda3_crypt: special device /dev/mapper/Live-OS-vg/root does not exist.
It could wipe out all the files in a 230MB disk in a few seconds? I use dd urandom, which I know takes a long time, but a few seconds to wipe all the files off? Not just some header or indices or whatever, everything?
It wipes out the LUKS header in a few microseconds. Without the LUKS header, the bits that used to be your files may still be there, but nobody and nothing can decrypt them. It's like having to read an Egyptian text after losing the stone of Rosetta.
Quote:
Code:
neon@neon:~$ sudo mount /dev/mapper/sda3_crypt/root /sda3_crypt
mount: /sda3_crypt: special device /dev/mapper/sda3_crypt/root does not exist (a path prefix is not a directory).
Specifically what is the difference? Why exactly does "(a path prefix is not a directory)" mean the files were deleted?
Code:
neon@neon:~$ sudo mount /dev/mapper/Live-OS-vg/root /sda3_crypt
mount: /sda3_crypt: special device /dev/mapper/Live-OS-vg/root does not exist.
Neither /dev/mapper/Live-OS-vg/root nor /dev/mapper/sda3_crypt/root exist, therefore they can't be mounted. I suppose that the absence of /dev/mapper/sda3_crypt is processd by one branch of the code, and the fact that /dev/mapper/Live-OS-vg exists but is not a directory (or the other way around) is processed by another, thus leading to different error messages.
In any case, "a path prefix is not a directory" doesn't mean that files were deleted. It's not an example for a particularly well-written error message, but you often get error messages that are somewhat hard to understand.
It's not directly a filesystem, but an LVM Physical Volume (PV) which can contain Logical Volumes (LVs) where filesystems reside. Now that you have the LUKS volume unlocked, you can run "lvs" to see what LVs exist, and the "lsblk -f" command should dig down into those LVs and report what filesystems it finds. You should be able to mount those filesystems and see what they contain.
I've avoided getting involved here until now because you were already getting good advice and I hate joining situations that have little chance of success. I fear you will find that the LUKS volume and LVM structure within it were created by your accidental installation run. Your only hope of recovering your data would be if that LUKS volume were not at the same physical disk location as was your old one. You can scan the disk for additional LUKS headers by running a binary editor like hexedit on the whole disk (i.e., /dev/sda, not /dev/sda3) and searching for the hexadecimal sequence
4C 55 4B 53 BA BE
That's the ASCII characters "LUKS" followed by the hex bytes 0xBA and 0xBE. If you should find that at some location other than the start of the current partition 3, it might be your old LUKS header. It's still a long shot that the LUKS header and its key material are uncorrupted, but at least there would be something more to look at.
I installed hexedit and then used the command "hexedit /dev/sda" and it appeared to complete extremely quickly, is that really normal going through a 230GB drive? Or are you saying that it isn't going through 230GBs, just some header or something with no multi-gigabyte contents.
Using "Find" it did not find the sequence 4C 55 4B 53 BA BE, in fact it only found two occurrences of 4C, and that's it fifth down on the left column and at the bottom.
Here are the last lines after rows of zeros, with the total at the bottom.
root@neon:~# mount /dev/sda3/Live--OS--vg-root /sda3_crypt
mount: /sda3_crypt: special device /dev/sda3/Live--OS--vg-root does not exist (a path prefix is not a directory).
root@neon:~# mount /dev/mapper/Live--OS--vg-root /Live-OS
mount: /Live-OS: wrong fs type, bad option, bad superblock on /dev/mapper/Live--OS--vg-root, missing codepage or helper program, or other error.
root@neon:~# mount /dev/mapper/Live--OS--vg-root /sda3_crypt
mount: /sda3_crypt: wrong fs type, bad option, bad superblock on /dev/mapper/Live--OS--vg-root, missing codepage or helper program, or other error.
root@neon:~# mount /dev/mapper/sda3_crypt /sda3_crypt
mount: /sda3_crypt: unknown filesystem type 'LVM2_member'.
I installed hexedit and then used the command "hexedit /dev/sda" and it appeared to complete extremely quickly, is that really normal going through a 230GB drive? Or are you saying that it isn't going through 230GBs, just some header or something with no multi-gigabyte contents.
It doesn't read the whole disk, just a few disk blocks. You don't have that much RAM anyway.
It might be an interesting exercise to analyze the data structures on the disk, but you won't be able to decrypt your data with hexedit.
root@neon:~# mount /dev/sda3/Live--OS--vg-root /sda3_crypt
mount: /sda3_crypt: special device /dev/sda3/Live--OS--vg-root does not exist (a path prefix is not a directory).
You can't mount /dev/sda3/Live--OS--vg-root because there is no file with that name.
Quote:
Code:
root@neon:~# mount /dev/mapper/Live--OS--vg-root /Live-OS
mount: /Live-OS: wrong fs type, bad option, bad superblock on /dev/mapper/Live--OS--vg-root, missing codepage or helper program, or other error.
/dev/mapper/Live--OS--vg-root exists, but it can't be mounted because it contains no filesystem.
Quote:
Code:
root@neon:~# mount /dev/mapper/Live--OS--vg-root /sda3_crypt
mount: /sda3_crypt: wrong fs type, bad option, bad superblock on /dev/mapper/Live--OS--vg-root, missing codepage or helper program, or other error.
It still contains no filesystem.
Quote:
Code:
root@neon:~# mount /dev/mapper/sda3_crypt /sda3_crypt
mount: /sda3_crypt: unknown filesystem type 'LVM2_member'.
/dev/mapper/sda3_crypt also contains no filesystem. It does contain LVM data structures.
I installed hexedit and then used the command "hexedit /dev/sda" and it appeared to complete extremely quickly, is that really normal going through a 230GB drive? Or are you saying that it isn't going through 230GBs, just some header or something with no multi-gigabyte contents.
Using "Find" it did not find the sequence 4C 55 4B 53 BA BE, in fact it only found two occurrences of 4C, and that's it fifth down on the left column and at the bottom.
You must not have done the search properly, since that sequence is absolutely known to exist at least once on the disk.
To search in hexedit:
Run "hexedit -s /dev/sda". The "-s" option formats the display on 512-byte sector boundaries.
In hexedit, type the "/" character (or Ctrl-s). The text "Hexa string to search:" will appear in the middle of the window.
Type the characters "4c554b53babe" (without the quotes, case does not matter) and press <Enter>. hexedit will begin searching through the disk and stop at the first occurrence of that sequence. If it's not at the start of a sector (hex address is a multiple of 0x200), ignore it. That sequence appears inside the cryptsetup executable, among other places.
If the location is at the start of a sector, make note of the address.
Press "/" and <Enter> to continue the search with the same sequence. Repeat steps 4 and 5 until no more occurrences are found.
In addition, you can see if anything recognizable exists on those Logical Volumes by running "file -sL /dev/mapper/Live--OS--vg-root /dev/mapper/Live--OS--vg-swap_1" I suspect that the file command will just report "data" for both, because those volumes were almost certainly created by the installer and probably not yet formatted.
4DCFFFF0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
4DD00000 4C 55 4B 53 BA BE 00 01 61 65 73 00 00 00 00 00 LUKS....aes.....
--- sda --0x4DCFFFE0/0x37E4896000--sector 2549759---------------------
^^^^with this as the bottom line^^^^
Last night on the hexedit manpage I just noticed the very limited Synopsis, of which --help was no help. I did use > to go to the end of the file, but didn't notice the Ctrl-S & Ctrl-R (and would never have known to enter "/") because the items above those didn't seem like anything I wanted to do, I did try Home & End which were disappointing. Thank you. I had used the Find selection of the terminal to look for the string.
Last edited by qelpp; 06-12-2020 at 01:47 PM.
Reason: clarification
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
