world! [that's funny, it automatically takes out leading "hello"s]

I'm installing Ubuntu on a friend's laptop, and I encountered a problem while resizing the Ubuntu partition. I was expanding it to the left (move and resize), but the process was interrupted while it was performing the actual data copying. GParted says the partition is corrupted and the filesystem can't be read. Now, I'm not worried about reinstalling. The problem is that I had already copied some of the files over from the Windows partition.

How can I resume the copying process? Here's what GParted says about it:

Filesystem volume name: <none>
Last mounted on: /
Filesystem UUID: [tl;dt]
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal_ext_attr_resize_inode dir_index filetype extent flex_bg sparse_super large_file
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 1155072
Block count: 4619008
Reserved block count: 230950
Free blocks: 764535
Free inodes: 968259
First block: 0
Block size: 4096
Fragment size: 4069
Reserved GDT blocks: 1022
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8

Journal superblock magic number invalid!

Unable to read the contents of this filesystem!

One particular thing that intrigues me is the has_journal_ext_attr_resize_inode attribute under Filesystem features. It's as though it knows it was in the middle of a resize. Just a guess.


You can't; the filesystem is toast.

In order to resume the move, you would have to know exactly where you were in the process when it was interrupted.

As for the features, I think you inserted some underscores where there are none. has_journal, ext_attr, and resize_inode are separate features. The first is the ext3/4 journal that logs metadata updates to the fs so it can recover quickly after a crash. The second means that extended attributes are enabled, and the third allows the fs to be grown while it is still mounted. None of them have anything to do with gparted's moving of the partition.

Your only hope is photorec, which may be able to recover some files onto another disk, though without their names or other metadata.

  • Okay, in that case, how can I recover the files on it? – Jonah Jul 7 '12 at 18:56
  • @Jonah, you can't. – psusi Jul 8 '12 at 4:12
  • 2
    I figured it out, I recovered the files with the photorec utility in the disktest package. It got all of the files, but they lost their directory structure and filenames. – Jonah Jul 8 '12 at 22:03
  • I assume you mean the testdisk package – mace Aug 20 '18 at 10:24

I'm not exactly sure what you did there. Did you just expand the file system, or were you moving the partition too? Have you been copying file into that partition during resize? This is a very bad idea. Are those files from a windows partition you were trying to delete at the same time? This is really confusing.

If you're just trying to recover the file system and it has just a bad superblock, first make a backup of the drive and a dump of the broken file system, to not make things worse. Than try this: Linux: Find Alternative Superblocks

  • It was moving the partition at the time of the interruption. The computer was shut down by accident. – Jonah Jul 8 '12 at 1:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.