Re-partition Operation Failed

[Graciano Goudreau]

HiI'm unable to mount my LUKS encrypted partition after a failed resize operation on KDE's partition manager. The device has a lot of important data on it and I really hope I can get it back.

Only thing I did differently was use KDE Partition Manager to do the job and not lvextend.

Now the entire drive won't read at all. I don't see anything in dmesg, although it's possible I missed something. lsblk shows nothing.

This problem seems to occur a lot with KDE Partition Manager. I can't tell if it's related to the encryption or not, but it's definitely correlated to KDE Partition Manager.

Then think about remove partition sda2 and do undo of shrink partition sda1 but don't do it by KDE Partition Manager; use for example cfdisk, parted for it. Then enlarge lvm, your filesystem on it and see what display fdisk, lsblk, try to mount it but read only, don't write anything to it until it mount successfully and you check it you can read your files without error.

Okay, so here's a complicated story:

After I attempted to delete /dev/sda2 and expand /dev/sda1 with kde partition manager, my OS would no longer boot after a restart. It was stuck on vendor logo of Bios screen. In my trying to get it to boot up, I switched SATA controller to Intel RST instead of AHCI and also disabled SATA controller completely.

I should have known what Intel RST would do, that's enough to cause a dysfunction, but I actually was panicking and made my previous post with SATA controller completely disabled.

I eventually fixed my OS boot process by putting in a Kubuntu Live USB and commenting out the swap entry in my fstab.

So you're sure I should delete /dev/sda2 and expand /dev/sda1 with cfdisk or parted? Should I do this with it decrypted or encrypted? I hope I can get this right.

Also, hopefully I got the formatting right on this post, I'm new.

Restoring the previous partition table w/ eg. cfdisk is "safe" (first close the luks container again)

You can then try to re-open LUKS and if that succeeds to mount the partition.

Iff however you're then prompted to run an fsck DO NOT RUN A DESTRUCTIVE FSCK ON THE DRIVE!

You can run an analysis to see how much is broken, but the very first thing you want to establish is that you're looking at your decrypted data!

I don't have another blank drive that is bigger than it, to make an image onto. It's a 2TB drive and if there is a way to make an image of only the data, I can afford that (it's probably like 25-50% full and I have other 500GB drives. But if you mean for me to clone the entire drive, I don't have 2TB of free space anywhere. Maybe if there is a way to clone it in parts, like a split up rar file (.r01, .r02, .r03, etc) Even then I don't know if I have enough space.

Is there a way to clone it in parts, and do you mean the entire drive or just the actual data?

Yes, I did it online with the partition mounted as root. I blame KDE Partition Manager for allowing it. We can do lots of stuff nowadays, even hotplug RAM into/from a live system. I thought it was okay to resize as long as the GUI allowed me to.

About expanding the partition back with cfdisk, I'm pretty sure someone on IRC told me to only do that with the drive decrypted/unlocked. You're saying the opposite?

Not saying you're wrong, it could be the IRC guy was wrong, or maybe I'm just completely mistaken and either misunderstood his instructions or I'm misunderstanding your instructions, I really don't know, just trying to get clarification here.

Thanks for the help, I really appreciate it.

There're essentially two things that can have happened here:

1. You resized only the partition but not the luks container nor the filesystem inside

2. You resized the partition and the luks container, but not the partition inside.

The suggestion on IRC *might* have been to resize the FS (not the GPT partition) to the current luks container (when the container is unlocked, it's not possible otherwise) - that would be the correct action in the second case because the data outside the luks container has likely been lost anyway.

You could check the output of "cryptsetup status" for the device to see the size of the luks container, if it exceeds the partition size the container has probably not been resized and, depending on whether you've previously written to the designated swap partition, data that might have resided there *might* still be salvageable.

If it's not (and the filesystem error actually suggests that and that case 2 is what has happened) probably the only thing left to do is to resize the filesystem and hope that it didn't contain any important data (what at 25%-50% isn't even all that unlikely)

Thank you I resized the partition to expand it to the entire drive with LUKS decrypted, and now it works again. It did require a reboot before it would mount.

I feel extremely lucky right now. Although I supposed I was pretty unlucky that this happened in the first place.

If you resized it w/ only c/fdisk it should not matter whether the LUKS container was decrypted, otherwise you might have silently re-expanded the container and the end of the filesystem cotains random data instead of yours. This might not even be a problem because of its limited usage, but w/o understanding what has happened you also can't be sure about that.

You also want to check the "cryptsetup status" to see whether the containerhas actually retained its full size through all of this.

In that case you originally only changed the partition table, what is completely transparent (you can do and undo that w/o any harm to the underlying partitions and filesystems as long as you're not writing around on them otherwise, eg. run mkfs on your fun-partition layout)

i tried resizing and rearranging my partitions with kde partition manager on a live USB, the idea being to take my boot drive and prepare it for a dd transfer to a faster drive i had. unfortunately, the operation failed after some 4 hours on the final step, checking the partitions. the end result is now i have no idea whats actually where on the disk, and i could really do to recover some of the configuration files, notes on things, and scripts i had stored in my home directory.

testdisk doesnt seem to find much of anything, sudo btrfs filesystem show /dev/sde yields nothing, sudo btrfs check /dev/sde finds no valid filesystems on it, all permutations of sudo btrfs inspect-internal dump-super with respect to existing partitions and superblock numbers yields either a blank result or ERROR: bad magic on superblock. im not even sure that the existing partitions line up with where the data would be, given i both re-arranged and shrunk various partitions.

beyond this i have no idea how best to proceed with data recovery. id wager theres a chance my configs and scripts exist on the disk to be found, but i dont know what tools or procedures i aught to be using on linux with respect to btrfs. anyone got any tips or things i should look at or into?

well that sounds like a fun way to spend a week kek. if i go about trying to find individual files, is there any tool for that on linux? iirc theres plenty of windows tools with that sort of functionality for raw disks.

the partitions all have the layout i wanted after the operation was complete, but some are unknown format according to kde partition manager. i have tried pointing said tools both at the raw disk device, as well as the partitions themselves, all to no avail.

good call. the first mystery partition is a valid NTFS one so apparently my windows partition was moved without issues, but the one im mainly interested in in the BTRFS linux one, which produces garbled output upon inspection of the partition its supposed to be in with hexdump.

3a8082e126