1

I was installing windows and I accidentally deleted the 2TB LUKS encrypted hard drive where I store my important things.

So after realizing my mistake I immediately rebooted into a live Ubuntu disk and installed Ubuntu on my SEPARATE hard drive just to have a system to work on. I searched around and found out about testdisk. I managed to retrieve the Linux header (I believe its still intact).

Here's what my partition table looks like:

Here's what my partition table looks like

I do not know what to do from here. All the other forums I read about similar problems on were too specific to the person including things I didn't have problems with.

Any hints?

Improve this question
8
  • Before even attempting to recover the LUKS container, it's important to have a backup of the entire thing. Assuming your LUKS container is in a partition on the disk, recovery involves recreating the partition without accidentally writing data within the partition; that would corrupt it. Do you have a backup?
    – Emmanuel Rosa
    Sep 4, 2017 at 16:59
  • Do I create a backup of just /dev/sdb1 (see image) or more? How would I go about making a backup? Should I go to another place with backup questions maybe?
    – chisp2000
    Sep 4, 2017 at 17:01
  • Well, sdb1 is only 2 MB, so I doubt your LUKS container is in it. You'd want a raw, byte for byte, backup the entire disk sdb. Of course, you'd have to have enough space for it, but say... /mnt/backup is a mounted filesystem without enough space, you can backup the disk into a file with dd. Something like this: dd if=/dev/sdb of=/mnt/backup/mybackup.img But first check the dd man page because there are some options for controlling how much data to copy at a time. Copying only one byte at a time would be slow.
    – Emmanuel Rosa
    Sep 4, 2017 at 17:07
  • I usually use the option bs=4M will this be applicable in this situation? Also when it is put into .img file will it be compressed? As I don't actually have enough space on my computer to save the backup onto it (that's why I got the 2TB drive xP).
    – chisp2000
    Sep 4, 2017 at 17:10
  • 4M is fine. The .img file will not be compressed. While you can pipe the output of dd to something like bzip2, because the disk contains encrypted (random-looking) data it won't compress well. But it really depends on how much of the disk contains random-looking data. For example, if you wrote random junk to the disk prior to creating the LUKS container, as often recommended, then there's not much that can be compressed. On the other hand, if the disk was blank prior to creating the LUKS container, then the areas on the disk which have not been used will compress well.
    – Emmanuel Rosa
    Sep 4, 2017 at 17:22

1 Answer 1

Reset to default
1

Based on the screenshot and our discussion, it looks like testdisk discovered your LUKS header and put it in it's own partition, leaving the rest of the LUKS container in the unallocated space. The LUKS header is stored at the beginning of the partition (or disk when not using partitions); unless you use a detached header.

LUKS format uses a metadata header and 8 key-slot areas that are
being placed at the beginning of the disk. https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions

So based on this, the solution is to resize sdb1 so that it encompasses the entire disk. There are a few things to keep in mind while resizing:

  1. The starting offset of the sdb1 partition must remain intact. In other words, you must not perform a move operation.
  2. Only resize the partition, not the filesystem.
  3. In reality, you're not resizing the partition, you're instead recreating it in the MBR. It's just that the GParted resizing operation makes it easier because it fills in the partition starting offset for you.

The instructions for resizing a partition with Gparted are here: https://gparted.sourceforge.io/display-doc.php?name=help-manual#gparted-resize-partition

There are a couple of things worth noting about the instructions. First as I mentioned earlier, the partition starting offset must remain intact. Here's the TIP from the instructions:

If you do not want the start of an existing partition to move, then do not change the free space preceding value.

And there's a TIP about LUKS which doesn't apply because you're not really resizing, instead your recreating the partition as it once was:

A LUKS encrypted partition and the file system within can only be resized when the encryption mapping is open.

After all this is set and done and your NTFS mounts OK, I recommend running a filesystem check to ensure your content is alright.

Improve this answer
8
  • Alright so I tried resizing the partition in GParted, but it says "Linux Unified Key Setup encryption is not yet supported." in the information page of /dev/sdb1. I looked it up and basically GParted does not support resizing LUKs partitions.
    – chisp2000
    Sep 5, 2017 at 15:53
  • 1
    Arg! Gparted is trying to be smart. You may have to go with a "dumber" tool, like fdisk. In that case, what you have to do is make note of the starting offset (save a screenshot somewhere), delete the partition, and recreate it with the same starting offset but including the remainder of the disk.
    – Emmanuel Rosa
    Sep 5, 2017 at 17:33
  • How do I go about finding the starting offeset data?
    – chisp2000
    Sep 5, 2017 at 18:01
  • You can get it from fdisk with the "p" command. This video will give you a sense of what it's like to use fdisk. WARNING: Don't use the "w" command until you are ready to commit to the new partition. youtube.com/watch?v=5kVAzxTwy5Q
    – Emmanuel Rosa
    Sep 5, 2017 at 19:49
  • I forgot to mention you should probably back up your LUKS header. It's so vulnerable yet only 2MB. The command would be something like: cryptsetup luksHeaderBackup --header-backup-file ~/luks_header.img /dev/sdb1
    – Emmanuel Rosa
    Sep 5, 2017 at 19:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .