Cannot mount hard disk: block count exceeds size of device --- bad partition table

R00ts · 05-11-2011, 01:21 PM

I have one hard disk (call her HDA) that contains nothing but a single ext4 partition containing a backup of all my important data. Last night I did a clean install of Ubuntu 10.10 on my primary hard disk (call her HDB) and from there proceeded to upgrade directly to Ubuntu 11.04 upgrade. In 10.10, I was able to read HDA just fine. However after the upgrade, I can no longer mount this drive.

When mounting from file browser:

Code:

Error mounting: mount: wrong fs type, bad option, bad superblock on /dev/sda,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

The end of dmesg said the following:

Code:

dmesg | tail
[   82.130904] EXT4-fs (sda): bad geometry: block count 122096646 exceeds size of device (122096381 blocks)

Okay, so for some reason my hard disk has a block count greater than the size of my device. I've done my background searching on this and tried a command line utility I've never heard of before:

Code:

# sudo e2fsck /dev/sda
e2fsck 1.41.14 (22-Dec-2010)
The filesystem size (according to the superblock) is 122096646 blocks
The physical size of the device is 122096381 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? yes

I used the following guide to try using a backup superblock to restore my disk.
http://www.cyberciti.biz/faq/recover...ted-partition/

However, it failed complaining of the same problem.

Code:

$ sudo fsck -b 32768 /dev/sda
fsck from util-linux-ng 2.17.2
e2fsck 1.41.14 (22-Dec-2010)
The filesystem size (according to the superblock) is 122096646 blocks
The physical size of the device is 122096381 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? yes

So if its not the super block that's corrupt, its probably the partition table, right? I found the following thread of someone else who experienced a very similar problem to me, although the cause of the problem was different (he was resizing a partition manually). I took a look at the partition table for my unmountable drive.
http://gparted-forum.surf4.info/viewtopic.php?id=14172

Code:

$ sudo sfdisk -d /dev/sda
# partition table of /dev/sda
unit: sectors

/dev/sda1 : start=        0, size=        0, Id= 0
/dev/sda2 : start=        0, size=        0, Id= 0
/dev/sda3 : start=        0, size=        0, Id= 0
/dev/sda4 : start=        0, size=        0, Id= 0

Wow. Well that doesn't look right. SDA is a brand new drive that I got yesterday explicitly for backing up my data so I could do a clean OS install to my main drive (the one that currently works). I used the Ubuntu disk utility to format the entire disk as a ext4 filesystem (so I would assume that would only create a single partition?) and copied all my data there, then checked that I could access the data from the drive before I began my clean OS install.

Ran some fdisk commands on the drive as well to see if it had anything interesting to say.

List partition tables (yes, it shows no partitions):

Code:

$ sudo fdisk -l /dev/sda

Disk /dev/sda: 500.1 GB, 500106780160 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System

Give partition size in blocks:

Code:

$ sudo fdisk -s /dev/sda 
488385527

-----

So, this is as far as I've gotten. This drive holds over a decade's worth of work for me and is extremely valuable. I really didn't think that the Ubuntu upgrade process would mess with this drive, seeing as the Ubuntu install was contained on an entirely different drive. What is it that I need to do to restore my drive to working status?

kilgoretrout · 05-11-2011, 02:35 PM

You have real problems. Either the partition table is badly corrupted or you have a hardware problem. There is no point in trying to run fsck utilities here; you need to run those on a partition(eg sda1, sdb3, sdc1, etc), not on an entire hard drive(eg, sda, sdb) like you attempted to do.

First, I recommend that you download PartedMagic from here:

http://partedmagic.com/doku.php?id=news

and burn the iso as an image. PartedMagic contains a great number of hard drive and partitioning utilities. The one you will be most interested in is called "TestDisk".

Second, double and triple check all wiring and cabling to your problem hard drive. Something may have just gotten loose. You may want to pull the drive and put it in one of these devices:

http://www.geeks.com/details.asp?invtid=2020

They are pretty cheap and are very handy for dealing with problem hard drives. You may also want to download the hard drive manufacturer's diagnostic utilities and run them on your problem drive. All the majors have them on their websites in the form of downloadable iso files from which you make a bootable cd and run their diagnostic utilities. Bottom line, you want to eliminate the possibility of this being a hardware problem. I think there is a decent chance that this is hardware related as opposed to a corrupted partition table, i.e. your drive may just be bad or the wiring got jostled loose. You wouldn't be the first person to get a DOA hard drive or have a drive go bad shortly after installation.

Third, if the hard drive checks out OK from a hardware perspective, you can attempt to repair the partition table using TestDisk. I'm not familiar with the details of its use but here are a couple links to get you pointed in the right direction:

http://www.cgsecurity.org/wiki/TestDisk

http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step

Edit: How did you create your original ext4 partition on your problem hard drive, i.e. what partitioning tools did you use and how did you setup the partition, eg primary, extended, etc.?

R00ts · 05-11-2011, 03:29 PM

Thanks for your response. I'll look into the solutions you suggested and report my findings. A loose wiring problem isn't all that unlikely, as I just installed this hard disk in my PC yesterday before doing the data backup and OS install. It also makes the most sense, as I don't see how or why the Ubuntu upgrade process would screw up a drive that it wasn't supposed to write to this badly. (Ironically, this problem drive *is* a replacement drive as the original drive I bought was in fact DOA and had to be returned).

I formatted the drive using the "Disk Utility" program that comes with Ubuntu. I selected the command "Format Whole Volume" and used the ext4 filesystem. I believe this formats the entire drive as a single partition, as I don't recall needing to then use the utility to partition the drive. After the format I was immediately able to read/write files to the drive with no problem, and even after installing Ubuntu 10.10 (before the upgrade to 11.04) I could access this drive without a problem.

syg00 · 05-11-2011, 06:43 PM

Quote:

Originally Posted by R00ts

Wow. Well that doesn't look right.

... At least you don't appear to have panicked and made this worse.
Hopefully not as bad as it looks - with luck just the partition table, and not the actual data, is gone. As to why it happened t all is a major worry.

Testdisk as suggested above is the normal answer to these sort of things, but if it was me and I was sure it was just one partition, I'd use fdisk to (re-)create a single partition on the drive. Take all the defaults - start at the beginning, end at the end. Do *not* make a filesystem on it.
See if you can mount that. If not merely delete the partition definition from fdisk.

kilgoretrout · 05-12-2011, 03:21 PM

Quote:

I formatted the drive using the "Disk Utility" program that comes with Ubuntu. I selected the command "Format Whole Volume" and used the ext4 filesystem.

I had a feeling you might have done this. You may have done the same thing I did when I got a new backup hard drive. When I chose the "Format Whole Volume" option in Ubuntu's Disk Utility and formatted ext4, I think I had the same problem you did. I'm not sure exactly what happened, but IIRC I was able to write data to the drive after the operation and read it but I could never remount it successfully afterwards. In my case it was an external esata hard drive which was only mounted for backup operations. All the other disk partition utilities I used to try and figure out what was going on showed there was no partition created on the hard drive. I suspect that somehow an ext4 filesystem was created on the raw drive without any partition being first created which at the time I didn't think was possible. In my case since it was a backup drive and I didn't need to worry about losing data, I just partitioned the drive with gparted, formatted the partition and reran my backup.

I wish I could be of more help regarding how to recover your data. I'm pretty sure my memory is reasonably accurate as to what happened to me when using Disk Utility on a fresh unpartitioned hard drive and choosing the same option you did. I'm not sure TestDisk will help if no partition was ever created on the drive.

syg00 · 05-13-2011, 03:18 AM

Good point @kilgoretrout, I hadn't considered that. You can certainly format the block device itself rather than a partition. If this is what has happened, ignore my advice above - that may (will) obliterate 16 bytes. Not normally a consideration if partitions are used.

Have you tried to resize the filesystem smaller (resize2fs) ?

R00ts · 05-13-2011, 05:51 PM

Sorry I haven't been more responsive in my own thread. I checked the cabling yesterday and everything appears to be plugged and snug. There was a big lightning storm in the area all day yesterday so I didn't get around to trying anything else, since it seemed like a bad idea to be trying to recover a hard disk when power loss was likely.

Yes, I am pretty sure I did format the block device itself rather than a partition. No, I haven't tried to resize the filesystem. Is that something that I should attempt to do given this new information?

One option I was considering was to re-install a temporary image of Ubuntu 10.10 on my primary drive, since 10.10 was able to read/write data to that drive just fine before the upgrade. I'm not too confident that this will work though, because I'm pretty sure it was the 11.04 upgrade that screwed everything up. In particular during the upgrade process, I remember some grub menu popping up during the software install asking about partitions and the like. I specifically instructed grub -not- to concern itself or mess with my backup drive, but maybe it ignored me (it did make my main drive unbootable, which I had to manually set the bootable flag for the partition before I could get into Ubuntu).

R00ts · 07-23-2011, 05:08 PM

Hello again. I never resolved this issue and put it off for several months but I'm ready to give it another shot again. First, a quick recap:

- My hard disk contains several gigs of valuable data that I can not access
- This disk has no partitions (I'm pretty sure)
- I can not mount this drive on my system nor have I found a way to access the data in any way
- I formatted the entire volume as an unpartitioned ext4 space and copied all of my data over to it, before it became unreadable after an upgrade to the latest Ubuntu

I've installed the testdisk application and ran it to try and determine the state of my harddisk, which I still believe has no partitions but is formatted entirely in ext4 and contains all of my backup data. I've been reading through the TestDisk documentation to try and figure out what I need to do. For now, I've run the application directly and had it analyze my hard disk. It first informs about hidden sectors on the disk:

Code:

Disk /dev/sda - 500 GB / 465 GiB - ATA ST3500418AS

Hidden sectors are present.

size       976771055 sectors
user_max   976771055 sectors
native_max 976773168 sectors
dco        976773168 sectors
Host Protected Area (HPA) present.

And then allows me to continue. From there it requests that I select the partition table type. This I'm not sure what to select since I have no partitions on the drive, so I tried two different options: "Intel" and "None". It warns me that its very rare for a drive to be non-partitioned and therefore for "None" to be a valid option to choose. After I selected the type, I selected "Analyze", which searches the current partition structure and searches for lost partitions.

Attached are the analyze results for both the "Intel" and "None" options when selecting the partition table. I'm still going through them myself and trying to make sense of it all. By the way the name I assigned to this volume is "Backup", so you might see that in some places.

I'll keep updating this thread as I try new things or learn new information until my problem is resolved (as I want anyone who experiences a similar problem to be able to follow what I did to fix it). I don't have any direct questions to ask yet, but if you have time to take a moment and examine these logs or suggest what it is I need to do in TestDisk to make my data accessible again, please do share what you know. Thanks!

R00ts · 07-28-2011, 01:05 AM

I've tried to find a backup superblock on my disk using the instructions on this page: http://www.cgsecurity.org/wiki/Advan...kup_SuperBlock

Unfortunately, the scan did not find any superblocks (probably because there were no partitions). I've written up an e-mail to TestDisk support to see if they can answer the question of is it possible to recover ext4 filesystem data that was stored on a non-partitioned drive. I'll report back with what they say when I get a response. In the mean time, I am completely out of ideas for what I could try.

R00ts · 07-28-2011, 02:09 AM

PROBLEM SOLVED

I was suggested to do the following:

Code:

$ sudo fsck.ext4 /dev/sda
e2fsck 1.41.14 (22-Dec-2010)
The filesystem size (according to the superblock) is 122096646 blocks
The physical size of the device is 122096381 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? no

Backup contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Backup: 223131/30531584 files (0.1% non-contiguous), 44383187/122096646 blocks

$ sudo mkdir /mnt/backup

$ sudo mount -t ext4 /dev/sda /mnt/backup
mount: wrong fs type, bad option, bad superblock on /dev/sda,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Looks familiar. And looking at dmesg | tail:

Code:

$ dmesg | tail
[359222.668707] EXT4-fs (sda): bad geometry: block count 122096646 exceeds size of device (122096381 blocks)

Also seen that before. I did some searching and thought that maybe using resize2fs (resize filesystem) was a command that could help. I asked if they thought this was correct and whether there was anything else I should try. They suggested I also try:

Code:

$ sudo mount -t ext4 -o ro /dev/sda /mnt/backup

Which failed the same way as the earlier mount attempt. Then I took a deep breath and resized the filesystem as he suggested:

Code:

$ sudo resize2fs /dev/sda 465G
resize2fs 1.41.14 (22-Dec-2010)
Resizing the filesystem on /dev/sda to 121896960 (4k) blocks.
The filesystem on /dev/sda is now 121896960 blocks long.

And after that, mounting my drive was successful and I can access all my data again!

Thank you all to have offered their advice and help throughout this ordeal. Its kind of a face palm moment when you realize that all this reading and researching and asking questions and worrying was solved by running a single, simple command-line application. But its bee n a learning experience!

toffi22 · 09-14-2011, 06:59 AM

I am currently facing the exact same problem that R00ts described in his original post. Since I have moved my pc to a different case, I haven't been able to mount my data drive and fsck tells me that my file system is larger than my drive. I looked at several of the backup superblocks and they all declare the same file system size, so I assume this error isn't caused by a corrupt superblock.

As R00ts pointed out in his last post, resizing the file system might be a way to make it accessible again. However, this doesn't really cure the original problem of the 'shrunken' drive.

Do you have an idea why my machine now sees a smaller drive than it did when the file system was originally created?

netcom61 · 10-16-2011, 02:48 AM

Wow, thanks for the above explanation/instruction... saved my /home folder!

Had basically the same problem/error, and tried resizing/moving the partition with gparted, etc, etc, to no avail.

The simple command of resize2fs... took all of half a second to execute and saved what I was beginning to think was a lost filesystem...

The clear explanation of the steps you took made the fix easy...

Muchos Gracias

tsod · 11-17-2011, 01:06 PM

This post was a lifesaver.
Thank you R00ts for staying with it and for coming back to post your results.

I was able to recover a partition with the same size although mine required that I specify the partition (/dev/sdd1) rather than the whole drive (/dev/sdd).

I also noticed in the man page for resize2fs that if you do not specify a size, it will automatically size to match the partition.
I suspect this would be a safer option if you don't know exactly what size to use...

rng · 11-18-2011, 11:36 AM

In retrospect, dd or ddrescue should have been used to get image of the disk before trying potentially risky commands, to avoid irretrievable lose of data.

blindinglightning · 08-18-2012, 07:41 AM

I know this thread is virtually closed, however I would like to thank R00ts for sharing the solution.

I installed Debian 6 on a small partition (~ 20GB), creating manually the ext4 filesystem (to specify stride and stripe length---the drive is a SSD), at reboot Debian could not find the root partition. From the rescue environment, trying to mount the fs I got the error about the fs size. From a live distribution using resize2fs with no size argument (same as tsod's post) solved the problem.

bl