Unrecognized Hard Drive

jdow jdow at earthlink.net
Fri Jan 2 00:44:04 UTC 2009


From: "Jorge Luis" <lists at jorge.cc>
Sent: Thursday, 2009, January 01 13:06


> jdow:
>> OK, let's break the problem down into smaller pieces. Do you have a known
>> good drive you can test on that adapter? Does it work?
>
> I have four drives that I'm using with the converter, including another 
> 200
> GiB Maxtor; all of them are EIDE.  Only one of the drives exhibits this
> behavior; the others are fine.  All drives are ext3.

At this point one might suggest the drive is toast. Plugging the interface
onto the drive upside down can do that.

>> When you say you've tried with an EIDE cable how do you know the drive 
>> was
>> not found? Did you look at dmesg after booting?
>
> Here is the dmesg output when the faulty drive is unplugged from a USB 2.0
> input and then plugged into the running box again.
>
> [81041.572000] usb 4-6: USB disconnect, address 16
> [81056.170272] usb 4-6: new high speed USB device using ehci_hcd and 
> address 17
> [81056.303917] usb 4-6: configuration #1 chosen from 1 choice
> [81056.348793] scsi11 : SCSI emulation for USB Mass Storage devices
> [81056.358481] usb-storage: device found at 17
> [81056.358490] usb-storage: waiting for device to settle before scanning
>
> The output from the operation stops there; no other messages are emitted.

It sounds like the drive is not spinning up or has not spun up. Holding
it in your hand when you apply power to it can inform you somewhat about
what is happening. If it gives a solid "clunk" then sits idle the head
could not load and went back to idle. A damaged track might happen from
pulling power while writing to the drive.

>> I guess an obvious question is, "How did you abort the gpartd operation?"
>> Pulling power while a drive is writing is "not a good thing."
>
> If I wrote that an aborted gparted was a likely suspect, I misspoke.  I 
> meant
> to say that I bailed out of a GRUB configuration.  It was some time ago 
> that
> this possibly unrelated event occured.  It is true that neither gparted,
> nor parted, nor fdisk can find the drive now while scanning devices.

Yes, you did say GRUB. My antiquated chunk of gray goo I call a brain
twisted that up into gparted.

Did you exit the configuration or did you bail out by pulling power?

>> And a sense of your urgency to recover the drive might help. Is it a new
>> one you'd hate to lose but all you'd lose is the drive or did it have a
>> lot of precious data on it that you have to figure out how to recover, 
>> now.
>> (If it is the latter you are going to have to do some serious learning 
>> and
>> have the patience of Job.)
>
> We swap out three backup drives.  One drive is always off the premises. 
> An
> attempt to introduce the wonky drive back into the rotation gave me the 
> first
> intimation of trouble.  The drive contains no sensitive or irrecoverable
> information in its current state; I'd actually like to wipe it.  I'm not 
> about
> to go at it with Knoppix STD or some other forensic suite.

Ah - well, you might learn more if you can actually mount it to a
computer's IDE drive controller and see what happens. But the drive sounds
like toast. If it's "too new for that to happen" remember that new drives
have infantile failures. It's after the first few months of operation that
drives are usually quite stable until well into old age.

>> In terms of dmesg, set the drive to cable select. Plug it in to the drive
>> cable as master (the end connector.) Plug the cable in to either of the
>> IDE connectors, such as is free. Boot the machine. Interrupt the boot in
>> the BIOS. Usually the first page contains a list of drives. Play with it
>> to look for the drive. (Usually it's set to auto for all four possible
>> IDE/PATA drives.) If you plugged into the secondary IDE connector check
>> down, hold the drive in your hand, power up. You should FEEL the drive
>> spin up.)
>
> No matter how the drive is jumpered--cable-select, primary, or slave (in 
> the
> last instance, with the drive taking the secondary place on the primary 
> EIDE
> ribbon)--the introduction of the drive locks up the computer. The machine
> halts just after the memory POST; from there, there's no way to get to the
> BIOS screens.  It detects a legacy setting for USB storage and recognizes 
> my
> precious IBM Model M as a legacy device and then stops cold.  It's 
> impossible
> to tell whether the BIOS recognizes the drive.  There's no way into the 
> BIOS
> screens, which are normally available after the POST by <F2>.  The boot 
> chain
> (at <F12>) is similarly unavailable.

I'd give up at this point. The drive is toast, sadly. How it got that way
is a matter for conjecture. Hanging the BIOS POST is a little far out,
though. You have an interesting case of failure there.

>> If the BIOS finds the drive then exit the BIOS setup and proceed to the
>> next step. Boot the machine. Then investigate /var/log/dmesg. Look 
>> through
>> it for references to drives being found. (If need be save a dmesg from
>> booting without the drive and one from booting with the drive and compare
>> them. The drive should stick out in a diff like a sore thumb.) Note the
>> drive's device name, say it is sdc. THAT is what you use with partd
>> or fdisk. (fdisk -l /dev/sdc)
>
> The closest I can come to having the drive recognized by the system is 
> through
> the USB cage.  When I introduce the drive using the Coolmax converter, 
> dmesg
> records the messages that I quoted above, in which the drive is recognized 
> as
> a USB storage device.  However, no userspace program that I've tried sees 
> the
> drive, not gparted, not parted.

It sounds like the drive cannot get its head mounted and simply hangs
somehow. It's not useful for backups. If I had data on it there are some
"hacks" I might try, sharply twisting the drive on the axis of rotation
as power is applied, for example. Sometimes that will get the disk to
spin up if that's the problem. I've managed to rescue data that way a
couple times.

>> If you get that far post the results of the fdisk -l and folks here will
>> probably try to help you.
>
> fdisk is similarly uninformative:

I would expect it to be uninformative. The dmesg output indicates no drive
letters could be applied to it.

{^_^} 




More information about the fedora-list mailing list