1

There is a number of other questions on this topic, however majority concerns formatted partitions or drive failure. In my case:

During resizing and moving 2.7TB partition in Gparted, I encountered an error that froze the whole program. (I dont have a screenshot or output from it, as fas as I remember, it was something about error when reading partition).

I ran mkfs.ext4 -S and fsck.ext4 -y.
It took it couple of days,then the system was crashing because it ran out of RAM and SWAP (8+8GB). After adding 200GB of swap, fsck ran for about two weeks but suddenly stopped with an error, unfortunately I didnt screenshot.

I tried running the same combination of mkfs and fsck again, but this time every time fsck ran, it made two cores of my CPU to go 100% and utterly froze the entire system. Not even alt+sysrq REISUB worked. This happened 2-3 times.

The current output from fsck is:

ext2fs_open2: Bad magic number in super-block fsck.ext4: Superblock invalid, trying backup blocks... fsck.ext4: Bad magic number in super-block while trying to open /dev/sdd1 The superblock could not be read or does not describe a valid ext2/ext3/ext4 filesystem. If the device is valid and it really contains an ext2/ext3/ext4 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 <device> or e2fsck -b 32768 <device>

when running sudo e2fsck -b 8193 or 32768, the output is:

e2fsck: Attempt to read block from filesystem resulted in short read while >trying to open /dev/sdd1 Could this be a zero-length partition?

I tried running testdisk but it stops at 2026 cylinder and does not go any further no matter how long I wait. I do have a backup made by ddrescue, but because of that I completely ran out of free space on any of my drives.

I fear, that error during moving/resizing partitions has made all the data on the partition chopped up and unintelligible to data recovery software.

I will appreciate any kind of suggestion as to what my next step should be.
Should I give up and dd the image back to the partition and try again with fsck?
Thank You

Improve this question

1 Answer 1

Reset to default
0

Do you know if the original resize/move failed when moving the partition, or when resizing the partition?

If it was during a move, then a good approach is to restore the dd image and try to figure out where the sectors are duplicated, and where the duplication (or copy) of sectors stops. From there you can work backwards to piece the two halves of the partition together.

If the problem occurred during a resize operation, and tools like fsck cannot fix the problem, then you might consider trying to recover the data files with a disk scanning tools such as photorec.

Improve this answer
2
  • I chose to BOTH move and resize the 3TB partition. I do not know which operation Gparted prioritizes, move or resize. Since the error froze gparted I couldnt see the step it was on. As for dding back the partition and looking at sectors. Ive never done that, wouldnt know how to look for those sectors and how to fix it. Maybe I will look for answers to this in askubuntu archive. I used photorec with no effect. I wanted to run sleuthkit autopsy, but they warn to have a backup of the img, but I dont have any more space for another 3TBimg atm. Do You have any experience with autopsy?
    – User2256
    Aug 10, 2014 at 6:24
  • Thank You Curtis for answering! Really happy someone noticed my issue
    – User2256
    Aug 10, 2014 at 6:25

You must log in to answer this question.

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