I recently had an infrequently used hard drive fail to mount, and upon inspection I found that it was no longer recognizable and an error was being produced at the console:

mount: wrong fs type, bad option, bad superblock on /dev/hdc1,
missing codepage or other error
In some cases useful info is found in syslog – try
dmesg | tail or so

And doing a dmesg gives the following output:

EXT3-fs: unsupported inode size: 0

So what to do, what to do? What does this mean?

What is happening is that the the superblock is corrupted. Fortunately there is a backup of the superblock elsewhere, and the location of it depends on the block size used on the partition. To replace the main superblock with a backup (alternative) superblock, use this command:

fsck -b 32768 /dev/sdh1

Of course, the number after the “-b” switch should be one of these values, depending on block size used on your file system:

• 1k blocks = 8193
• 2k blocks = 16384
• 4k blocks = 32768

The location of your partition (‘/dev/sdh1′ in my case) must be changed according to your actual partition location as well.

So how do you tell what size blocks your partition uses? Well, I have read a suggestion of running fsck with the ‘-n’ switch on your partition to get that information; that didn’t work at all for me. In fact, that would crash with the output of

fsck.ext3[5618] trap divide error rip:2aaefe7b7b57 rsp:7fffac521f50 error:0

So instead, I just made a guess that my drive used 4k blocks (which it does), and fsck worked like a charm. I can now mount the drive and get the data off that I thought was gone forever. (Note: you might want to make a backup copy using dd or something similar before messing with your partitions!)