1 Topic by errrarehumanumest

  • errrarehumanumest
  • New member
  • Offline
  • Registered: 2012-11-04
  • Posts: 4

Topic: Crash while Resizing (move start to "left") -> ext3-"/home" corrupt

Hello,
I made a big mistake and have NO backup.

motivation: I deleted one older partition and wanted to put the freed GiB to my /home-partition (ext3-formatted).
Everything was processed with a promising look (read-only test OK, ...) when my laptop decided to shutdown due to overheating ...
So I rebooted and took a look with GParted (running from Linux Mint 13 from a usb-stick):

http://morke.bplaced.net/ext3/gparted_view.png

As you can see, the original partition /device/sda5 with size 191 Gib (or so) is now 222 GiB and not readable.
So when it crashed during the process of moving the beginning (data) to the left (which would be the case if "increasing with space in before"), then there should be the data with a block of "nothing" in between. Only the rest of the data has to be moved and then the partition table has to be restored/recreated somehow.

=====================
When I first tried to recover the sparse superblocks with system-tools I got:

mint@mint ~ $ sudo mke2fs -n /dev/sda5
mke2fs 1.42 (29-Nov-2011)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
14614528 inodes, 58432387 blocks
2921619 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
1784 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872

When I check the given blocks with: (the same for every other block-number)

mint@mint ~ $ sudo e2fsck -b 2654208 -B 4096 /dev/sda5
e2fsck 1.42 (29-Nov-2011)
e2fsck: Bad magic number in super-block while trying to open /dev/sda5

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
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>

=====================
Then I gave Testdisk a try (snippet from its logfile):
this is from the advanced view mode: there it suggests to try some sparse blocks, but this results in "bad magic number at the beginning of ..."

Interface Advanced
Geometry from i386 MBR: head=255 sector=63
NTFS at 32219/15/53
NTFS at 32231/206/40
check_part_i386 failed for partition type 83
get_geometry_from_list_part_aux head=255 nbr=1
get_geometry_from_list_part_aux head=8 nbr=1
get_geometry_from_list_part_aux head=16 nbr=1
get_geometry_from_list_part_aux head=32 nbr=1
get_geometry_from_list_part_aux head=64 nbr=1
get_geometry_from_list_part_aux head=128 nbr=1
get_geometry_from_list_part_aux head=240 nbr=1
get_geometry_from_list_part_aux head=255 nbr=1
 1 * Linux                    0   1  1  2594 131 33   41680833
     ext3 blocksize=4096 Large file Sparse superblock, 21 GB / 19 GiB
 2 E extended LBA          2594 131 34 32219  15 52  475918336
   X extended              2594 131 35  3120 226 50    8456191
 6 L Linux Swap            2594 164  3  3120 226 50    8454144
     SWAP2 version 1, pagesize=4096, 4328 MB / 4128 MiB
 5 L Linux                 3121   4 20 32218 254 62  467459098
 3 P HPFS - NTFS          32219  15 53 32231 206 39     204800 [System-reserviert]
     NTFS, blocksize=4096, 104 MB / 100 MiB
 4 P HPFS - NTFS          32231 206 40 38913  37 36  107335680 [Festplatte]
     NTFS, blocksize=4096, 54 GB / 51 GiB
search_superblock
search_superblock

recover_EXT2: s_block_group_nr=0/158, s_mnt_count=1/27, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 5210104
recover_EXT2: part_size 41680832
Ext2 superblock found at sector 2 (block=0, blocksize=4096)

block_group_nr 1

recover_EXT2: "e2fsck -b 32768 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=1/158, s_mnt_count=0/27, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 5210104
recover_EXT2: part_size 41680832
Ext2 superblock found at sector 262144 (block=32768, blocksize=4096)

block_group_nr 3

recover_EXT2: "e2fsck -b 98304 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=3/158, s_mnt_count=0/27, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 5210104
recover_EXT2: part_size 41680832
Ext2 superblock found at sector 786432 (block=98304, blocksize=4096)

block_group_nr 5

recover_EXT2: "e2fsck -b 163840 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=5/158, s_mnt_count=0/27, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 5210104
recover_EXT2: part_size 41680832
Ext2 superblock found at sector 1310720 (block=163840, blocksize=4096)

block_group_nr 7

recover_EXT2: "e2fsck -b 229376 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=7/158, s_mnt_count=0/27, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 5210104
recover_EXT2: part_size 41680832
Ext2 superblock found at sector 1835008 (block=229376, blocksize=4096)

block_group_nr 9

recover_EXT2: "e2fsck -b 294912 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=9/158, s_mnt_count=0/27, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 5210104
recover_EXT2: part_size 41680832
Ext2 superblock found at sector 2359296 (block=294912, blocksize=4096)

block_group_nr 25

recover_EXT2: "e2fsck -b 819200 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=25/158, s_mnt_count=0/27, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 5210104
recover_EXT2: part_size 41680832
Ext2 superblock found at sector 6553600 (block=819200, blocksize=4096)

block_group_nr 27

recover_EXT2: "e2fsck -b 884736 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=27/158, s_mnt_count=0/27, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 5210104
recover_EXT2: part_size 41680832
Ext2 superblock found at sector 7077888 (block=884736, blocksize=4096)

block_group_nr 49

recover_EXT2: "e2fsck -b 1605632 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=49/158, s_mnt_count=0/27, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 5210104
recover_EXT2: part_size 41680832
Ext2 superblock found at sector 12845056 (block=1605632, blocksize=4096)

block_group_nr 81

recover_EXT2: "e2fsck -b 2654208 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=81/158, s_mnt_count=0/27, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 5210104
recover_EXT2: part_size 41680832
Ext2 superblock found at sector 21233664 (block=2654208, blocksize=4096)
  Linux                    0   1  1  2594 131 32   41680832
superblock 0, blocksize=4096 []
superblock 32768, blocksize=4096 []
superblock 98304, blocksize=4096 []
superblock 163840, blocksize=4096 []
superblock 229376, blocksize=4096 []
superblock 294912, blocksize=4096 []
superblock 819200, blocksize=4096 []
superblock 884736, blocksize=4096 []
superblock 1605632, blocksize=4096 []
superblock 2654208, blocksize=4096 []

To repair the filesystem using alternate superblock, run
fsck.ext3 -p -b superblock -B blocksize device

TestDisk exited normally.


TL;DR
Resized ext3-partition with GParted; Crash in between; impossible to recover data because partition-table is missing

What else can I try? Do I just use the wrong parameters for e2fsck?

2 Reply by gedakc

  • gedakc
  • Developer
  • Offline
  • Registered: 2007-11-30
  • Posts: 4,592

Re: Crash while Resizing (move start to "left") -> ext3-"/home" corrupt

When GParted grows a partition to the left, it first tries reading all sectors in the current partition.  If no bad sectors are found, then GParted will start copying, sector by sector, starting with the the front of the original partition, and finishing at the end of the original partition.  After that GParted will grow the file system to fill the new partition.

From your description, it would appear that the process was halted in the copying sector by sector stage.  Unfortunately we do not know at which sector the copy operation stopped.

This leaves two scenarios:

1)  If you can find at which sector the copying stopped, you could finish the copy by dd'ing the remaining portion of the file system to join up with the already copied portion.

2)  If the copy failed early on, then it is possible that the entire original partition is still completely intact.  In this situation you would only need to restore the original partition boundaries.  Unfortunately we don't know if this is the case because one really needs to know at which sector the copy operation stopped.

The best chances for recovery would be from pursuing scenario, 1 and 2 above.  Others have posted in this forum about their efforts to determine where the copy operation failed.

A third option is to use a tool like photorec to try to recover any recognizable files.  This option does not restore the partition.

3 Reply by errrarehumanumest (edited by errrarehumanumest 2012-11-04 18:56:36)

  • errrarehumanumest
  • New member
  • Offline
  • Registered: 2012-11-04
  • Posts: 4

Re: Crash while Resizing (move start to "left") -> ext3-"/home" corrupt

Thank you for your answer - I am starting to go crazy why I am unable to recover ....
Beside: I gave photorec a short try, but you can imagine what is recovered from a 200 GiB-home-directory with a lot of unncecessary data. Without the structure it is like "everything is gone" ...

So, if I understood you correct, then I need to search the whole partition /dev/sda5 for superblocks? I think, it should be possible to recognize them from their magic number. But "scanning" will take some time.
I am currently dumping the partition which will be scanned to a backup-devide with dd.

Any suggestions how I can start the scan for remaining superblocks?

Or: any keywords how to search for the location where the resizing/move stopped?

4 Reply by class413 (edited by class413 2012-11-04 18:45:55)

  • class413
  • Moderator
  • Offline
  • Registered: 2007-05-25
  • Posts: 2,376

Re: Crash while Resizing (move start to "left") -> ext3-"/home" corrupt

It is safer to keep a backup copy using dd of the hard drive on another disk, so that you are able to retry the recovery.

EDIT
I see that you already proceed to the backup copy.

*** It is highly recommended to backup any important files before doing resize/move operations. ***

5 Reply by gedakc (edited by gedakc 2012-11-04 19:04:39)

  • gedakc
  • Developer
  • Offline
  • Registered: 2007-11-30
  • Posts: 4,592

Re: Crash while Resizing (move start to "left") -> ext3-"/home" corrupt

It would be worth some of your time to search the GParted forums for how others have done this.  I am not sure that all of the details were posted, but reading these posts might help you find out how to do this.   When you do figure it out, it would be helpful if you could post your findings.  That would help others.  Of course the first thing is to figure out how to do it for yourself.

EDIT:  You might want to search the Internet too.

6 Reply by errrarehumanumest

  • errrarehumanumest
  • New member
  • Offline
  • Registered: 2012-11-04
  • Posts: 4

Re: Crash while Resizing (move start to "left") -> ext3-"/home" corrupt

I am currently searching this forum and also the internet. But since nobody updates titles after finding the solution this takes time.

Situation is: ext3-partition which is separated after moving stopped due to a crash. I don't know the exact offset, but I have the following idea:
* scan the whole partition for existing (sparse) superblocks (dumpe2fs does not work)
* get an overview how mke2fs would create the superblock-layout (positions) for the original size of the partition
* compare this against the found locations of the superblocks: somewhere in-between there should be a gap (= offset)
* if I can live with loosing some files, then I can try to move the remaining "rest" left and then recover the partition
(* or: I can try to compare blocks with some kind of hashing and find out the location of the gap in this way)

But anyway: that are only ideas ... if I would just have made a backup before trying such a simple "resize partition"-operation

7 Reply by gedakc

  • gedakc
  • Developer
  • Offline
  • Registered: 2007-11-30
  • Posts: 4,592

Re: Crash while Resizing (move start to "left") -> ext3-"/home" corrupt

Yes, a backing up first is the best way to proceed.  Of course saying that now doesn't help.

With some perseverance your efforts should become a beacon of hope for others in the future.

8 Reply by errrarehumanumest

  • errrarehumanumest
  • New member
  • Offline
  • Registered: 2012-11-04
  • Posts: 4

Re: Crash while Resizing (move start to "left") -> ext3-"/home" corrupt

Just to keep you up to date:

My first idea to search with dd and grep -b for the magic numbers turned out to be to slow, then I stumbled over a nice program from someone who had the same problem (superblocks being not where they belong)

original source: ht tp://schumann.cx/e2sl/
better version (last post): http://forum.hddguru.com/ext3-filesyste … 12415.html

When I run the optimized version on the partition, then I get some resutls. Still have to wait for the dd-backup until I (possibly) finally destroy my data ....

9 Reply by gedakc

  • gedakc
  • Developer
  • Offline
  • Registered: 2007-11-30
  • Posts: 4,592

Re: Crash while Resizing (move start to "left") -> ext3-"/home" corrupt

'Sounds like you are making good progress.  I'll keep my fingers crossed for good luck.