LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 02-14-2008, 02:49 AM   #1
WindowBreaker
Member
 
Registered: Oct 2005
Distribution: Slackware
Posts: 228

Rep: Reputation: 40
can't mount drive - corrupted superblock?


My server's HD has an unmountable partition. The other partitions are fine and mountable. The thing is that I NEED to mount this partition to pull off some data which has not been backed up. I've been at this for 2 days and am down to the wire, so any suggestions would be appreciated.

The drives looks like this (hda8 is the problem):
Code:
fdisk -l 
Disk /dev/hda: 160.0 GB, 160000000000 bytes
255 heads, 63 sectors/track, 19452 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1               1          62      497983+  82  Linux swap / Solaris
/dev/hda2              63         671     4891792+  83  Linux
/dev/hda3             672       19452   150858382+   5  Extended
/dev/hda5             672         733      497983+  83  Linux
/dev/hda6             734        1342     4891761   83  Linux
/dev/hda7            1343        2194     6843658+  83  Linux
/dev/hda8            2195       19452   138624853+  83  Linux
When the system tries to mount /dev/hda8, I get the following errors scrolling by non-stop - and which locks up the whole system.

Quote:
Ide0: reset: success
hda: task_out_intr: status=0x61 {DriveReady DeviceFault Error}
hda: task_out_intr: error=0x04 {DriveStatusErrors}
Ide0: reset: success
hda: task_out_intr: status=0x61 {DriveReady DeviceFault Error}
hda: task_out_intr: error=0x04 {DriveStatusErrors}
Again, all other partitions work perfectly without a single error, which leads me to believe this is a corrupt partition or superblock.

I have run
Code:
badblocks /dev/hda8
and let it run for over 4 hours with absolutely no output.

When I run
Code:
fsck -f /dev/hda8
I again get pages of errors and cannot even reboot the system, must pull the plug.

I found the backup superblocks by doing
Code:
mke2fs -n /dev/hda8
I then tried running
Code:
fsck -f -b 294912 /dev/hda8
And all I see is
Quote:
recovering journal
And it sits there for over 12 hours, no output or anything.

I've tried mounting it using an alternate superblock by doing
Code:
mount -t ext2 -o ro,sb=1179648 /dev/hda8 /hda8
and get the message
Quote:
Couldn't mount because of unsupported optional features (4).
* 1179648 is 294912 * 4, since mount uses 1k block sizes and mine are 4k.

I've been googling for days and only come across people who have successfully used the techniques I've already tried - mainly using backup superblocks with either fsck or mount. I'm now thinking that the problem is related to a bad feature which I may be able to change with tune2fs. So I compared the output from a "healthy" partition to that of /dev/hda8, and here's what I got:
Code:
dumpe2fs -h /dev/hda2 | grep features
Filesystem features: has_journal filetype sparse_super large_file

dumpe2fs -h /dev/hda2 | grep features
Filesystem features: has_journal filetype needs_recovery sparse_super
I am desperately needing some progress here, so if I am overlooking something please advise.

Thanks

Last edited by WindowBreaker; 02-14-2008 at 03:20 AM.
 
Old 02-14-2008, 11:55 AM   #2
kilgoretrout
Senior Member
 
Registered: Oct 2003
Posts: 2,726

Rep: Reputation: 255Reputation: 255Reputation: 255
I don't understand your superblock calculation. When I run mke2fs -n on my 4KB block ext3 partitions I get:

Code:
# mk2fs -n /dev/sdb10
bash: mk2fs: command not found
[root@localhost patrick]# mke2fs -n /dev/sdb10
mke2fs 1.40.2 (12-Jul-2007)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
2048000 inodes, 4094559 blocks
204727 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4194304000
125 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208
Did you try any of these alternative superblock backup locations besides 294912? Also, in at least one book I have, it indicates that you should add 1 to these locations, i.e. 32769, 98305, 163841, etc. So you can try both.

Also, typically when you try to mount a corrupted ext3 filesystem you just get the bad superblock error message so something else might be going on. The error message you are getting looks like it may indicate a hardware problem. One thing you can try is booting up with a livecd like knoppix or sidux and see if you can access the drive. It's usually easier to run filesystem repairs on a non-running system anyway so you can try doing your fsck from there as well. You may also try downloading the hard drive manufacturer's hard drive diagnostic utilities and run them on the drive in thorough mode. All the majors have them on their websites and they usually can be downloaded as a bootable iso that you can burn . At least that will eliminate a hardware failure although that doesn't seem likely since only hda8 is effected. The livecd will eliminate some software problem with your slack installation as well, again, not likely but certainly worth a shot.

If you have additional disk space, like on an external hard drive, you may want to make a disk image file of hda8 using the dd command:

# dd if=/dev/hda8 of=<mount point of external drive>/imagefilename

You can try mounting the imagefile with loop:

# mount <path to imagefile> <mountpoint> -o loop

Off the top of my head, those are some things you can try. Before completely giving up you can also try running:

# mke2fs -b 4096 -S /dev/hda8

This is pretty much a last resort:

Quote:
-S
Write superblock and group descriptors only. This is useful if all of the superblock and backup superblocks are corrupted, and a last-ditch recovery method is desired. It causes mke2fs to reinitialize the superblock and group descriptors, while not touching the inode table and the block and inode bitmaps. The e2fsck program should be run immediately after this option is used, and there is no guarantee that any data will be salvageable. It is critical to specify the correct filesystem blocksize when using this option, or there is no chance of recovery.
I've never used it myself, so you may want to research the command before trying it. Also, having a dd image file backup would be advisable so you can get back to square one if things get really screwed up.
 
Old 02-14-2008, 03:13 PM   #3
WindowBreaker
Member
 
Registered: Oct 2005
Distribution: Slackware
Posts: 228

Original Poster
Rep: Reputation: 40
Thanks for the response and suggestions.

Quote:
I don't understand your superblock calculation.
I used the 5th superblock at location 294912. It is the same as listed in your own output.

If you're referring to when I said
Quote:
mount -t ext2 -o ro,sb=1179648 /dev/hda8 /hda8
* 1179648 is 294912 * 4, since mount uses 1k block sizes and mine are 4k.
I meant that I want to tell 'mount' to use backup superblock 294912. But mount's man page says
Quote:
The block number here uses 1k units. Thus, if you want to use logical block 32768 on a filesystem with 4k blocks, use "sb=131072".
This is why I had to multiply my block number by 4, and use sb=1179648.

I did try using both Slax and System Rescue CD. That's actually the way I'm performing all these things, while under a Live CD.

I also don't think it's the drive as a whole, just seems like nasty corruption on hda8 (it's actually a SATA drive, but the LIVE CD maps it as hda8 instead of sda8). It's a Maxtor Caviar, so I will download the diagnostic utilities and see what they say.

Quote:
If you have additional disk space, like on an external hard drive, you may want to make a disk image file of hda8 using the dd command:
Thanks for the suggestion. I just got back from buying another HD to dd onto. I'd feel more comfortable messing with the image instead of the original.

Quote:
mke2fs -b 4096 -S /dev/hda8
Thanks for that suggestion. I also read that on http://linuxgazette.net/issue32/tag_superblock.html and is what I will be trying when I'm done dd'ing the image (fingers crossed).

If you think of anything else I might try, do let me know. I have tried using all the backup superblocks and have had to luck. But the wierd thing is that badblocks is showing 0 bad blocks. How is that possible?
 
Old 02-15-2008, 02:27 AM   #4
evilDagmar
Member
 
Registered: Mar 2005
Location: Right behind you.
Distribution: NBG, then randomed.
Posts: 480

Rep: Reputation: 31
Quote:
Ide0: reset: success
hda: task_out_intr: status=0x61 {DriveReady DeviceFault Error}
hda: task_out_intr: error=0x04 {DriveStatusErrors}
Ide0: reset: success
hda: task_out_intr: status=0x61 {DriveReady DeviceFault Error}
hda: task_out_intr: error=0x04 {DriveStatusErrors}
These sorts of messages generally indicate something more than simple data corruption is going on. I strongly suggest you make a backup image of the partition using dd as soon as possible--although I suspect you're going to be using dd_rescue before this is over with.
 
Old 02-15-2008, 10:48 AM   #5
kilgoretrout
Senior Member
 
Registered: Oct 2003
Posts: 2,726

Rep: Reputation: 255Reputation: 255Reputation: 255
Quote:
(it's actually a SATA drive, but the LIVE CD maps it as hda8 instead of sda8
That is very strange. Only the very early 2.6 kernels named sata drives with hdx instead of sdx. Try a more recent livecd like sidux. Also, what type of sata controller are you using?

Quote:
These sorts of messages generally indicate something more than simple data corruption is going on. I strongly suggest you make a backup image of the partition using dd as soon as possible--although I suspect you're going to be using dd_rescue before this is over with.
I totally agree. These types of error messages look like a hardware issue, either with the drive or the sata controller. If you have another box you can throw the drive in, you may want to give that a try.
 
Old 02-16-2008, 03:22 PM   #6
WindowBreaker
Member
 
Registered: Oct 2005
Distribution: Slackware
Posts: 228

Original Poster
Rep: Reputation: 40
[Solved] can't mount drive - corrupted superblock?

First off, thanx for all the suggestions. I have been working on the HD on another system the whole time, not on the server it crashed in. I used the newest systemrescuecd and slax Live CD's there is. But because they both saw the drive as /dev/hda instead of /dev/sdb, I didn't feel comfortable wasting hours imaging a drive unless everything was kosher. So I booted up Slackware 12.0, which is what I've got installed on the first SATA drive on that box, and then I could view the drive as /dev/sdb.

Here's how I solved this prob.

First, as suggested, I used dd to image the partition onto a new external drive.
Code:
dd if=/dev/sdb8 of=/external_drive/sdb8.img bs=4096 conv=notrunc,noerror
Then I ran e2fsck against the partition image as follows
Code:
e2fsck -y ./sdb8.img
This found so many double-claimed sectors that they scrolled by very fast. I just let it do it's thing, and when it was done I was finally able to mount the partition image for the first time. From there, I pulled the 10GB of data I was really after.

I unhooked the drive, labeled it, and put it in a drawer, in case a few weeks/months down the road the client tells me some files are still missing/corrupted.

I'm convinced this is a bad drive, probably the pcb on the drive. I'm not gonna waste my time trying to use it, as it's more valuable to me as an archive in case anything is missing.

NOTE
If this didn't work, here's what I was going to try:
Code:
dd if=/dev/sdb8 of=/dev/sdb8
I read somewhere that this "rejuventates" the drive by rewriting everything. I know how risky this is on a potentially bad controller, but I would have ran out of options by this point.

The other think I considered was swapping the printed circuit board on the drive with an brand new, identical drive. Assuming the controller was the problem, this may have made the drive reabable at least.

Again, both risky practices - and I'm glad I didn't have to do them.
 
Old 02-17-2008, 02:46 AM   #7
evilDagmar
Member
 
Registered: Mar 2005
Location: Right behind you.
Distribution: NBG, then randomed.
Posts: 480

Rep: Reputation: 31
Quote:
Originally Posted by WindowBreaker View Post
If this didn't work, here's what I was going to try:
Code:
dd if=/dev/sdb8 of=/dev/sdb8
I read somewhere that this "rejuventates" the drive by rewriting everything. I know how risky this is on a potentially bad controller, but I would have ran out of options by this point.
Well, people post a lot of things on the web. This is one of the many that bears no relation to reality. Don't bother doing it.

Quote:
Originally Posted by WindowBreaker View Post
The other think I considered was swapping the printed circuit board on the drive with an brand new, identical drive. Assuming the controller was the problem, this may have made the drive reabable at least.
Right idea, wrong approach. This can be done with a replacement PCB from the same model, but you don't want a "new" drive. You want one that's as close to the original production run in it's manufacture as you can get. Drive manufacturers often change the design of a given model of drive several times during it's lifetime, so there's a number of ways this can go horribly wrong on you. Dig around with Google and you can find where just how close you have to get is documented with respect to several manufacturers.
 
Old 02-17-2008, 05:43 AM   #8
H_TeXMeX_H
LQ Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292
What I suggest, try and use foremost or similar program to recover your data, then see what you can do with the partition.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Restoring missing/corrupted Superblock? fell Slackware 3 07-13-2005 04:39 PM
bad superblock when trying to mount a USB hard drive shubb Linux - Hardware 4 04-29-2005 01:00 AM
Can't access partition: superblock corrupted lixy Linux - General 3 03-15-2005 04:12 AM
Corrupted superblock lnb Linux - Newbie 3 05-06-2004 06:29 AM
Corrupted superblock/filesystem? (Ext3) elrohir_telperi Linux - General 2 05-04-2004 06:29 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 01:22 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration