DISCLAIMER: USE AT YOUR OWN RISK. THIS DOCUMENT ASSUMES ADVANCED KNOWLEDGE OF PCs. PROCEED WITH EXTREME CAUTION. DO NOT EVER ATTEMPT ANY OF THE OPERATIONS OUTLINED HERE WITHOUT A FULL BACKUP OF YOUR ENTIRE SYSTEM. NEVER ATTEMPT THE FOLLOWING WITHOUT FIRST PRACTICING ON A "DISPOSABLE" SYSTEM. OPERATING SYSTEMS ARE VERY COMPLICATED AND THIS DOCUMENT DEMANDS READER EXPERTISE IN THE AREA. THIS DOCUMENT MAY CONTAIN ERRORS AND EXPERT USERS MUST ALWAYS USE THEIR BEST JUDGEMENT.

Copying/resizing partitions for a dual boot system

(Upgrading to a new, larger disk, and preserving your existing system)

System layouts vary considerably, and I can not offer an all-encompassing guide on how to copy and resize partitions when upgrading disks. This document presents several methods to copy partitions, but you will have to use your own judgement to determine when each method is appropriate. The goal here is to copy your system over to a newer, larger disk, while maybe modifying the partition sizes. Copying filesystems intact will save you the hassle of spending days configuring and tweaking a fresh installation. The copied system should boot and run like the original.

THIS DOCUMENT IS AIMED AT PEOPLE WITH ADVANCED KNOWLEDGE OF PC INTERNALS. ONLY PROCEED IF YOU ALREADY ARE VERY FAMILIAR WITH BOOT SECTORS, PARTITION TABLES, FDISK, ETC.

STEP #1 (THE ONLY ONE THAT MATTERS) : BACK UP EVERYTHING NOW! ASK YOURSELF, "IF ALL DATA ON THE HARD DRIVE(S) DISAPPEARS, WILL THIS BE A DISASTER?" ONLY PROCEED IF THE ANSWER IS 'NO'.

I will document here the details on how I entirely copied a dual-booting Windows 2000 (or NT/XP) and Linux system to a new, larger disk. The resulting system boots and functions identically to the first. The advantage to this is that you don't have to reinstall all your software, nor do you have to change any configurations -- just boot up off your new, larger disk and keep using your system as before! The disadvantage is that you risk losing all data on both disks while you perform this operation. (The same risk applies even if you use expensive partition copying software, though this low level procedure is more risky. While experimenting I accidentally destroyed a partition table and had to recreate it manually)

• MBR: Master Boot Record. This chunk of data starts up the whole system booting process. This is the first 512 bytes of the hard disk (e.g. first 512 bytes of /dev/hda) and contains the partition table. There is one MBR per hard disk. Only the first 446 bytes of the MBR contain booting code; the remaining bytes are the partition table. Thus the first 446 bytes of the MBR can be copied from the old disk to the new disk, since MBR code is quite generic (e.g. stock DOS/Windows). The famous DOS "FDISK /MBR" command just overwrites the first 446 bytes of the disk with a stock MBR.

• Partition table: a listing of all the partitions on the disk, including extended partitions (containing logical drives). The partition table provides the essential mapping of partitions to locations on the disk. The partition table is independent of actual disk contents, but without the correct mapping your disk is unreadable. It is a bad idea to copy partition tables between disks since any difference in partition size or layout will render the copy useless. Note that the partition table is stored within the 512 bytes of the MBR.

• Boot sector(s): Contains code that starts the operating system, the first 512 bytes of each partition. While there is only one MBR per disk, there is a boot sector for each partition (e.g. /dev/hda1). Dual boot installations typically rely on a boot menu selector pointing towards one of several boot sectors. With multiple operating systems on a single disk, each operating system will have its own boot sector on its own partition.

It is very easy to back up these essential parts of your disk. You will need to copy (part of) the MBR, and boot sectors in order to have your new system boot like the old one.

To save the MBR to a file (this contains the partition table too):
dd if=/dev/hda of=hda-mbr-full bs=512 count=1

To save the MBR, without the partition table, to a file:
dd if=/dev/hda of=hda-mbr-nopart bs=446 count=1

To save a boot sector (e.g. partition 3) to a file:
dd if=/dev/hda3 of=hda3-bootsect bs=512 count=1

The complementary dd commands, using the appropriate input file and the disk for the output file, will restore/overwrite the data. Obviously this is a very risky operation, so exercise great care. I also recommend copying backups of your MBR and boot sectors to a floppy disk, along with md5sum-generated hashes to verify integrity. The MBR and boot sectors are very important.

Generally speaking, you will need to make an exact copy of a partition (same size) when you are transferring over a DOS or Windows system volume, because certain files have to be at exact offsets within the file system, or in the case of NTFS, a direct raw copy avoids problems in transferring sensitive security files and files which the Administrator does not have read access to. For example, DOS/Windows drive C: should probably be exactly duplicated to avoid problems booting Windows.

The source and destination partitions must be the exact same size. Use the fdisk command to observe the length of your source partition, and create a destination partition with the exact same size. For example:

Disk /dev/hda: 81.9 GB, 81964302336 bytes
255 heads, 63 sectors/track, 9964 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
...
/dev/hda5             132         641     4096543+   7  HPFS/NTFS

For the above, you can make an exact copy of the indicated NTFS file system by creating a destination partition that is (641 - 132 + 1 = 510 cylinders) in size. The Linux 'fdisk' command lets you specify values in cylinders when you add partitions. Reboot after changing the partition table so that the kernel recognizes the new partition sizes. Then you can use the 'dd' command to copy over the entire partition:

The above command will copy the indicated partition over from the source disk (hda) to the destination disk (hdb). Generally speaking, the partition number on the destination disk can be different from the source partition number. However, keeping the same numbering scheme for your destination partition layout ensures that the operating system does not get confused referencing its various files across partitions (no modifications needed to setups).

In contrast to this byte-for-byte raw copy, when transferring over a data volume or a volume containing non-operating system applications, you can use an application level copying tool and resize partitions while you're at it. This is another good reason to separate a system/boot volume from data and application volumes; system volumes are messy to copy, but application and data volumes don't have the same picky constraints.

If the partition in question is not a system volume, then you can simply use the Windows NT "XCOPY.EXE" program to make a good duplicate. This is appropriate for data volumes or for volumes storing application programs.

To start with, boot an active Windows NT (NT4/2000/XP) system with the two hard drives (source and destination). Create the destination volume, which can be any size greater than or equal to the source. Then use an XCOPY command such as:

This generally works, preserving the directory structure, attributes, ownership and security. Consult documentation for XCOPY for syntax details. This command should work on Windows 2000 and Windows XP. Note that encrypted filesystems likely can not be copied this easily.

Linux volumes are much easier to copy/resize, even the root filesystem itself. You should boot an active Linux system with the two hard drives (source and destination) and then create and format the destination partition. As before, use fdisk to create the partition and mke2fs or mkreiserfs, etc. to create a blank filesystem. Mount the destination filesystem. 'cd' to the root of the source filesystem.

You can then copy the entire filesystem with:

This recurses the source file system, without dipping into paths that leave that filesystem, and feeds the file listing to cpio. The 'cpio' program then operates in copy-pass mode, preserving permissions and time stamps. This method seems to deal properly with device files. In case your destination partition is not numbered the same as your source, you will have to of course modify /etc/fstab. Other complications may result, but cpio seems to be a popular way to copy a root filesystem.

1. Copy your MBR from the old disk to the new disk, but only the first 446 bytes because otherwise you will overwrite the destination partition table!

2. Try to keep as close to the original partition layout as possible. This is more important for DOS/Windows systems, in which the OS and applications will use drive letters (C: D: etc.) to find files they need. For UNIX systems, this is not a major issue since you can easily modify /etc/fstab after the copy to update the mount points.

3. Boot sectors can sometimes be directly copied, but other times will have to be created fresh. For DOS/Windows, the drive C: boot sector can be directly copied to your new disk. For NT systems, the boot sector will launch a program (NTLDR) that is then capable of booting the main NT volume. Note that the NT 'boot.ini' file will have to be updated if your partition layout changes.

4. For Linux systems, it is best to boot from a CD-ROM after transferring your file systems order. You can then re-run 'lilo' to recreate the boot sector. What exactly you have to do depends on whether you're dual booting, which loader will be booted via the MBR, etc.

5. Always test to make sure your file systems have been copied over correctly. Use 'cfdisk' to double check your partition table. Run CHKDSK.EXE or fsck, reiserfsck etc. as the case may be to check your copied file system.

6. In case of problems, double check to make sure that you are using dd to raw copy a partition only when the source and destination have equal sizes. Make sure that a valid MBR, valid boot sectors, and valid partition table exists.

7. The boot loader programs from different operating systems have different requirements for a 'valid' partition table format. For example, a partition table with multiple partitions flagged bootable is valid by LILO, but invalid for DOS/Windows.

Copyright (C) 2005 SysDesign