Solved Ext4 partition recovery advice needed

Solved issue

leprawel

New Member
Joined
Jun 3, 2024
Messages
2
Reaction score
3
Credits
23
I have the following problem. Gparted stopped responding after completing partition resize operation (ext4 3TB partition +3 TB to the left). After waiting for 2 days I killed the process. Now the newly created partition is corrupt. testdisk can see files on the parition and allow me to copy them just fine, however when I try to mount I get:
[ 291.942055] EXT4-fs (sda1): ext4_check_descriptors: Block bitmap for group 64 overlaps superblock
[ 291.942059] EXT4-fs (sda1): group descriptors corrupted!
What I tried:
  1. Select the 6TB partition displayed in testdisk and write it to disk. testdisk asked for reboot, after reboot nothing changed.
  2. sudo fsck -b 0 -B 4096 /dev/sda1 as testdisk superblock utility suggested. Result visible below. I didn't proceed with the operation because I want to be 100% sure I wont break something
[leprawel@leprawel-pc ~]$ sudo fsck -b 0 -B 4096 /dev/sda1
[sudo] password for leprawel:
fsck from util-linux 2.40.1
e2fsck 1.47.1 (20-May-2024)
Note: if several inode or block bitmap blocks or part
of the inode table require relocation, you may wish to try
running e2fsck with the '-b 8193' option first. The problem
may lie only with the primary block group descriptors, and
the backup block group descriptors may be OK.

Block bitmap for group 112 is not in group. (block 1162627398)
Relocate<y>? yes
Inode table for group 112 is not in group. (block 30350003432)
WARNING: SEVERE DATA LOSS POSSIBLE.
Relocate<y>? cancelled!
One or more block group descriptor checksums are invalid. Fix<y>? cancelled!
Group descriptor 112 checksum is 0x0000, should be 0xceba. IGNORED.
Group descriptor 112 has invalid unused inodes count 1024. Fix<y>? cancelled!

d: ********** WARNING: Filesystem still has errors **********
Some more info:
[leprawel@leprawel-pc ~]$ sudo mke2fs -n /dev/sda1
mke2fs 1.47.1 (20-May-2024)
/dev/sda1 contains a ext4 file system labelled 'd'
last mounted on /run/media/leprawel/d on Thu May 30 14:20:35 2024
Proceed anyway? (y,N) y
Creating filesystem with 802194176 4k blocks and 200556544 inodes
Filesystem UUID: b51a4617-ff2c-4fb4-a492-57a5c4105fe4
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848, 512000000, 550731776, 644972544
I am looking for advice on how to proceed. Files can be accessed without problem by testdisk so I assume there should be some kind of solution to recover the entire partition.
 


G'day leprawel, Welcome to Linux.org

Do you have any means to save the info/data from that drive?
 
I will send a call to other members who may have experience with this.

Be aware this an international site and time zones vary. there may well be delays due to differing times and members personal lives.
@osprey
@GatorsFan
@f33dm3bits
 
There appears to be two problems, which may intersect. One is the apparently corrupted superblock mentioned here:
Code:
[ 291.942055] EXT4-fs (sda1): ext4_check_descriptors: Block bitmap for group 64 overlaps superblock

The second is the problem of the invalid group descriptors.

Bear in mind that the filesystem that is being checked and hopefully repaired must be unmounted, and, that all the data that you wish to save ought to be backed up one way or another. There are risks.

The suggestion in the output of the fsck command show in post #1:
you may wish to try running e2fsck with the '-b 8193' option first.
is one command to try.

An alternative way of proceeding is to try and repair the filesystem from an alternative backup superblock. Since the backup superblocks appear to have been identified from the mke2fs command, they can be tried with a command like:
Code:
e2fsck -f -b 32768 /dev/sda1

The -f option will force checking, even the clean areas on disk, and the -b option selects an alternative superblock. In this case, the first backup superblock from the list was selected.

Note there are no guarantees with this since it depends on the state and possible damage to the disk. In my case these issues are treated from a rescue usb such as systemrescue which boots and usually has the tools to make the repairs.

Perhaps have a look here for one similar experience:
 
Last edited:
Welcome to the Forum.
1717483407464.gif


I always have a system backup for times like these.
1717483484684.gif
 
SO glad this worked for you - I haven't had this happen yet, but when it does.... I'm bookmarking this thread. :)
 

Members online


Latest posts

Top