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.
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.
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?
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?
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?
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.
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: