Repair a "wrong fs type, bad option, bad superblock"

From wiki.morphey.org

Jump to: navigation, search

A lot of times understood that the superblock of a hardisk is damaged. The generic error is this:

 
...
Mounting local filesystems: mount: wrong fs type, bad option, bad superblock on /dev/sdc.
...
 

Some times, all it takes is effecting a fsck -y /dev/sdc (thing that he is automatically effected generally at boot). Other times, we have lost the whole block instead index of the hd. A backup is generally, effected in automatic on the hd of the superblock.

The location of this backup I am generally:

8193, 32768, 98304, 163840, 229376 and 294912. (8193 in many cases only on older systems, 32768 is the most current position for the first backup)

To see if indeed the block is (for instance) 32768 (used often in the last times), the command can be given:

 
root@mx [~]# dumpe2fs /dev/sdc1|grep 32768
dumpe2fs 1.35 (28-Feb-2004)
Blocks per group:         32768
Fragments per group:      32768
Group 1: (Blocks 32768-65535)
  Backup superblock at 32768, Group descriptors at 32769-32769
Group 10: (Blocks 327680-360447)
  Block bitmap at 327680 (+0), Inode bitmap at 327681 (+1)
  Inode table at 327682-328190 (+2)
Group 100: (Blocks 3276800-3309567)
  Block bitmap at 3276800 (+0), Inode bitmap at 3276801 (+1)
  Inode table at 3276802-3277310 (+2)
root@mx [~]#
 

How you can see in:

 
...
Group 1: (Blocks 32768-65535)
  Backup superblock at 32768, Group descriptors at 32769-32769
...
 

We have our backup. To restore him to the superblock in position 0, we can give this command:

 
root@mx [~]# e2fsck -b 32768 /dev/sdc1
 

his way we have restored the superblock. If the backup is not 32768 we have to try all the others (also making some greps inside the dumpe2fs).

Personal tools