How to replace a hard drive...

[Lennart Sorensen]

On Wed, May 04, 2011 at 06:25:05PM -0400, Peter King wrote:
> 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.

fsck means nothing.  Use mkfs with badblock check.  Unless you low level
formatted it, nothing is done about bad sectors.  Of course modern drives
don't need that since they can automatically map bad sectors _on_write_
(not on read).  Writing to the whole disk should help the drive remap
all bad sectors.

> 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.)

Well I wouldn't personally trust it.

> 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> 
 
rsync -aHx would be my choice.  I have never found cpio a useful tool
(the syntax is horrible).

> 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

No, reinstall grub.  The file is no longer in the same place on the new
drive so the boot sector is meaningless.

> 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.

GRUB GRUB GRUB means stage1 can't load other parts of grub, which makes
sense since it isn't where it used to be.

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

Just do a new grub-install and you will be fine.

-- 
Len Sorensen
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists