Re: [dm-crypt] Moving LUKS-LVM partition with KDE Partition Manager broke it

["Michael Kjörling" <michael@kjorling.se>]

On 15 Oct 2019 06:16 +0000, from hijackeel@gmail.com (Hijack Eel):
> However, things went wrong when I used KDE Partition Manager to move the
> shrunken LUKS partition to the right. After that, the partition's type
> showed up in partitionmanager and gparted as "unknown" instead of LUKS, and
> trying to run cryptsetup luksOpen returned that the partition "is not a
> valid LUKS device".
> 
> I did manage to recover the LUKS header from the freshly unallocated space
> between the Windows and LUKS partitions by using hexdump and dd. Decrypting
> the LUKS partition using the recovered header (i.e: sudo cryptsetup
> --readonly --header /path/to/recovered/header/file luksOpen /dev/partition
> <insert some name here>) seems to work in the sense that cryptsetup accepts
> my password, and the mapping shows up in /dev/mapper. However, lvdisplay
> and vgdisplay detect nothing, and mounting it fails.

So it sounds like the data, including LUKS metadata, is (at least
mostly) intact, and that you've now got a copy of the LUKS header and
know a corresponding passphrase. That's good; whatever you do, take
care to not do anything that would jeopordize that.

I would very strongly suggest making a full disk copy of what you
currently have, if at all possible, and then working with one of the
copies while strictly not touching the other; in case you make a
mistake at some point, that would allow for far easier recovery to at
least where you are now. (If you care about your data, a second
same-size HDD should be cheap insurance against mistakes, and you can
always use it for regular backups later.)

It's not entirely surprising if the partition offsets are wrong that
LVM would not recognize the contents of the LUKS container, since LVM
metadata would not be where it is expected to be relative to the
container start, even if the decryption itself yields useful
plaintext.

As for what to try to recover from this, I don't have a handy
step-by-step guide ready for you, but I would consider trying to
figure out the original partition offsets for the now-moved partition,
feeding those original offsets to losetup, and try to open the LUKS
container through that mapping. (This should be plenty doable without
touching the current, broken, partitioning.) If that works, then see
what lsblk as well as the LVM tools can tell you about the contents of
the container at that point.

It's certainly possible that all you'd need to do in the end is to
restore the original partition offsets and perform the resizing all
over again.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
  “The most dangerous thought that you can have as a creative person
              is to think you know what you’re doing.” (Bret Victor)