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 as: http://www.inference.phy.cam.ac.uk/saw27/notes/backup-hard-disk-partitions.html Actually, I found plenty of postings on copying disks. This appears to be almost exactly the same kind of thing as Karl was preparing: http://www.sentinelsecurity.net/whitepapers/diskcloning.pdf 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 GRUB GRUB GRUB GRUB 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. PJ -- Paul E. Johnson Professor, Political Science 1541 Lilac Lane, Room 504 University of Kansas
