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

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

[Hijack Eel]

[-- Attachment #1: Type: text/plain, Size: 2087 bytes --]

Hello,

I hope someone on this list can help me fix a stupid mistake I made. My
apologies if this is not the right place. This page made it sound like it
would be ok to ask for help here:
https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions

My computer is set up to dual boot Windows and Linux. Directly after the
main Windows partition, is a LUKS-encrypted partition containing 3 LVM
logical volumes, set up following this guide:
https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide

In case it is useful information, I actually followed "Option 6" in the
guide (i.e. using a password only):
https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Using_Your_New_Gentoo_System_under_OpenRC#Migrating_Off_the_Boot_USB_Key_.28Optional.29

Recently, I wanted to increase the Windows partition by 100 GB. This meant
shrinking my LUKS partition by 100 GB, and moving it to the right 100 GB,
to free up space on the left for Windows.

I successfully shrank the LUKS partition, and tested it by booting into
Linux and viewing my data.

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.

In the worst case, I do have a qcow2 image of my entire disk that is
several months old that I may be able to use to recover most of my data,
but I would like to try that last.

Thanks in advance to anyone who can help!

[-- Attachment #2: Type: text/html, Size: 2730 bytes --]

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

[Michael Kjörling]

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)