If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Using a Linux Live CD to clone XP and/or Vista

Recent updates

27 Apr 09 - The procedure set out here is applicable to Xp, Vista and Win7, regardless how many of them in the hard disk. No re-activation is needed but a reboot is generally necessary for the system to update its registry to account for a change in the hardware. Remember to remove the source disk or hide the source partition when booting the new traget partition or disk. Newer M$ systems uses a unique code for each partition identification which will be faithfully cloned. This can cause confusion to the OS if two identical partition codes are encountered. Generally the OS will disable the second partition and possibly invalidate its booting code.

30 Jan 07 - for reliably resizing XP partitions there are now free Linux Live CD on Gparted and Parted Magic
For a modern, informative and authoritative use of dd see AwesomeMachine's thread "Learn dd command"

13 May 07 - Section B added to include cloning the whole hard disk. I have since rewritten Section B as a separate thread in view of it being a general methodwhich is recommended because it is a lot simpler but totally reliable. All you need is a hard disk exactly in size or just larger.

1 July 07 - A worked example to clone Windows Vista has been added in Post #55 of this thread

21 Oct 07 - Recommended block size now changed from 32768 to 32256 as the latter proves easier to finish with a full record in the last transfer.

----------------------------------------------------------------

Section A - Cloning a XP partition

For cloning Vista or an easier scheme see Section B

An installed Windows XP protects itself from being cloned even for the backup purpose. Specialised software like the Norton Ghost, Acronis or PowerQuest Drive Image has to be used so that the OS can be moved to a bigger hard drive in a disk upgrade.

Linuxs dd command also works the same way but this needed to be performed on the whole hard disk so that the MBR and partition table are cloned as one whole lot.

The method described below shows how Linux can be used to clone a XP partition. In the example here the source is a XP Pro partition in a 30Gb IDE drive recognised by Linux as hda1. For simplicity I used a disk with just one partition in it. The source XP partition has a SATA driver previously incorporated when installed. The target is a brand new unformatted 200 Gb SATA disk recognised by Linux as sda (older kernel may report hde).

To demonstrate the power of Linux I use only a Live CD from Knoppix 3.4. There is no other bootable Linux in the hard disk.
(1) Install both source IDE (hda) and SATA (sda) as internal hard disks into the PC and boot the computer up with Knoppix Live CD.

(2) Click Knoppixs terminal mode, type

Code:

su

to become the root user.

(3) Type

Code:

fdisk -l

to check the hda and sda structures if needed (Recommended so that you know what you are doing).

(4) Type

Code:

cfdisk /dev/hda

to write down the exact size of hda1, assumed NTFS type.

(5) Type

Code:

cfdisk /dev/sda

and create a primary sda1 partition, select file type NTFS (type No 7) and size identical to hda1, select it to be it bootable too, let it write the partition table and exit (recommend a reboot here to make the partition table permanent)

(6) Native copying by typing

Code:

dd if=/dev/hda1 of=/dev/sda1 bs=32256

The 32256 is the track size for 63 sectors each 512 byte. Progress is slower if bs is omitted and Linux would use the default block size 512.

(7) When dd operation completes it will show the time taken on the screen. Power down, remove Knoppix, remove the source disk hda. (re-set the new disk as the master, no action is needed if it is in cable select mode for the Pata disk. Sata disk has no master/slave setting and the booting queue is controlled by the Bios only)

(8) Boot system up with a DOS floppy (with fdisk.exe inside) to restore MBR by typing

Code:

fdisk /mbr

This works even on a SATA disk. Alternative boot up any Win2k or XP installation CD, go to the recovery console and issure command

Code:

fixmbr

(9) Remove DOS floppy and the SATA should be bootable with XP cloned.

Did this twice with a XP home and then a XP Pro. The above example has XP Pro in a 28.6Gb partition with 16.1 filled data. It took 4297 second or 72 minutes. On another 10.1Gb partition with XP home in 5.24 Gb data the time was 1409 seconds or 24 minutes. Naturally the two different licenses of XP booted successfully.

If the Linux has been installed from a hard disk and has the 2.6 kernel the time needed can be reduced considerably (about 50&#37.

The cloning rate for current versions Linux is about 45-55Mb/s for internal disks.
--------------------------------------------------------------

Section B - Cloning the whole disk containing either Win2k, XP, Vista or in any combination with or without other operating systems.

This method is highly recommended because it is the most reliable. The whole source disk is cloned to a target disk. The only essential requirement is the target disk must be as larger as the source disk, down to the exact number of sectors or simply just bigger.

The cloning has been 100% successful in the following applications

From a Pata to a Sata disk or the opposite way, both internal disks.
From an internal disk to an external USB hard disk or the opposite way
From a 2.5" latop disk to a 3.5" desktop hard disk (the opposite way not tried).

The number of operating systems and the types are immaterial to the cloning. I have the maximum 63 partitions in many disks cloned this way and every operating systems in the clone boots exactly as the original. The systems I cloned include a mixture of Dos, Windows (3x, 9x,2k, Xp & Vista), Linux, BSD and Solaris.

I am so confident with this method that on the completion of the cloning process I would remove the original source disk, put it away for safe keeping as the backup and start to use the newly cloned disk straight away, as I have never met a problem in upgrading my hard disk from 200Gb to 300Gb, then to 400Gb and finally to 500Gb.

I shall use the example of cloning an existing Pata hard disk known in Linux as hda into a newly purchased larger Pata disk hooked up as a USB hard disk. To Linux a USB disk belongs to the SCSI/Sata family and is called sda if it is the first one in the PC, otherwise it could be a sdb, sdc, sdd, sde etc.

Here is the simple steps

(1) Obtain a Linux Live CD. Any one will do because the dd command is an integral part of Linux terminal command. However for fast cloning please use the current version of Linux Live CD. Recommeded distros are Slax, Knoppix, Kanotix, Mepis, Fedora Live, Mandriva Live etc. Ubuntu is also suitable but it is slight more work to get root privilege.

(2) Obtain a hard disk enclosure and purchase a new hard disk is has a capacity larger than the original source disk. Cloning is just like putting a carbon paper between two sheets. It will not work out if the bottom sheet is physically smaller than the top sheet as part of the information cannot be recorded out. That will happen exactly to hard disk cloning. It is very simple. The partition table has been copied from a bigger original disk resulting some hard disk addresses cannot be found on the smaller cloned hard disk.

(3) Cut the seal from the new disk and install it into the hard disk enclosure as a raw disk. Hook it up to the PC as a USB hard disk. Boot up the PC with a Linux Live CD.

(4) Select terminal mode and become the superuser by issuing the terminal command

Code:

su

The standard practice in Linux Live CD is to waive the demand of root password which will be demand only if the Linux is installed into the hard disk, but there are always variations. If a root password is demanded take a look at the /home directory as the Live CD developer usually left a hint on how to get the root password. Some distros will work if you just press enter (i.e. blank password), other will accept "root" or "toor". I recommend Slax and its family distros because the root password is printed before the login.

(5) Check the hard disk naming notation in Linux by command

Code:

fdisk -l

Linux call a Pata either hda, hdb, hdc or hdd. For Sata it can be sda, sdb, sdc, sdd, sde, sdf etc. An USB disk also follows the SCSI/Sata notation so it will be call sda if there is no Sata or SCSI disk in the system, otherwise it will take the name sdx where x is the next alphabet not yet taken. One can see the name of the newly hooked USB disk as it has no partition inside and the capacity should correspond to the size purchased. I shall assume this new target disk to be sda. Please adjust according to your own circumstance.

(6) You can start the cloning process by one line of command

Code:

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

In the above "if" is the input device and "of" stands for the output device. The Block size parameter bs has been chosen to be one complete track of 64 sectors each 512 bytes. Omitting the bs parameter will cause dd to default to 512 bytes in each transfer and this slows down the cloning. The 32256 is about the optimum I have found.

For AMD 3200 Athlon PC with 1Gb ram my cloning speed between internal disk is about 50Mb/s. If one disk is a USB this can drop to about 10Gb/s.

dd does not output any information until the process is completed. The flickering LED of the hard disk tells us dd is busy. On completion dd will always report the number of records, each equal to the the specified block size, transferred. Multiplying the record number with the block size should correspond to the capacity of the source hard disk.

I recommend removing the source disk, put it away for safe keeping as the backup, install the cloned disk in its place and start using the new disk right away.

For those who is not already aware dd stands for "data dump" meaning the binary pattern from a source disk is read and then written on the target disk. Technically it is impossible to clone a disk that is not a 100% carbon copy of the original.

The newly cloned disk's extra capacity over and above the original disk simply become the unallocated hard disk space which can be absorbed into the existing partitions by gparted or Parted Magic. It is recommended the current versions of these software to be downloaded and run as Live CD.

It has been my experience the whole hard disk cloning will always work on XP and Vista.

The current Live CD versions of gparted and Parted Magic are good for resizing XP. To resize Vista I recommend using its own internal resizer program which is faster and the success is guaranteed by M$.

It is recommended Vista to be cloned as the whole hard disk. This is because the current Vista has a new MBR and will conduct a check on the partition table. It can use a change to the partition table, between a reboot, as an excuse for the security risk to refuse to boot. Cloning the whole disk gives Vista no such excuse because the partition table isn't changed. Vista will still be able to detect the hard disk has been altered and demands an immediate reboot, same as XP. After a reboot Vista will work normally after the hard disk serial number has been updated.

Re: Using a Linux Live CD to clone XP

Originally posted by saikee Type "cfdisk /dev/hde" and create a primary hde1 partition, select file type NTFS (type No 7) and size identical to hda1, select it to be it bootable too, let it write the partition table and exit (recommend a reboot here to make the partition table permanent)

Yes, you MUST reboot here. If you don't, you risk serious damage to your drive.
The only way you can get around rebooting is by running program partprobe.

Partprobe works great, and I have used it several times before with no problems.

I know Linuxs dd command also works but this needed to be performed on the whole hard disk so that the MBR and partition table are cloned as one whole lot. This is only successful for source and target disks having identical size.

Are you sure about this? I have moved a linux install directly from a small disk to a larger disk without any problems, the rest of the drive just becomes free space with which you can make new partitions. I don't see why this would be a problem to Windows, but I haven't tried it.

Also I should mention there is a ntfsclone tool, which allows you to copy the whole filesystem with the unused space being zeroed, which will allow to compress the image a lot more efficiently than compressing the filesystem directly if you want to store a copy. However I haven't used this, so I don't know how well it works.

The dd copies the hard disk data natively in 1s and 0s and probably not an ideal tool to back up a "filing system".

However inside every partition there is a boot sector for storing the boot loader which is NOT part of the filing system. You will have no doubt seen threads that a Windows user complaining not able to get rid of a Linux boot loader after formatting the whole drive.

dd comes in its own because it copies the boot sector across and does not care what the filing system is. That is why Linux can't write on a NTFS partition (gradually changing now) but can clone it. It goes without saying that we can clone Solaris and BSD partition in the same manner.

dd works by counting the bytes, sectors, heads or cylinder. If the source and target partitions or disks are identical then the cloning is perfect because the internal sizes will be exactly matched.

If we back up a filing system in Linux there are many better tools than dd which only copies 1s and 0s religiously without knowing the data can be empty.

Many users say their back up images from a filing-orientated software also boot but that is more to do with the original bootloader and MBR haven't been moved. If we clone a the filing-system XP into a new disk it will not boot. If you do a defrag in XP you will also notice part of the files is unmovable. Therefore a 100% mirror image by dd is the way foraward because it faithfully preserves the original filing structure and the boot loader.

I have used Ghost for cloning XP before I learned to use dd. It has to drop XP system first, hide itself inside the boot sector and so as to re-appear as a Dos program after a reboot. The cloning is also byte by byte too. Ghost has the ability to cope with a target different in size to the source. One needs to pay a license fee to get it. dd is free and much neater if you know how to use it.

dd is fast too. I record a 50Mb/s rate for a 5Gb partition transfer. About 10 days ago I "dd" an extendted partition with 55 logical partitions inside ecah has an operating system and a boot loader. One of the logical partition has a NetBSD. The average 285Gb data transfer rate was 43Mb/s on my IDE with a Asrock mobo with a Amd64 3200 CPU.

To me at least using dd is technically sound and logical to clone a XP system.

XP is copy-protected so that a cloned copy cannot be used on another PC because it will lock up solid when the new hardware is significantly different to the original. This thread can only help a owner to backup a bootable XP system using a simple facility availbale in a free Linux Live CD because XP does not even allow itself to be copied out. The cloned copy is a useful way to have something to fall back on as XP is the most infected system in a PC.

Was your post a response to mine or just adding background information to how the cloning process works? It's hard to tell since it was posted shortly after mine, but doesn't refer directly to what I commented on.

Originally Posted by saikee

The dd copies the hard disk data natively in 1s and 0s and probably not an ideal tool to back up a "filing system".

It certainly isn't, since it will also copy old left over information that is in currently unused parts of the filesystem, therefore limiting it's compressablility and increasing the space it takes to store.

However inside every partition there is a boot sector for storing the boot loader which is NOT part of the filing system.

Slightly OT, but it doesn't apply to XFS partitions, so you can't say "every partition". It is for this reason you can't install a bootloader to a XFS partition and instead need to use a boot partition with a different filesystem for this purpose or use the MBR instead.

dd works by counting the bytes, sectors, heads or cylinder. If the source and target partitions or disks are identical then the cloning is perfect because the internal sizes will be exactly matched.

The source and target partitions do not have to be the same size when you use dd, but the target must be at least the size of the source partition. If the target partition is bigger you will need to use a tool to resize the filesystem to make use of the extra space.

If you do a defrag in XP you will also notice part of the files is unmovable.

Usually this is because the file(s) is in use (typically the swap file) or belongs to another user whose files you don't have permission to access.

To me at least using dd is technically sound and logical to clone a XP system.

I agree, there is nothing wrong with using dd for this job. I did mention ntfsclone in my previous post because I had heard of it, maybe it would be quicker since it actually understands the filesystem and won't copy empty data which could in theory save time, but I don't know for sure if it will.

XP is copy-protected so that a cloned copy cannot be used on another PC because it will lock up solid when the new hardware is significantly different to the original.

If it locks up solid, it is not because of copy protection, but rather it is likely that the hardware requires a different incompatible HAL in Windows (you can't change the HAL after installing Windows), otherwise it should boot and just require a new activation code.

You asked me if it is nessary to have identical size of the source and target disks in the cloning and suggested transferring the filing system will so I tried to explain it by dd does its work in native format. Such process requires the number sectors exactly matched.

I am aware that there is at least one filing system that disregards the boot sector arrangement.

On the different partition/disk size between source and target I suppose one can always clone a 200Gb disk into the first part of a 300Gb disk. However if all the 3 primary and one extended partitions have been created already then the extra space at the back may require an above-average skill to make it usable.

On the XP copy-protection the re-activation isn't always guaranteed if a cloned unit is used in a changed environment. I think it is well publicised that XP keeps a record on the hardware including the serial number of the hard disk. Each device has a number of points assigned to it and the re-activation or lockup depends on how much much hardware has been changed. I had one PC locked up when I changed a toasted CPU at the time my son went to university. I offered to swap my wireless nic with his wired ethernet card because he was going into a rented accommodation (no wiring allowed). The nic card and the CPU are among the highest in the point system scale and the PC was instantly unbootable. I called MS up and explained. They unlocked it from the Internet side. On my side I can't do anything to it. Sound like a scary story but it did happen to me once. Since then I went into Linux because I can't have my home computers controlled this way.

You asked me if it is nessary to have identical size of the source and target disks in the cloning and suggested transferring the filing system will so I tried to explain it by dd does its work in native format. Such process requires the number sectors exactly matched.

Actually, I asked if you were sure if it was necessary for Windows because it is not necessary for the source and target to be identical in size to actually copy a filesystem and I don't see why Windows would be different in this regard, but I haven't tried this on a filesystem Windows uses. I do know how dd works.

On the different partition/disk size between source and target I suppose one can always clone a 200Gb disk into the first part of a 300Gb disk. However if all the 3 primary and one extended partitions have been created already then the extra space at the back may require an above-average skill to make it usable.

If the extended partition is at the end of the drive there will be no difficulty in using the space, but if it is at the beggining or middle, then it would be tricky making the space usable.