[Cialug] usb to ide

[Dan Hockey]

Thanks for the input, I now have a few more options to try. I'm hoping the
drive is still good after the motherboard dieing. I'll have to order one for
my own use.
-dh

-----Original Message-----
From: cialug-bounces at cialug.org [mailto:cialug-bounces at cialug.org] On Behalf
Of kristau
Sent: Sunday, July 15, 2007 2:25 PM
To: Central Iowa Linux Users Group
Subject: Re: [Cialug] usb to ide

On 7/15/07, Dan Hockey <icepuck2k at mchsi.com> wrote:
> I was volunteered to help a friend figure out what happened to his 386/33
> win3.1 no less. The cmos seems to have died, it doesn't beep or display
> anything.

Lucky you!

> Is there any particular brand of adapter that I should look for? Do they
all
> work the same?

I've got a different brand of adapter than the one you linked in your
first message, but mine looks exactly like that one (except it is
blue).  They are probably made in the same place overseas then
re-branded over here.

I originally bought one for work and liked it so well I bought one for
home, too.  It has saved me a lot of work.  I like that it has laptop,
3.5" and SATA connections.  I recommend taking an image of the hard
drive with dd before you do anything else.  I use the dd clone method
to save dying systems at work all the time.  Here's an anecdote of one
such case:

I schedule my day pretty tightly, so I'm in the habit of telling
people to send me an e-mail if they try to interrupt me with something
non-critical.  One such time, a co-worker approached me saying his
computer seemed to have slowed down quite a bit.  Thinking it was
still usable, but probably needed a defragment performed or a run away
process terminated, I asked him to e-mail me and I'd put him on my
schedule.  He responded simply, "I can't."

Ahh, this sounds like a hardware problem!  So I dropped what I was
working on (well, sort of) and headed over to his desk.  He was logged
in, but the desktop had no icons on it and clicking the Start menu
resulted in no response from the system.  I also noted that his hard
drive light was solid.  I tried rebooting the system once and it
behaved the same way -- talking a long time to boot up as well.
Assessment: the hard drive was failing.

I ran back to my desk and grabbed the following items:
- USB hard drive adapter.
- Empty 160 GB IDE hard drive.
- Knoppix 5.x CD.

Here's the procedure I followed:
1) Boot system to the Knoppix CD, usually with 'knoppix 2' at the
boot: prompt to get in to console-only mode.
2) Verify the device ID of the system hard drive (such as /dev/hda)
and its size (must be equal or less than the empty drive).  The output
from dmesg is handy for this.
3) Connect the empty drive with the USB drive adapter and verify its
device ID (such as /dev/sda) and size (must be equal or larger than
the system drive).
4) Issue a command similar to the following, MAKING SURE THE SOURCE
(if=) AND DESTINATION (of=) DRIVES ARE CORRECT!

  dd if=/dev/hda of=/dev/sda bs=4096 conv=noerror,sync

5) Wait and watch.  The copy takes awhile depending on several factors
including the size of the drive and speed of the USB bus.  I've seen
transfer rates between 1 MB/s to over 20 MB/s.

Once the clone was complete (it took about an hour in this case for an
80 GB system drive), I placed the cloned drive in his system and
booted to it.  Everything worked, and the slowness issues had
disappeared.  I did note a few bad sector errors during the clone, so
I warned him that there may be a couple of corrupt files on the cloned
drive now.  It has been over a week and I've not had any complaints
from him yet, though.

Total time to clone this system: approximately 1 1/2 hours.  If I had
to rebuild this system from scratch (install and configure OS,
software, restore files from old HD, etc.) it would take me between 4
and 6 hours.  Yes, the clone may have failed, but I'm willing to
gamble that outcome for the potential of saving 4 to 5 hours of work
AND down time for the end-user.  Plus, even if the clone fails, you
may be able to recover data from the clone copy easier than from the
failing drive.

A couple of notes on the dd parameters used above:
- if= is your SOURCE, of= is your DESTINATION.  Woe to those who
inadvertently swap them!
- bs= is your block size in bytes.  512 is the default and almost
always results in a 1 MB/s or slower transfer rate.  I've found most
of the drives I've imaged get the best transfer at 4096, but some may
be faster with a different size.  If the drive is large, and you have
the luxury to run some tests (death is not imminent), it is worth
trying several different block sizes to find the optimum setting.
- conv=noerror,sync tells dd to not stop if it gets errors (the
default is to stop which is bad if you know the drive is dying) and to
sync the writes.  Syncing the writes slows things down, sort of, but
assures that every block gets immediately transferred to the new drive
instead of cached and written later.

Also note that your target can be a file instead of a drive, or you
can even stream the clone copy over the network by piping it through
netcat (much slower, but a viable option in some cases).  Those are
topics for a different discussion.

Apologies for rambling on about this, but I've been using it quite a
lot recently.  We've many old Windows systems at work that are
starting to suffer hard drive and other types of hardware failures.
I'm even using it to take images of old, working systems just before I
retire them.  That way, if a user complains they are missing something
on their new system, I can use the image to restore it for them.

-- 
Tired programmer
Coding late into the night
The core dump follows

My GNUPG public key is available at http://www.kristau.net/public_key.asc
_______________________________________________
Cialug mailing list
Cialug at cialug.org
http://cialug.org/mailman/listinfo/cialug