From: "Jorge Luis" <lists@xxxxxxxx>
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.
{^_^}
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
