How to restore a broken luks-encypted home partition after a failed partition change?

Hello everybody!

I could use some help in restoring my luks-encrypted home partion. At the moment there are only some 94 GiBs of an unknown file system where once my partition was.

The setup:
I am using a 250 GB hard drive in dual-boot mode with Windows.
sda1 and sda2 are ntfs partitions that use the first 125 GiB on the hard drive. sda4 is an extended partition of 129 Gib, that contains sda5 as a root (24.29 GiB), sda6 (93.75 GiB) as my home and sda7 as swap (8.98 GiB). Also there is some unallocated space between sda5 and sda6.

What happened:
I ran out of space on my root partition, thus I couldn’t do any kinds of updates. I reckoned that this might be a deeper issue to fix since I didn’t really install a lot of programs after initial installation and even a “paccache -rk 1” didn’t fix that problem for long. So I decided to use the unallocated space that was left on the hard drive and extend my root partition.

for that I booted my external diagnostic drive which is a spare SSD with a Manjaro installation and started KDE partition manager.
Initially this space was allocated after my swap, so I decided to move all partitions a bit back until the free space would be next to my root partition and then expand this partion.

Unfortunately, the worst possible happened: Something happened to the external drive somehow mid-operation, crashing X and KDEs partition manager. I was on the toilet when it happened. So I am not sure at what point it failed. But judging from the current setup it seems like it successfully relocated both sda6 and sda7, but broke sda6 in the process. The free space is still present.
I blame something in the USB connection for this. At the moment the partitions in the diagnostic drive is broken in the way that its Manjaro aborts booting at some point.

So I could use some hints as to how to progress with this one. At the moment I am in a bit of a shock and don’t even know where to start with this. Fortunately, the most important stuff is backed-up, but some more recent things aren’t so far.

Does anyone have any idea how to start with this problem?
Thanks!

Some additional Info from FDisk

Disk /dev/sda: 250.1 GB, 250059350016 bytes
255 Köpfe, 63 Sektoren/Spur, 30401 Zylinder, zusammen 488397168 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Festplattenidentifikation: 0x38d7d07a

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sda1   *        2048     1026047      512000    7  HPFS/NTFS/exFAT
/dev/sda2         1026048   214434233   106704093    7  HPFS/NTFS/exFAT
/dev/sda3       486553968   488397167      921600    7  HPFS/NTFS/exFAT
/dev/sda4       214434234   486553967   136059867    5  Erweiterte
/dev/sda5       214436282   265369599    25466659   83  Linux
/dev/sda6       271108096   467714047    98302976   83  Linux
/dev/sda7       467716096   486553599     9418752   82  Linux Swap / Solaris

I tried to find some residuals of my luks header, But I’m not sure how to interpret the results. It seems like it is still there…right?

sudo hexdump -C //dev/sda |grep LUKS
3ce9ee70  20 4c 55 4b 53 01 17 50  61 72 74 69 63 69 6a 61  | LUKS..Particija|
3cebe6e0  6e 01 14 4c 69 6e 75 78  20 4c 55 4b 53 2d 70 61  |n..Linux LUKS-pa|
3cedf320  4c 55 4b 53 20 62 c3 b6  6c c3 bc 6d c3 bc 01 14  |LUKS b..l..m....|
3cf09b60  d0 b7 d0 b4 d1 96 d0 bb  20 4c 55 4b 53 20 d0 9e  |........ LUKS ..|

not sure why there are multiple results, though. So I considered to

cryptsetup -v luksOpen /dev/sda6 sda6_crypt

but even if it would open, how would I restore it properly so it can be opened automatically?

The only thing you can do is to restore your crash-proof backup:

and to remember that with great security comes great responsibility, so if you don’t have a backup, even the NSA will not be able to get your data back…

Broken LUKS container = lost data.

:sob:

Thanks for the feedback, I just saw that post of yours.
I still haven’t given up hope with this one. The reason is that I found an undamaged LUKS header at

242019041280 LUKS

242019041320 xts-plain

I performed a

losetup --find --show --read-only --offset 135870283776 /dev/sda

followed by

sudo cryptsetup luksOpen /dev/loop0 luksrecovery

which worked well. I was asked about my passphrase and it got accepted. My guess is that the header wasn’t yet moved during the repartitioning process.
Trying to mount it resulted in an error stating Line 9 of my etc/fstab seems to be wrong. I’m not sure this is relevant in this case, though, a this probably does not refer to the fstab of the system to recover. But it’s probably a hint that the file system is corrupted.

Interestingly, after performing luksOpen I can see the general file structure of my home now, I thought I would have to do a

sudo ecryptfs-recover-private .Private/

in order to properly open the home.

Also, I can now access some files just fine, whereas some others cannot be opened. I guess the file system might be broken as some part of it was probably already written on another part of the drive before the crash.

So my guess is that I have to either restore the initial structure of the drive before by repartitioning attempt, or I try to repair the file system as is.

I was giving this some more thought. I am still puzzled why I can access some of my files. Shouldn’t the partition be scrambled since it got relocated? I would expect fdisk to show me an empty space where the partition currently lies. Rather it detects it as sda6. How is that?

As already stated:

So it’s like a corrupted ZIP file: some files can still be read and the corruption happens after that point in the container and those files are irrevocably lost and hence why:

With great security comes great responsibility.

:man_shrugging: :cry:

So depending on where the corruption happened in the container 1% gets lost (corruption happened at the complete end) or 100% lost (corruption happened at the 1st byte)

While I get that I was wondering what exactly makes the container broken in that case. Mabe I am not understanding LUKS properly but I thought that the container was moved and brokes while repartitioning. That might mean that another partitioning tool like testdisk might be able to revert the container to its previous state. After all, testdik can locate previously overwritten filesystems as well. So why not locate LUKS container parts as well?

Or maybe a simple ext4.fsck on the loop device might suffice? After all, fsck is quite the potent tool.

TL;DR

  • Unless you have a backup of your files, information has been lost. The amount of lost data depends which physical sector/block/… that got corrupted and can vary from 0,00001% up to 100% of lost data.
  • That is why there is an adagio that goes with great security comes great responsibility and why you should always back up encrypted information.

The long version:

From the authors of testdisk here:

As the content of a LUKS partition is encrypted, Testdisk cannot look inside. There are a few pieces of information at the beginning of a LUKS partition that suggest that it’s the beginning of a LUKS partition.

IOW: from a testdisk perspective, a LUKS partition is just garbage pseudo-random noise.

  • So it’s like a corrupted ZIP file: some files inside the ZIP archive can still be read and the files that are stored after the point in the container where the corruption happened are irrevocably lost.

  • If you don’t know how ZIP files work and have never encountered a corrupted ZIP file, let me try to explain it differently:

    • Encryption turns readable text into unreadable text.

    • The simplest cypher is Caeser’s cypher and turns:

      hello world
      

      into:

      ifmmp xpsme
      
    • Most modern encryption algorithms (like AES ) use a sliding cypher that uses the output of the previous encrypted block as input to encrypt the next block, so if a block in the middle is just of by one bit, everything after that block is just so much garbage.

For more information, please read this excellent article:

1 Like