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