Cloning an old drive to a new drive

[oldcpu]

This is a basic guide/example for cloning an old small hard EIDE (PATA) internal drive to a new larger EIDE (PATA) internal hard drive, using the linux "dd" command where both hard drives are 255 heads, 63 sectors/track.

Edit: The reviewed how-to has been copied to here:
Cloning an old drive to a new drive - openSUSE Forums
any/all future edits will be made on the Linked how-to, and not on this post. This thread is being maintained for comments, suggestions, and discussion of corrections for the "reviewed" how-to.

OVERVIEW:

In the example that I did in January 2009, the old drive was 40GB and the new drive was 160GB. This was done on an old Dell Dimension 2100 PC (1.1 GHz CPU with 512MB of RAM and the latest A4 BIOS) that was purchased in 2001. After a successful cloning, the new drive will have only 40 GB of formatted bits and bytes, but it can be easily expanded to use the fully 160 GB with the appropriate utility.

In the case where I did this operation, I used an
(a) openSUSE-11.1 live CD
(b) parted Magic Live CD
(c) external 60 GB USB hard drive (for data backup).

RESEARCH:

Before purchasing the external hard drive, try to ensure that it is compatible with your PC (via research on the Internet). This is especially true if one intends to use the hard drive on an older PC. This guide assumes both old and new drives are 255 heads, 63 sectors/track, so attempt to confirm that prior to purchasing the new drive.

Also before starting, check the web site of your motherboard manufacturer to see if there is a BIOS update. Sometimes there are BIOS fixes associated with new drives (and newer drive technology).

If possible, it is useful to ensure the new hard hard drive can be returned to the computer store, if the cloning does not work. However finding a computer store that will allow that return policy is not so easy nor common.

BACKUP FIRST

Before cloning, it is best to backup all data. External USB drives are inexpensive, and they make great platforms for external backed up data.

CONNECT BOTH OLD AND NEW DRIVE

After backing up the data, switch OFF the PC, and leave the old (smaller) hard drive connected. Connect the new hard drive to the same cable as the old hard drive, but have the jumpers on the new hard drive set as "slave". Now switch ON the PC and boot to the BIOS, and confirm that that BIOS recognizes both the old hard drive, and the new hard drive.

In the example I did (with the old Dell Dimension 2100) the BIOS recognized both old and new drives, although the Dell recognized the new 160GB drive (a Seagate Barracuda) as a 137,447 MB drive. The fact the drive is recognized was positive, although it worried me that the 160 GB drive was recognized as a 137 GB, as opposed to 160 GB. I read on our forum that this was due to a 142 GB BIOS limit. Purportedly (from what I was told) that only means that any GRUB files should be in partitions under this limit. Linux has no problems reading the whole disk, since it doesn't rely on the BIOS to access the disk.

Put the openSUSE Live CD in the CD drive, and with the BIOS set to boot to CD ROM first, continue booting to the openSUSE live CD. Once boot is complete, open a gnome terminal (for Gnome live CD) or KDE konsole (for KDE live CD) and type "su" (no quotes, enter root password when prompted) followed by

fdisk -l

to check openSUSE can see both old hard drive and new hard drive. Once may see something like this for the old hard drive:

# fdisk -l
Disk /dev/hda: 40.0 GB, 40000000000 bytes
255 heads, 63 sectors/track, 4863 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/hda1 * 1 959 7703136 b W95 FAT32
/dev/hda2 960 2043 8707230 7 HPFS/NTFS
/dev/hda3 2943 4863 15430432+ f W95 Ext'd (LBA)
/dev/hda4 2044 2942 7221217+ 83 Linux
/dev/hda5 2943 4033 8763426 b W95 FAT32
/dev/hda6 4034 4103 562243+ 82 Linux swap / Solaris
/dev/hda7 4104 4863 6104668+ 83 Linux

and something like this for the new hard drive:

Disk /dev/hdb: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/hdb doesn't contain a valid partition table

So clearly here in the above example, hda was the old drive and hdb is the new drive. In this example, hda1 was a winME partition, hda2 is a winXP partition, hda5 is a fat32 data partition, and hda4, 6, 7 were all old openSUSE-10.2 Linux partitions (for /, swap, /home respectively). Note that hdb "doesn't contain a valid partition table" because it is brand new, and never was partitioned before. Note also that both drives were 255 heads and 63 sectors/track. That is important, and provides confidence that the cloning will work.

CLONE

Then, in the same terminal / konsole (with root permissions) type:

dd if=/dev/hda of=/dev/hdb bs=32256

BE VERY CAREFUL when typing that. If you get that wrong, you could erase your existing hard drive !! THAT LINE IS KEY TO THE CLONING. Note in this example, hda is the original hard drive, and hdb is the new hard drive. Dependant on how the live CD recognizes your drives, this may instead be different. For example if the old drive was sda and the new sdb, this could instead be:

dd if=/dev/sda of=/dev/sdb bs=32256

I have read that bs=32256 represents one complete track of 63 sectors, each with 512 bytes (I also read that omitting bs=32256 purportedly still works, but that would significantly slow down dd cloning).

In the case of cloning a 40 GB drive, that could take about 2 hours for an old PC (time dependant on the PC age). There will be no messages during the cloning.

PREPARE FOR FIRST BOOT

Once the cloning is complete, switch OFF the PC, remove the old drive (40 GB drive in this example) and move the new drive (160GB in this example) to the same place on the cable as the old drive, and ensure that you change the jumpers on the new drive to make it the primary drive. This is important. Do NOT power on with new drive still setup as a slave.

FIRST BOOT

Then switch ON the PC. It should boot properly to Grub, which was cloned as part of the cloning process. In my example case, I selected to boot to openSUSE-10.2, and the PC booted properly to 10.2 (hda4). I then rebooted to winME (hda1) properly as a test. I then rebooted to winXP (hda2) as a test. WinXP gave an error the first time, and refused to boot properly. I'm told this is typical winXP behaviour when it notes a new drive ID in the place of the old drive. I then rebooted winXP (hda2) and on the second boot winXP booted properly and functioned properly.

RECLAIM FULL SPACE OF NEW DRIVE

I then inserted the Parted Magic live CD (this would work just as well with the gparted live CD) and repartitioned the new hard drive. There are many ways to go from this point, but the purpose here by booting to Parted Magic is to expand the 160 GB drive (which is currently only using 40 GB) to use its full capacity.

At this point, one is complete. (In my case, I "shelved" the old 40GB drive, and did not use it any more).

EXAMPLE OF ADDITIONAL THINGS

Also in my case I decided to go a step further to completely remove openSUSE-10.2 and replace it with openSUSE-11.1, so I removed all partitions except for the hda1 (winME) and hda2 (winXP). By doing that the drive would no longer boot, as the MBR had the old openSUSE-10.2 grub pointing to /hda4 (where the boot files on /hda4 had been removed by me). With parted Magic I expanded the /hda2 NTFS partition to be larger (for winXP), I created a new /hda3 (fat32 data partition) and created a new /hda4 extended partition where upon I created an hda5 swap partition, a hda6 / (root) partition area and a hda7 /home partition area for an openSUSE-11.1 install. I then rebooted from the Parted Magic live CD to the openSUSE-11.1 live CD, and during the openSUSE-11.1 live CD install I was careful to ensure openSUSE-11.1 installed on the /hda5 (swap), /hda6 (root) and /hda7 /home, and careful to ensure openSUSE-11.1 placed grub on the MBR (it was not going to do this by default, and I had to edit the install configuration).

The openSUSE-11.1 was successful, and after a successful openSUSE-11.1 install, the new grub then gave me the choice upon booting to go to winME, winXP, openSUSE-11.1 or openSUSE-11.1 safe.

Overall, the operation ran quite smooth.

For the example I gave above, the following is the thread where I sought help from our forum experts for conducing the cloning operation: Looking for new hard drive advice - openSUSE Forums

[smpoole7]

Good stuff.

[ken_yap]

Well done oldcpu. I see the OpenSUSE world is benefiting from your filial IT support.

[brunomcl]

I understand that for drives of different geometry it is possible to clone by partition, for example,dd if=/dev/hda1 of=/dev/hdb3. This will copy partition hda1 to partition hdb3.

Pros: After copy you can resize the new partition before copying the next one, if any. This may be very desirable, as after a full drive dump (copy) you're only be able to resize the last partition.

Cons: The boot sector(s) is(are) not copied, it has to be done manually. dd can be used for this, or another partitioner. Also grub or lilo may have to be edited if partitions are copied out of order, as in the example above.

[NigmaToolin]

Personally, I am dead against this howto for adhoc upgrades of hard drives, because of the advice given by robopensuse in this thread.

Generally, dd operates on a byte level and in 'cloning' a partition, what is desired is to copy the files, not the specific byte patterns. If you use dd for this job, you will carry over all of the rubbish from the previous filesystem, including orphaned data and the complete fragmentation state of the old drive. Only if you specifically want the byte pattern [eg to copy a boot sector] is it appropriate to use dd. Or again, if you have loaded a new drive and want to copy it multiple times to identical drives. Otherwise, you really are breaching the principle of 'abstraction' inherent in filesystems.

Users doing simple upgrades should not need to know about disk geometry when copying data, really they should not. All that is required is to copy the files to a fresh filesystem of the same or a different type. The risks of the general user misunderstanding how this works and the way that this process will clone a partition table appropriate to one disk onto another for which it is not appropriate mean that this advice is destined to cause problems.

Please, I implore you WITHDRAW THIS HOWTO FROM THE READONLY HOWTO FORUM until this issue has been ironed out and the howto has withstood peer review. oldcpu, I know that as a mod, you have the privs to put this up as a reviewed howto, but I suggest that you take it down from the read only section and let another moderator take the decision to put it up.

[oldcpu]

Originally Posted by NigmaToolin

Personally, I am dead against this howto for adhoc upgrades of hard drives, because of the advice given by robopensuse in this thread.

I read that. Its not a valid reason not to attempt dd when applied to the context and purpose that I defined in the how to.

Originally Posted by NigmaToolin

Generally, dd operates on a byte level and in 'cloning' a partition, what is desired is to copy the files, not the specific byte patterns.

The entire POINT is to copy the bit pattern !!!!

Originally Posted by NigmaToolin

Please, I implore you COLOR="Red"]WITHDRAW THIS HOWTO FROM THE READONLY HOWTO FORUM[/COLOR] until this issue has been ironed out and the howto has withstood peer review.

Give me a technical observation that can hold water. Not something that is not relevant.

I completely disagree with you.

For the qualifications I gave, and for the purpose that the example I gave was used, this worked extremely well.

I also researched the individual partition method suggested by others, and that is fraught with complications and difficulties that the one clone method does not have, FOR THE PURPOSE that I defined.

EDIT: One closing comment, I was amazed by the amount of FUD against dd, by users who had either misused it , or simply did not know how to properly apply it.

[oldcpu]

Further to my above post, ... to say that I did a large amount of research into dd before applying it for a specific purpose of cloning a "healthy" 40 GByte drive image on to a new "healthy" 160 GB drive, would be an understatement. I did a LOT of research.

For those users who wish to follow any debate that may follow on this thread, and I think such a debate would be VERY HEALTHY, then I recommend users first bring themselves up to speed technically. By being up to speed technically, it will make any technical debate much more useful in coming to the truth as to the utility of the how-to.

I recommend a good place to start is to read this very large thread quoted here, from start to finish:
How to migrate XP, Vista, Linux, BSD and Solaris to a bigger hard disk - JustLinux Forums

And finally a plea to all. No insults. Just the specific technical facts, without generalisations. I am "guilty" of complaining about FUD, although if one reads the thread I quote, and then read also this initial thread Looking for new hard drive advice - openSUSE Forums about the warnings I got saying it would never work (until I examined each one in detail, and figured out why the warnings were not applicable if things were done properly) then one might understand why I say there is a lot of FUD.

[NigmaToolin]

Originally Posted by oldcpu

I read that. Its not a valid reason not to attempt dd when applied to the context and purpose that I defined in the how to.

You gave the scope as "This is a basic guide/example for cloning an old small hard EIDE (PATA) internal drive to a new larger EIDE (PATA) internal hard drive, using the linux "dd" command where both hard drives are 255 heads, 63 sectors/track.". That is such a wide scope, for which dd is not always appropriate.

Originally Posted by oldcpu

The entire POINT is to copy the bit pattern !!!!

Fragmentation, lost and orphaned inodes and all?. You joke.

Originally Posted by oldcpu

Give me a technical observation that can hold water. Not something that is not relevant.

OK, "If you use dd for this job, you will carry over all of the rubbish from the previous filesystem, including orphaned data and the complete fragmentation state of the old drive." is a valid and relevant technical observation which I gave you first time.

Also you don't appear to have taken on board my comment "you really are breaching the principle of 'abstraction' inherent in filesystems". Now that is a technical observation which holds water.

Originally Posted by oldcpu

I completely disagree with you.

I think it started with me partially disagreeing with you.

Originally Posted by oldcpu

For the qualifications I gave, and for the purpose that the example I gave was used, this worked extremely well.

For your one instance, undoubtedly it did. But for a noob, it could cause untold trouble. I am not saying don't do it otr publish it, just that if you do, it needs to be set in context as a way of doing the job among several and the issues spelled out.

Originally Posted by oldcpu

[I also researched the individual partition method suggested by others, and that is fraught with complications and difficulties that the one clone method does not have, FOR THE PURPOSE that I defined.

Your purpose is too broadly defined and is itself fraught with issues which are not adequately laid bare.

Originally Posted by oldcpu

EDIT: One closing comment, I was amazed by the amount of FUD against dd, by users who had either misused it , or simply did not know how to properly apply it.

I don't do FUD, I do like to see the right tool for the job. dd is excellent for copying boot records, which are patterns of bytes, and also for archiving old floppy disks into files on CD which can be mounted as though they were floppies. dd is the wrong for your job unless either you really want to capture fragmentation and imperfections in filesystems, or you have a fresh installed working model which you wish to replicate. cp is more appropriate.

If you don't take on board my comment about abstraction, dare I say that you yourself do not understand properly how to apply dd.

[NigmaToolin]

Originally Posted by oldcpu

Further to my above post, ... to say that I did a large amount of research into dd before applying it for a specific purpose of cloning a "healthy" 40 GByte drive image on to a new "healthy" 160 GB drive, would be an understatement. I did a LOT of research.

For those users who wish to follow any debate that may follow on this thread, and I think such a debate would be VERY HEALTHY, then I recommend users first bring themselves up to speed technically. By being up to speed technically, it will make any technical debate much more useful in coming to the truth as to the utility of the how-to.

I recommend a good place to start is to read this very large thread quoted here, from start to finish:
How to migrate XP, Vista, Linux, BSD and Solaris to a bigger hard disk - JustLinux Forums

And finally a plea to all. No insults. Just the specific technical facts, without generalisations. I am "guilty" of complaining about FUD, although if one reads the thread I quote, and then read also this initial thread Looking for new hard drive advice - openSUSE Forums about the warnings I got saying it would never work (until I examined each one in detail, and figured out why the warnings were not applicable if things were done properly) then one might understand why I say there is a lot of FUD.

Let's be accurate here, there is enough controversy around the use of dd, and reading the thread you only did it the once [or for one instance], that you have not produced a 'howto' you have produced a 'howIdidIt'.

I am not denying your success, but I am very concerned that you have not taken into account what is meant by abstraction nor how filesystems are implemented as abstractions in your write up, so that the innocent may stumble in and think that this is the only and right way to do the job. You need to present the implications of the various approaches or at least identify the other approaches within your howto. In other words, you are not being specific enough in defining your purpose to allow potential users to evaluate whether your process is appropriate for what they want to do.

And, sorry to say this, I think that you are being unwise using your mod privileges to put up your own document in the read-only section. Like all the other howto's it should get a peer review first and the author should not be the one to put it up. If you have got it wrong, the price is that you devalue all of the reviewed howtos.

[oldcpu]

Originally Posted by NigmaToolin

You gave the scope as "This is a basic guide/example for cloning an old small hard EIDE (PATA) internal drive to a new larger EIDE (PATA) internal hard drive, using the linux "dd" command where both hard drives are 255 heads, 63 sectors/track.". That is such a wide scope, for which dd is not always appropriate.

How is it too wide?? Explain. Specifics please.

Originally Posted by NigmaToolin

Fragmentation, lost and orphaned inodes and all?. You joke.

A basic assumption, in any guide, is one's PC is operating properly. Show me a guide that states, "Do not do this if your PC is not working". ... Of course that is a basic, understood assumption.

Fragmentation can be cloned. And after the cloning is successful, it can be defragmented with windows utilities. When I cloned my my mother's PC's hard drive, before cloning I backed up her data, then she used it a bit, and then I cloned it. It worked flawless. Afterward I successfully defragmented. Note the caveats about 255 heads, 63 sectors/track.

Give me some specific examples, within the guidelines I provided, as to why it won't work. Not generalizations. Please, I'll say it again. NOT generalizations. Saying "fragmentation" is a generalization. Thats exactly what the comment on "fragmentation" is. It is an attempt to scare users, in the belief that fragmentation will cause a problem with the cloning. It will NOT. And after the cloning the fragmentation can be removed with Windows utilities.

Originally Posted by NigmaToolin

OK, "If you use dd for this job, you will carry over all of the rubbish from the previous filesystem, including orphaned data and the complete fragmentation state of the old drive." is a valid and relevant technical observation which I gave you first time.

So? if the drive is healthy, none of that is fatal. Fragmentation can be fixed with Windows utilities after the cloning.

Why do you not mention that (defragmentation can be done afterward, and hence it is not an issue)?

Originally Posted by NigmaToolin

Also you don't appear to have taken on board my comment "you really are breaching the principle of 'abstraction' inherent in filesystems". Now that is a technical observation which holds water.

You will need to be more specific with an example as to how that is relevant for the example I gave. To me that comes across the same as trying to scare people way because fragmentation is being cloned, where after the clonging the fragmentation can be removed. So you generalize. Specifics please.

Originally Posted by NigmaToolin

For your one instance, undoubtedly it did. But for a noob, it could cause untold trouble.

If a new user makes a mistake following any guide, it can cause problems. You need to be explicit why a new user would have trouble if they follow the guide. Again, a generalization. Specifics please.

Originally Posted by NigmaToolin

I am not saying don't do it otr publish it, just that if you do, it needs to be set in context as a way of doing the job among several and the issues spelled out.

Please state the issues. But not fragmentation. That is a generalization. Specifics please.

Originally Posted by NigmaToolin

Your purpose is too broadly defined and is itself fraught with issues which are not adequately laid bare.

That is a generaliation. Specifics please.

Originally Posted by NigmaToolin

I don't do FUD

Thats good. Then you understand now that fragmentation is not an issue.

Originally Posted by NigmaToolin

dd is excellent for copying boot records, which are patterns of bytes, and also for archiving old floppy disks into files on CD which can be mounted as though they were floppies.

Maybe you can write a how-to on those. It is not my intention to do that.

Originally Posted by NigmaToolin

dd is the wrong for your job unless either you really want to capture fragmentation and imperfections in filesystems

yes, as noted, any such imperfections are not serious if the PC is healthy, and that does not destroy the functionality.

As noted, the "imperfections" can be addressed after the cloning.

I think you need to state that (imperfections can be addressed after the cloning).

Originally Posted by NigmaToolin

If you don't take on board my comment about abstraction, dare I say that you yourself do not understand properly how to apply dd.

I ask no insults.

Did you read the thread I quoted ?? Given the speed of your post, I do not think so. It is a very long thread. The issue was hashed about a LOT in that thread.

I can probably quote 1/2 dozen more threads, equally long, exploring this issue.

I have yet to find a valid technical argument against the careful use of dd, as laid out in the how to.

So, please, no generalities. Specifics.