A story fairly similar to this one happened to me yesterday.

Update: My only hard drive /dev/sda was originally partitioned this way:

Device Boot Start End Blocks Id System /dev/sda1 * 2048 1026047 512000 83 Linux /dev/sda2 1026048 976773119 487873536 83 Linux 

/dev/sda1 is the /boot partition, it is not encrypted. The /dev/sda2 partition was originally a LUKS partition containing the volume group fedora_hostname, which itself contained the following logical volumes:

/dev/mapper/fedora_hostname-root /dev/mapper/fedora_hostname-home /dev/mapper/fedora_hostname-swap 

I was on a live disk, just about to shrink the /dev/sda2 partition following those steps when I abruptly had to stop and unplug my computer. I just had mounted the partition using

cryptsetup luksOpen /dev/sda2 ExistingExt4 

and had a look around the place (first time I was playing with LVM & LUKS), mounting and unmounting the different logical volumes (swap, root, home), when I had to hastily shut the terminal down without closing the LUKS partition (exit; exit). Not really paying attention, I withdrew the live CD before the end of the shutdown procedure and turned the laptop off pressing the power button.

When I started the computer a few hours later, the boot hung at "Reached Target Basic System"; the only hint I got from booting from the hard drive in rescue mode was

dracut-initqueue [...] unit file of systemd-cryptsetup@luksMYUUID changed on disk 

Using a rescue disk, I opened the drive (cryptsetup luksOpen /dev/sda2 ExistingExt4) and I inquired the status of the partition using e2fsck, which returned a pretty

fsck.ext4: Superblock invalid, trying backup blocks... fsck.ext4: Bad magic number in super-block while trying to open /dev/sda2 

pvdisplay returned that all PE were free (so the volume was shown as virtually empty), and vgscan shared that opinion, too, mentioning that my volume group did not contain any logical volume. lvdisplay returned nothing.

I had not resized anything yet, so I was very puzzled by the problem.

testdisk /dev/mapper/ExistingExt4 

showed the right volumes (swap, root and home) and allowed access to all data on the system, so I chose to Write partition to the disk, hoping that I could see them after rebooting. That did not happen however, although fdisk -l /dev/mapper/ExistingExt4 now returns

Disk /dev/mapper/ExistingExt4: 465.3 GiB, 49958403712 bytes, 975742976 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 / 4096 bytes Disklabel type: dos Disk identifier: 0x0000000 Device Boot Start End Blocks Id System /dev/mapper/ExistingExt4p1 * 2048 8161279 4079616 82 Linux swap / Solaris /dev/mapper/ExistingExt4p2 8161280 870885375 431362048 82 Linux /dev/mapper/ExistingExt4p3 870885376 975742975 52428800 82 Linux 

I'm still not able to mount the volumes individually as I was able to unmount them when everything was O.K.. In fact, I cannot find them in /dev/mapper. Additionally, since I copied the table to the disk, that I cannot see the physical volumes anymore, let alone the groups and the logical volumes (pvscan, vgscan & lvscan commands return nothing). But I remain confident and I am sure that the solution to this problem is not so far fetched:

• Maybe renaming the volume entries in the partition table to match the original ones in the grub. <-- Unlikely
• Maybe find a backup and restore the system using vgcfgrestore or equivalent. <-- Possible
• Maybe rewrite the superblocks on the disk using mke2fs -S, as was proposed in the story I mentioned at the beginning. testdisk is positive about the size of the blocks: 4096. <-- Risky

But all those solutions (and the other ones you might propose) go beyond my limited knowledge of the logical volume system, as the reading may have disclosed already. I would like to know which procedure would be suitable to boot again properly.