Hard Drive / Partitioning Problem

I_Died_Once · 08-29-2008, 05:35 PM

Hi... almost veteran of Linux here, currently using Debian Etch.

I have a hard drive that I use as a backup drive. Its got several irreplaceable files on it, mega important to me. I have it slaved to my debian box via a usb adapter. A few days ago, it was all working perfectly. All my files were there on one big partition.

Then a couple days ago, I couldn't access my stuff. WHen I try to mount the drive, I get a pop up error telling me

Code:

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

So, I check my dmesg and this is the result of that:

Code:

 dmesg | tail
sde: Current: sense key: No Sense
    Additional sense: No additional sense information
EXT2-fs error (device sde): ext2_check_descriptors: Block bitmap for group 445 not in group (block 688566700)!
EXT2-fs: group descriptors corrupted!
usb 5-8: reset high speed USB device using ehci_hcd and address 9
usb 5-8: reset high speed USB device using ehci_hcd and address 9
EXT2-fs error (device sde): ext2_check_descriptors: Block bitmap for group 445 not in group (block 688566700)!
EXT2-fs: group descriptors corrupted!
EXT2-fs: sde: couldn't mount because of unsupported optional features (1798000).
EXT2-fs: sde: couldn't mount because of unsupported optional features (1718000).

Now, I cannot stress how important it is (to me, anyway) that the files on here get backed up. I can do that on data DVD's, no prob - if I could only access the files. The plan here is to back-up my back-up, as that drive is the only existence of some of these files.

If anyone has any ideas on how to "fix" the partition table, correct the said corrupt descriptors, or whatever - I would be oh so gratious.

If any more infor is needed, please just let me know and I'll share.
Thanks!

syg00 · 08-29-2008, 06:01 PM

Presumably the partition table is o.k. - "fdisk -l" (as root) should list it.
You need to fsck it as it says - you don't need (or want) it mounted for that.

Now if you don't have a backup, you might be between a rock and a hard place. fsck "fixes" things - if you let it. By fixing it may truncate data/files - will you be able to tell ???.
That's the tough bit.
If you don't want to risk it, there are forensic tools out there, but none are guaranteed to get all of all your "important" files back.

mostlyharmless · 08-29-2008, 06:09 PM

Hmm, well, if the drive is in an enclosure with more than USB connection you could try switching connections; same on the computer end, that worked for me once. Sometimes the enclosure itself goes bad, might be able to get the drive out and reinstall it to a new enclosure, but of course that's quite a bit scarier with your data.

I can't think of a software cause for this.

I_Died_Once · 08-29-2008, 06:36 PM

I ran fsck, here are the results

Code:

# fdisk -l

Disk /dev/hda: 40.0 GB, 40020664320 bytes
255 heads, 63 sectors/track, 4865 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1   *           1        4678    37576003+  83  Linux
/dev/hda2            4679        4865     1502077+   5  Extended
/dev/hda5            4679        4865     1502046   82  Linux swap / Solaris

Disk /dev/sde: 200.0 GB, 200049647616 bytes
255 heads, 63 sectors/track, 24321 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/sde doesn't contain a valid partition table




# fsck /dev/sde
fsck 1.40-WIP (14-Nov-2006)
e2fsck 1.40-WIP (14-Nov-2006)
fsck.ext2: Filesystem revision too high while trying to open /dev/sde
The filesystem revision is apparently too high for this version of e2fsck.
(Or the filesystem superblock is corrupt)


The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

ANd when I run it like it says....

Code:

# e2fsck -b 8193 /dev/sde
e2fsck 1.40-WIP (14-Nov-2006)
e2fsck: Bad magic number in super-block while trying to open /dev/sde

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

Which is the same error.

Can anyone tell me how to find out what number the superblock is, like its asking?

Also, syg00 - can you name some of those forensic programs?

jailbait · 08-29-2008, 06:45 PM

Quote:

Originally Posted by I_Died_Once

Can anyone tell me how to find out what number the superblock is, like its asking?

The first superblock is at 0. The second superblock is at 32768.

------------------
Steve Stites

syg00 · 08-29-2008, 08:15 PM

Quote:

Originally Posted by I_Died_Once

Disk /dev/sde doesn't contain a valid partition table

That's the first issue you will have to deal with - fsck deals with partitions (e.g. /dev/sde1), not devices (i.e. /dev/sde). To attempt to rebuild the partition table, try testdisk - it scans the disk looking for "signatures" that indicate where partitions may have been. Can find false positives, and will usually also find previous partitions that have been deleted in the past. It's up to you to determine what is correct.
If you are sure you know *exactly* the extent of any partition(s) that were there you can simply recreate them from fdisk. For example the simple case of just one partition covering the entire disk.

If you are lucky that will get you access to all your data, nothing else to do - except back it up of course.
Else you might need to get into data mining - search LQ for (many) previous threads. Start maybe with photorec (same site as testdisk), then perhaps foremost. There are also specialty rescue CDs for this.
It's gunna take some time - days (plural), maybe week(s). And still no guarantees.

Clarification: The <device> referred to in that message is a block device - as understood by the block device driver. To you and me it (usually) means a partition.

jiml8 · 08-30-2008, 10:08 PM

I think I wouldn't play with this for very long before I took that drive out of the USB box and connected it directly to a computer either via PATA or SATA (as appropriate).

You have a whole bunch of things in the way on a USB interface that can interfere with the kind of diagnostics you may need to do on that drive. For instance, you could very easily be experiencing a drive failure, and the USB interface is concealing the information from you. You'll only find out when you plug the drive in directly.

Also, the USB itself could be the problem; if the drive is not self-powered, the USB bus might not be providing enough power - or might no longer be providing the power, either because it is failing or because you plugged some other new USB device in and the USB port no longer has the reserve capacity.