Re: [vox-tech] HD xfer
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [vox-tech] HD xfer
When school starts, I probably won't be able to comment like this, or
respond to all the items I would like to offer responses... :-/
On Sat, 11 Aug 2001, Foo Lim wrote:
> My HD is on the fritz. It's clicking quite loudly, and even though the
> Western Digital diagnostics program says there's nothing wrong, I am going
> to transfer everything over to another drive. I'll be following the
> guide mini-HOWTO for hard drive upgrading:
> But I have a few questions, specifically in regards to the contents in the
> actual copying part:
> 1. I'll probably be booting from a Redhat 6.2 CD and copying one partition
> at a time, so I guess I can use the first option?
> # [cdrom's root] cp -ax /mnt/old-disk-part1 /mnt/new-disk-part1
> 2. Would the -x option also copy the stuff in /proc?
No need to copy this. Just go to the root ("/") of the new hd (where you
have it mounted) and mkdir proc. Without a directory for "/proc" on the
new system, the kernel will have no place to mount the pseudo-fileystem
and this will probably cause bad things to hapen - possibly including not
being able to boot all your services.
> 3. What was the bug in the tar method? Also, what was the tar method?
Not sure what the "bug" was. I have used the tar method on a number of
transfers, and it has worked AFAIK for them.
(Have not really used cp -ar in the past for this, I just used the tar
Since the how-to is more mainstream and has aparrently survived criticism
from people more skilled than me, you may want to go with their suggested
For tar. probably something like:
Your new drive has its root filesystesm ("/") mounted on /newhd on the old
system then mountpoints for other partitions within the /newhd like
/newhd/home /newhd/var /newhd/tmp /newhd/usr /newhd/usr/local though you
may not have as many partitions/mountpoints on your new HD.
(New mount points and partitions do not need to be the same size as old
ones, just big enough to take the size of data stored in the old
locations. If yuo need to know how much space is used by a given tree, try
du -s as in
# du -s /usr/local
This method requires that you have all of the partitions for the new HD
mounted at once in their same relative locations within /newhd 's
directory tree !
Once all of the new mountpoints are set-up, cd to the root level of the
new hard disk:
# cd /newhd
now a sample tar for moving the stuff: (assuming gnu tar, and options may
be different for different versions so please check
(one long line)
# tar --same-permissions --numeric-owner --atime-preserve --same-owner
--exclude newhd --to-stdout -cvf - / | tar xvf -
What this sample would do is be to tar up everything on the system
starting at "/" except for the things it finds in /newhd and then instead
of creating a tar archive, is streams the data to another tar (your
shell's pwd is /newhd ) and extracts the stream on the fly. What this
would also do is avoid the 2Gb limit for pre 2.4 kernels, and not require
the extra space of an intermediate tar file.
Since GNU tar by default strips the leading "/" from created archives by
default, the extraction will take place relative to the PWD of the shell
doing the tar extraction. (in this case /newhd ) kewl, no?
This may end up copying /proc, but you could always cd to /newhd/proc and
rm -rf * or you could examine the --from-file FILE option in tar and
create a file listing the places you do not want the tar archiver to
travel to include not only newhd but also proc/
- end aside
What was the bug they write about? Not sure. Could be a system that used
an intermediate file and when archiving over 2Gb on 2.2 series kernels
extra data might get tossed. "split" could have circumvented this, but you
still have the issue of neededing some free space to store the files and
it would take longer.
Perhaps the bug is differences between tar on different systems and GNU
having changed some of the options on tar. ?
Perhaps it was a problem with the tar command not being told to skip the
place the new archive is being extracted - and ending up in a kind of loop
where files being extracted get archived for extraction again.
> 4. Any other caveats I should know about before I begin?
Yeah. If your HD is clicking and/or grinding, it may be the spindle or
bearings that are failing. When this happens, a drive disk in motion tends
to stay in motion, but a drive disk at rest tends to stay at rest.
What I mean by this is this: If there is drag on the drive, it may be
insufficient drag to stop the drive's disks that are spinning, *but* may
be enough to prevent the stopped drive disks from spinning up. (This issue
is illustrated in physics when you exacine the differences between the
coefficients of static friction vs the coefficients for kinetic friction;
it often takes more energy/work to break the initial friction than it does
to keep something going against the friction imposed while in motion.)
What to think about:
If you shut down your machine to insert the new drive, you may find the
old drive won't spin back up. You can try to "shutdown" your system
without a power-down, and then insert the new HD into a machine that is
powered-up, but this has a few risks:
1) power surge to new drive may damage it
2) power drain from system with device "hot swapped" may cause "other
problems" not limited to perm. hardware damage.
3) the new HD not being detected - even though Linux will likely detect
4) more (that I am not thinking about)
If the risks above are more favaroable than the risk your HD will not spin
up, then you may want to go that route.
Last, as an emergency procedure, and last effort - just in case:
I had experience with a drive that refused to spin up after the drive was
shut down for the above reason. The machine was old, and we did not care
what happened to it - it was going to be tossed. I did care about the
data on the disk and wanted to migrate it to a new system.
(EE people may want to overt their eyes from this section. ;-)
After te new HD was connected and set up as the slave, the disconnected
the power to the primary master drive and powered up the machine. Then
during the initial POST, I would insert and remove the power to the b0rked
disk. By pulsing the power on and off by connecting and disconnecting the
power connector to the old HD, it provided enough instant power to the
motor to create a low frequency vibration (equal to the power cycling
speed of connecting and disconnecting the power to the b0rked drive.) (By
the way, if ds/dt is speed, and ds/(dt)^2 is accelleration, then what is
ds/(df)^3 ? - a jerk - exactly what I was using.) I could tell it was
starting to work, because I could hear the drive almost spin up a few
times. After several attempts, using trial and error to find the best
frequency to cycle the drive power, the drive spun up! (I did need to
restart the system between each try because I only had about an 8 second
window for POST before Iw ould get an error message about not being able
to find the primary master HD and "no boot device" from the BIOS.
That part remonds me of a fortune quote I found in the past:
'A novice was trying to fix a broken lisp machine by turning the power off
and on. Knight, seeing what the student was doing spoke sternly,
"You cannot fix a machine by just power-cycling it with no understanding
of what is going wrong." Knight turned the machine off and on. The
-----BEGIN GEEK CODE BLOCK-----
GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-----) C++$(++++) U++++$(+$) P+$>+++
L+++$(++) E W+++$(+) N+ o K w+$>++>+++ O-@ M+$ V-$>- !PS !PE Y+ !PGP
t@-(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+>++>++++ h(++)>+ r*>? z?
------END GEEK CODE BLOCK------
decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html
Systems Department Operating Systems Analyst for the SSU Library