1 (edited by RecursiveCursive 2018-10-01 21:03:37)

Topic: Ext4 grow and move interrupted

I was trying to increase the size of my Ubuntu partition from 150GB to 200GB wyith some free space which was to the left of the partition. I livebooted Ubuntu from a USB stick and used GParted to resize and move the data. However, about 5-10 min later, my laptop froze and wouldn't update the display. I thought that the process might be going on without updating the display and so, I left it for 4 hours (more than the estimated time of <1 hour) and turned off the liveboot as there was nothing useful that I could do then. Upon rebooting into the liveboot, I couldn't mount the partition, but it showed a size of 200GB. Is there any way to recover it? I could get a crude screenshot of the frozen GParted window https://i.imgur.com/mPjHNDZ.jpg. (Image: Command used - e2image -ra -p -o 53687091200 /dev/sda7; Copying 5689166/36741784 blocks (15%)) Is there any way I can get back a working drive?

I have tried solutions from a bunch of sources, and will detail them below:
1) askubuntu.com/a/328369 -  I tried the Python script in the solution and found that most of the sectors at the start of the enlarged partition were 0's and the first non-zero sector did not match with any sector in the disk. (addendum: the sectors were zero according to python but not according to hexdump)
2) gparted-forum.surf4.info/viewtopic.php?id=14753 - Using sudo mke2fs -n /dev/sda7, I got this -
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
    4096000, 7962624, 11239424, 20480000, 23887872
Trying to hexdump these blocks gave me nothing useful (or I couldn't figure out what to do).
I took some help from the linked topic gparted-forum.surf4.info/viewtopic.php?id=15293 also.
3) Testdisk - I could recover my home directory (a few files failed though) in this method. I couldn't figure out how to rescue the original partition

I have made an image of the broken partition so I think I can muck around a bit trying to recover this.

On a slightly unrelated note, does e2image copy sequentially? In that case my data should be preserved as it is as 15% of 150GB is ~23GB which is less than the 50GB extra space. Right?

I have posted the partition information as seen from GParted below

<i>Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          9a673f6f-01b9-4fb3-9ddf-d872309ba652
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 huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              9830400
Block count:              39320832
Reserved block count:     1966041
Free blocks:              2578124
Free inodes:              7111035
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1014
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
RAID stride:              32732
Flex block group size:    16
Filesystem created:       Wed May 17 00:00:29 2017
Last mount time:          Sat Sep 29 18:54:18 2018
Last write time:          Sun Sep 30 00:41:24 2018
Mount count:              0
Maximum mount count:      -1
Last checked:             Sun Sep 30 00:41:24 2018
Check interval:           0 (<none>)
Lifetime writes:          1564 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:              256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      c1524cd5-e977-4732-8023-55190cc1eae6
Journal backup:           inode blocks</i>

<i>dumpe2fs 1.42.13 (17-May-2015)
Journal superblock magic number invalid!</i>

<i>Unable to read the contents of this file system!
Because of this some operations may be unavailable.
The cause might be a missing software package.
The following list of software packages is required for ext4 file system support:  e2fsprogs v1.41+.</i>