How to fix messed up Logical Volumes From (initramfs) shell? (Linux, ElementaryOS)

Solution 1:

Mappings are ephemeral, like mounts, and the "mapper" isn't a property of the encrypted disk – it's a component of the currently running OS. Similarly, the 'devtmpfs' filesystem that's mounted on /dev always represents mappings established on the running OS – your physical disk shouldn't even have a /dev/mapper or indeed anything else inside /dev.

So if you connect the same disk to a completely different Linux system (with its own DM modules and everything) and still cannot access the disk, the problem is almost certainly not with device-mapper but with something else that is part of the disk.

For example, the LUKS metadata header on the disk could've gotten corrupted (it is used to actually set up the DM mapping). This is somewhat unlikely, as cryptsetup does prompt for passphrase without complaints, but it could be (if somewhat unlikely) that the installer set up two LUKS volumes with the same passphrase, and the first unlocked successfully but the second didn't.

The "No medium found" error message for /dev/sda is somewhat concerning. The only time it should normally show up is if the device is in fact just a drive/reader without any media inserted, e.g. a SD card reader with no card in it¹ . Use lsblk -S or ls -l /sys/class/block/sda to find out. (If the message ever shows up for an HDD or SSD or USB stick, it pretty much means that device is dead.) That being said, from Elementary OS it seems that your system disk is NVMe, so /dev/sda isn't that.

¹ (CD/DVD drives are 'sr', not 'sd', so even if you have one, it's not the cause of the error.)

I would suggest starting with lsblk (alone; with -f; with -S) from another working Linux system, finding your disk there, and trying to unlock each LUKS volume manually through command line, i.e. using cryptsetup open. From the screenshot it seems that you're supposed to have LVM inside LUKS, so after unlocking the LUKS volumes run lsblk -f again to see if the contents are recognized, and pvscan -ay (or whatever command LVM uses again) to see if the LVM metadata is working. (It seems that the boot process first opens a LUKS volume and names the mapping "cryptdata", then expects LVM to set up a logical-volume mapping named "data-root" on top of that.)