[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

About that "copying disks" thread and dd

I read with interest the threads started by Karl about using dd to
copy disks.  I may be one of the people who "had a bad day" trying to
follow those instructions.  I tried the dd approach to copy one 80GB
disk to another 80GB disk and ran into some trouble.  I was mostly
following advice in that long thread about dd as well as web pages
about how copy disks including the MBR and the partition tables, such


Actually, I found plenty of postings on copying disks.

This appears to be almost exactly the same kind of thing as Karl was preparing:


Here is what went wrong for me.  After copying the mbr and partition
tables, fdisk reported that the partitions were the same size, I then
used dd to copy the content.  After rebooting on the new disk, I got
the dreaded


for 100s of lines.

So I rebooted off the original disk, which showed as /dev/sda and the
other one appeared as /dev/sdb, and I was able to re-write the MBR
with grub on the second disk. grub is somewhat confusing because it
uses the term root to refer both to the location of the boot partition
as well as the  root partition of the filesystem.  grub also refers to
the disks with its own terminology.  /dev/sda is called hd0 and
/dev/sdb is hd1.  In any case

# grub
> root (hdb1,0)
> setup (hdb1)
> quit

gets the job done, it lets the system know that, in order to boot from
that second disk, it should look in the first partition for the
kernel.  Then I remove /dev/sda from the computer and restart.

After that it would boot, but there was funny business on the home
partition, which was the last partition on the disk.  fdisk said it
was OK, but I found something interesting when I installed gparted,
which is a nice graphical interface to GNU parted.  It has been about
7 years since I looked at parted, and WOW, it has come along way.

gparted refused to show the partitions on the new disk, the error
message said the constraints could not be satisfied.

That was when I remembered that the two disks were not of the same
brand. Both said they were 80gb, but one was Seagate and one was
Maxtor, and they had the same number of cylinders, but not the same
number of sectors per cylinders.  Hmm.  I'm a political scientist, not
a computer scientist, but that seems to be a big source of trouble.
The partition table did not match up with the second disks's
parameters, and in fact, the last partition was OFF THE END of the
disk.  I removed that partition with fdisk, and re-created it, and
after that gparted would show the disk.  Because of the different size
of units on the 2 disks, the second one shows weird unused spaces
between the partitions.  Those are the ones with + signs after them in
fdisk.  Interestingly, fsck did not give me errors when I tested this
along the way.

Anyway, After screwing around with this and experimenting, I agree
with the advice that people are giving Karl, which is that there is
probably no fool proof step-by-step way to copy disks that will work
in all conditions.

I think it is probably better for us non-experts to rely on higher
level tools than dd when they do this.  There is less danger of human
error. I see many people recommending "partimage" for this job, but it
appears that is not in Fedora's distribution, and that makes me think
it is somehow untrustworthy or dangerous.

After copying disks 15 times, testing various methods, I think the
best approaches I've found are

1. If two disks are Identical (same brand, same number of sectors,
cylinders, and all those other things I don't understand very well),
then the best way to get an exact copy is to run "g4u", which is a
program that you install on a bootable CDR and its "copydisk" command
produces an exact byte-for-byte copy of the whole disk, including the
MBR, partition table, etc.  For all I know, it may be using dd under
the hood, but the "copydisk" command takes the human error out of the
equation.  It gets the boot sector and everything.  g4u is about the
best documented piece of free software I've found.  (The best is CVS,
by far!)

2. If two disks are not identical, be more cautious.

In the future, here is how I'm going to copy content from 1 disk to
the other of a different type/size.  Boot the system and make sure
both disks are recognized by the OS.  Use gparted to study the
partition table on the source disk, and then on the target disk, use
gparted to create partitons that are AT LEAST AS BIG as the originals.

Then copy the content from one to the other.  You can use the
equivalent of dd in gparted--it has a menu driven approach too copy
one partition to another, and you can apply that one partition at a
time.  You can use dd in a terminal if you want, of course.  Using the
gparted or dd to copy the content is slow because it copies everything
bit by bit, including the empty parts of the disks.

There are many ways to just copy the files from one system to another.
 These will be faster than dd.  Old school Unix people recommend using
tar or cpio for things like that.  For me, this has always worked:
Mount the 2 partitions, and then run "find /original -xdev | cpio
-padm /target ".   New kids seem to feel comfortable with "cp -Ra".
Some people recommend avoiding copying the system-created partitions
like /proc, and /sys when making this copy, but I don't think it is
really necessary because a re-boot wipes those out anyway and builds
new ones.

If your target disk is not as big as the source, you should not use dd
or gparted to copy the content anyway, and so you have to copy the
content with tar or such.

After you copy the partitions over, then you need to do 2 things
manually.   First, use e2label to check the labels on each partition
of the first disk and then use e2label to write the same labels on the
target disk.  If you don't do that, chances are the system will not
boot because Fedora uses labels to find partitions. Note that e2label
does not work on swap disks, and one must use mkswap with the -L
option to set a label on a swap partition.   Second, run grub to
re-write the mbr on the target disk.

This has been a humbling experience.  If anybody does come with with a
step by step fool proof way to make this work, I would be really glad
to hear it.

Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]