root@neon:~# cryptsetup luksOpen /dev/sda3 sda3_crypt
Enter passphrase for /dev/sda3: 
root@neon:~# stat /dev/dm-1
  File: /dev/dm-1
  Size: 0               Blocks: 0          IO Block: 4096   block special file
Device: 6h/6d   Inode: 677         Links: 1     Device type: fd,1
Access: (0660/brw-rw----)  Uid: (    0/    root)   Gid: (    6/    disk)
Access: 2020-06-14 16:38:02.417892970 +0000
Modify: 2020-06-14 16:38:02.417892970 +0000
Change: 2020-06-14 16:38:02.417892970 +0000
 Birth: -
root@neon:~#

OK, it's a block special file just as it should be, or at least it is now. I have no idea why the file command would have reported it as a directory.

It still shows that.

stat /dev/dm-0 shows this:


And namei /dev/mapper/sda3_crypt shows this

No, now it's showing "data", which is what I would expect from an device that has never been formatted with a filesystem. Before, it was showing "directory", which is impossible for a device. Looking back (#46. #47), I now see you had run some very inappropriate mkdir commands, which put directories in /dev/mapper where a successful luksOpen would have created symlinks to dm-* devices. Sorry, I didn't notice that before.

I rebooted prior to #63; and after #64 had to log out. If that makes any difference in today's results.

Whatever files and directories you create in the /dev filesystem will disappear when you reboot. /dev is recreated at each system startup, based on the hardware that the kernel discovers. This is why you get different results at different times.

Earlier, you created directories here and there and everywhere under /dev, which led to the result in https://www.linuxquestions.org/quest...ml#post6133591. All that is gone now.

You seem to be thorougly confused by mountpoints, logical volumes, devices files and symbolic links. I would grab an intermediate Linux course, book or tutorial and learn about these things; this is fundamental knowledge required for managing a Linux system.

This is what happened.

When you open your LUKS device with cryptsetup open /dev/sda3 sda3_crypt --type luks, a new device mapper device is created, named /dev/dm-# (where # is an autoincrementing number). This device represents the decrypted data. Whatever you write to it will be encrypted and stored on /dev/sda3, and whatever you read from it will be read from /dev/sda3, then decrypted.

In addition, the cryptsetup open command results in the creation of a symbolic link /dev/mapper/sda3_crypt, which is a different name for the same /dev/dm-# device.

Now, the data on /dev/mapper/sda3_crypt or /dev/dm-# can't be used immediately. In your case, an LVM physical volume has been created on top of that device. On that physical volume, you find several logical volumes (which you can loosely consider to be "flexible partitions").

One of the logical volumes is named Live-OS-...root. The installer was able to create the encrypted device, the physical volume and the two logical volumes, but at this point you noticed your mistake and hit the back button, which prevented the installer from creating a filesystem on top of that logical volume. This is why you can't mount it.

Your disk contains a hierarchy of data:

sda contains partitions sda1, sda2, sda3
sda3 contains a LUKS device
The LUKS device contains a physical volume
The physical volume contains two logical volumes named root and swap
The root logical volume is meant to contain the root filesystem (but doesn't because the installation was aborted)

Thank you