How to replace a hard drive...

[Peter King]

A little while ago I had a Western Digital Caviar Black drive that was throwing
bad sector errors. On the view that storage is cheap and reliability is crucial,
I replaced it with a fresh shiny new hard disk (a 1TB Seagate Barracuda), and one
way or another managed to restore all the data that was on the damaged disk.

This left me with the WD disk. So I tried reformatting it, which should lock out the
bad sectors. That seems to work: once reformatted, it passes fsck with no problem,
and it has fast access times.

Here's the first question. Can I trust this drive now?

  (I'm inclined to think the answer should be no, on the grounds that once a drive
   goes bad it should never be trusted again. But more experienced hands should
   tell me what they think.)

One thing I noticed while fooling around with the drives is that my root partition
is on what nowadays counts as a low-capacity drive (a "mere" 320GB). So I thought
I'd find out how easy or hard it would be to transfer it to a new and larger hard
drive.

So the first thing I tried was to dd everything (including the MBR) over to a new
drive, and then to resize the root partition on the new disk with GParted. No go. 
GParted wouldn't do it, claiming that things didn't end on cylinder boundaries and 
that was over. It reminded me why I strongly prefer command-line tools.

The second thing I tried was to simply partition the new drive along the lines of
the way the old drive was partitioned (namely a boot partition, swap partition, root 
partition) using all of the new disk, and, once the partitions are properly formatted,
then transfer the files on the boot/root partitions using, let's see if I have this
right,

    find . -xdev | cpio <destination> 
    
from the source. That worked. Then I tried to copy over the boot sectors of the MBR
without copying the partition table, using:

    dd if=/dev/sda of=/dev/sdb bs=446 count=1

But on boot, I just get GRUB GRUB GRUB GRUB... endlessly filling the screen. Drat.
Now I confess I cheated; I tried to boot from the new disk "in place" attached via
USB, rather than physically replacing the old boot/root disk, and perhaps that's
the problem. (Note: I don't see why, since if the drive address is wrong GRUB should
just give me a standard failure, like "no kernel detected" or the like.) The struggle
is, well, ongoing.

So here's the second question. Is there a more sensible/straightforward way to reproduce
one disk onto another of larger size?

-- 
Peter King			 	peter.king-H217xnMUJC0sA/PxXw9srA at public.gmane.org
Department of Philosophy
170 St. George Street #521
The University of Toronto		    (416)-978-4951 ofc
Toronto, ON  M5R 2M8
       CANADA

http://individual.utoronto.ca/pking/

=========================================================================
GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC  36F5 1FE6 D32A 7587 EC42)
gpg --keyserver pgp.mit.edu --recv-keys 7587EC42
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://gtalug.org/pipermail/legacy/attachments/20110504/8a05c302/attachment.sig>