Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I can no longer mount an extra internal hard drive on my Ubuntu 11.04 64-bit system. I could up until a few days ago.

I had added a line at the end of fstab for the drive to automount, but I don't think it worked. I then removed the line from fstab and the drive will no longer mount via GUI or CLI. At least I think the problem is related to this, it may not be at all.

Trying to mount:

$ sudo mount /dev/sda /media/openSpaceI

GUI:

enter image description here

That gives this error:

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

GUI:

enter image description here

Here is the print out from dmesg | tail:

$ dmesg | tail
[ 9344.234380] compiz[6098]: segfault at 28 ip 00007f1fa0641335 sp 00007fff0b306700 error 4 in libregex.so[7f1fa063c000+8000]
[ 9987.879043] nautilus[6899]: segfault at 1505b817b60f ip 00007ff6eeefdb8d sp 00007fff09aa6170 error 4 in libgobject-2.0.so.0.2800.6[7ff6eeeca000+4e000]
[10001.231835] compiz[7360]: segfault at 28 ip 00007f38e0cfe335 sp 00007fff3228d380 error 4 in libregex.so[7f38e0cf9000+8000]
[10113.817592] compiz[7429]: segfault at 28 ip 00007f01c11cd335 sp 00007fffac4f4250 error 4 in libregex.so[7f01c11c8000+8000]
[10116.592022] compiz[7651]: segfault at 28 ip 00007f4369548335 sp 00007fffb3b2b030 error 4 in libregex.so[7f4369543000+8000]
[10117.958485] compiz[7666]: segfault at 28 ip 00007f3861d7d335 sp 00007fff268395d0 error 4 in libregex.so[7f3861d78000+8000]
[10366.207793] EXT4-fs (sda): bad geometry: block count 156282966 exceeds size of device (156282701 blocks)
[10855.975855] EXT4-fs (sdb): mounted filesystem with ordered data mode. Opts: (null)
[10863.666747] EXT4-fs (sda): bad geometry: block count 156282966 exceeds size of device (156282701 blocks)
[11125.922998] EXT4-fs (sda): bad geometry: block count 156282966 exceeds size of device (156282701 blocks)

My fstab file now:

enter image description here

I also ran disk utility on the disk. Disk is good and healthy. Here are the screenshots from that:

enter image description here

enter image description here

Any help getting this disk mounted would be extremely appreciated.

share|improve this question

5 Answers 5

up vote 5 down vote accepted

I encountered this problem recently, and was able to solve it. Since there doesn’t seem to be a clear answer here, I thought I would attempt to fix that.

First off, it is important to understand that you can have put a filesystem directly on a block device. In that case, you would mount/fsck/etc the device, like:

/dev/sda

NOT /dev/sda1

To be clear, this means you can have a filesystem without a partition table. This is called a partionless filesystem, and has been around for a long time. Here is a thread on stackexchange debating the merits: http://unix.stackexchange.com/questions/14010/the-merits-of-a-partitionless-filesystem

Next, this seems to be a somewhat common problem, mostly because Ubuntu decided to include the option of installing directly to a device.

The problem arises because in some cases a partitionless install breaks the formula EXT4 uses to compute disk size. You can tell if you have this problem if the difference between the expected and actual size is 265 bytes. (and no that’s not supposed to be 256) Google just told me that 265 is the size of an EXT4 inode structure. Since putting filesystems on bare devices is supported, and in some cases even encouraged, I would assume this is a bug. I was using kernel version 2.6.39 when it happened to me.

Finally, the solution. It’s quite easy really.

First, you need to force an fsck of the filesystem:

fsck.ext4 -f /dev/(your device)

Again, for a partionless device you would use for instance /dev/sda, not /dev/sda1 or anything like that.

Next you need to resize the device to match what ext4 wants:

resize2fs /dev/(your device) ####

Where <####> is the value from the error message:

EXT4-fs (sda): bad geometry: block count exceeds size of device (#### blocks)

PLEASE NOTE: the usual disclaimers apply. Messing with filesystems is dangerous etc. Be careful! This is meant is a last-ditch attempt to fix a filesystem, when the only other alternative is to reformat. I am not a filesystem expert, and have no idea if the above fix will work on your system, or introduce problems later on down the road. YMMV.

Once you’ve rescued your data, the safest approach is probably to reformat and create a standard partition table, if you can.

share|improve this answer
    
! I finally got around to fixing my drive. After numerous posts on numerous forums, this did it. Thank you Eric, a lot. –  winchendonsprings Nov 26 '11 at 4:27
1  
Also this may be some help. The #### you use in the resize2fs command is the smaller of the two numbers. For example, my superblock size was 156282966 and the physical size of the drive was 156282701. So my command was # resize2fs /dev/sdb 156282701 –  winchendonsprings Nov 26 '11 at 4:30

First you will need to open Terminal and edit the file /etc/fstab using the following command:

sudo gedit /etc/fstab

Then add this line to the end of the file for ext3 filesystems:

/dev/sdb1 /media/yourdrive ext3

Add this line for fat32 filesystems:

 /dev/sdb1 /media/yourdrive vfat

Now reboot your computer for the changes to take effect.

http://www.ubuntulinuxguide.com

share|improve this answer

It is perfectly legal to have a filesystem such as ext4 without any partition. I got the same problem as you.

If you run e2fsck on your drive, it will say that it probably has a bad superblock and will propose to abort. Press n for it to continue, and it will check the filesystem. If your problem is the same as mine, you'll see that the filesystem is there and perfectly clean.

You can also run tune2fs -l on /dev/sda and you'll have lots of details showing that the filesystem is there and healthy, appart from that blocksize discrepancy.

I don't have any answer for now. It is probable that you could mount the filsystem on Ubuntu 10.10. I haven't tried yet, but you could attempt to recover data using the 10.10 Live CD for example.

Another way, which I didn't try yet, would be to use resize2fs to resize the filesystem so that its blocksize is the same as the device.

share|improve this answer
    
Mounting the filesystem on a 10.10 install did not work for me (same error). I finally used resize2fs /dev/sda <size of device in blocks> and it worked for me. I don't see any damage yet. –  neutro May 13 '11 at 3:10
    
!!! wow, I thought I was out of luck. Something new to try, awesome. I will absolutely try this in a few days(out of town) and report back. Thanks –  winchendonsprings May 14 '11 at 18:29

boehj has pretty much covered it - you don't mount a disk (eg: /dev/sda), you mount a partition on a disk (eg: /dev/sda1) and the fdisk screen print for /dev/sda shows no partitions so there's nothing to mount.

Your output from dmesg says that the disk geometry looks bad so the partition table on the disk may have become corrupted - it's hard to say much more on the evidence provided, but it may be worth running this partition test/recovery utility: http://www.cgsecurity.org/wiki/TestDisk - you can download a liveCD version or run it under your current OS.

share|improve this answer
    
A funny thing I noticed is that the mount point (/media/openSpaceI) still remains. usually after an unmount the directory disapears. Is this possible-- I removed a line in fstab while the drive was mounted and it screwed something up? The line was for automounting that drive (/dev/sda) at boot. –  winchendonsprings May 4 '11 at 23:39

The mount command you listed isn't complete, i.e.:

$ sudo mount /dev/sda /media/openSpaceI

It should be something like (presumably):

$ sudo mount /dev/sda1 /media/openSpaceI

Seeing as the disk isn't mounted now, why not do:

$ sudo e2fsck /dev/sdaX

to see if any errors are found and can be corrected (where X is the partition number on /dev/sda).

share|improve this answer
    
The drive contains no partitions and is formated to ext4 see - fdisk - dl.dropbox.com/u/545099/fdisk.png and e2fsck - dl.dropbox.com/u/545099/e2fsck.png –  winchendonsprings May 4 '11 at 7:07
    
Well, if it's formatted as ext4 that means it has at least one partition. But in that 1st .png you've posted you can't see anything under the labels 'Device Boot', 'Start', etc., whereas you can see entries under these for /dev/sdc1. Which means there's no partition as far as I can tell on /dev/sda. Or there was one but it's now been damaged. –  boehj May 4 '11 at 7:34
    
But I can mount /dev/sdb at /media/openSpaceII, but I cannot mount /dev/sdb1 at openSpaceII. See in the fdisk.png where that drive is listed as well? As for /dev/sda being damaged, you can see in the e2fsck.png that the filesystem size blocks differ by 265 from the physical size blocks if you do the math. I'm bummed, I really don't want to have to wipe the data off this disk. –  winchendonsprings May 4 '11 at 16:15

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.