IV.  Practical howto


IV.1  First things first

Planning partitions

The following factors should be considered when planning partitioning of a hard disk:

  1. Older BIOSes can access only the first 1024 cylinders of the hard disk drive. Therefore, it is not able to boot partitions that start past 1024-th cylinder. The workaround is to make boot partitions for all installed operating systems small enough to fit them all within the first 1024 cylinders.

    A modern BIOS supporting INT 13h extensions can access cylinders greater than 1024. If both Master Boot Code and Partition Boot Code utilize the INT 13h extensions the 8GB or 1024 cylinder limitation is overcome.

  2. Windows NT boot files should reside within the first 1024 cylinders. This limitation is caused by NT boot sector which uses BIOS Int 13h calls to access boot files. Theoretically, boot files can be placed at the very beginning of the boot partition, which allows to make boot partitions that exceed 1024-th cylinder. It is, however, recommended not to make NTFS boot partitions that exceed 1024-th cylinder [MS2].
  3. Safety. When installing two or more operating systems, it is most safe to install them into separate, dedicated hard disk drives. This will prevent data loss of one system when another accidentally crashes the hard disk. Also repartitioning of one system does not influence the other. In this case only one of the hard disks works at the time.
  4. Performance. In contrast to the above, safe model, getting all hard disk drives working for one operating system may improve performance significantly. It can be achieved by partitioning hard disks so that every operating system uses at least one volume on each hard disk.

    The performance depends also on how long distance hard disk heads have to go to access requested data. So, frequently used files like swap should be stored near the middle of the hard disk, and volumes that belong to one operating system should lay side by side.

  5. Provide a file system for data exchange between operating systems. It must be supported by all systems. Most broadly supported is FAT-16.
  6. Solaris 7 and earlier do not support IDE hard disk drives larger than 8 GB, that is, they may access only the first 1024 cylinders of such a disk. Since the problem is on Solaris fdisk side, the workaround is quite straightforward:
    1. Using Linux fdisk program on Linux installation floppy, or Ranish PM create a Linux swap primary partition. It is also possible to create e.g. DOS partition and change its ID to 0x82 (Solaris ID) with a favorite hex-editor and BOOT program, or a disk editor.
    2. Boot Solaris from e.g. its installation CD.
    3. Run format utility and create slices on Solaris partition.
    4. Run newfs to construct file systems on all created slices.
  7. Solaris 2.6 and earlier do not support FAT-32.
  8. Windows NT up to the Service Pack 4 does not support hard disk drives larger than 8 GB. The only way to solve this is to install updated in SP4 ATAPI driver. Separate driver may be downloaded and installed, as well as entire SP4.

    Actually, the boot partition is limited to 4GB only when NT is installed into an empty hard disk. If an NTFS partition is created in advance, the boot partition might be as large as possible.

  9. MS DOS, Windows 3.x and Windows 95 up to OSR2 do not support hard disks larger than 8 GB.
  10. FAT-16 partitions may not exceed 2 GB.
  11. Windows fdisk creates Extended LBA partition of ID 0x0F on disks larger than 32 GB, instead of extended partition of ID 0x05. This may cause problems if another operating system, that is to be installed on the same disk, does not support partitions 0x0F. There are problems during installation of Red Hat 7.1 (and probably older versions), though Linux in general supports partitions 0x0F.
  12. Windows 2000 can not create FAT-32 partitions larger than 32 GB.
  13. Multiple extended partitions are not broadly supported, though NT supports such.
  14. Solaris fdisk reorders entries in the fdisk table in MBR. It may happen that some fdisk utility leaves entries in the fdisk table unsorted, or there are higher slots occupied while lower are left free. If that is the case, Solaris fdisk may reorder the partition entries, which may cause that previously installed operating systems will not boot properly. This affects Linux and BSD. Ranish PM lets to monitor and change the order of partition entries in the fdisk table.

How to preserve an existing operating system?

If an operating system is already setup and running, but occupies entire hard disk, while we want to install another operating system and do not want to loose the existing one, there are a couple of possible ways to go:

  1. Get additional hard disk drive. IDE drives are quite affordable nowadays.
  2. Resize the partition with Ranish PM or some other partition manager if it supports the file system used. This operation is not supported for all file systems. FAT-16, FAT-32, NTFS and Linux ext2fs can be resized with newest Partition Magic. Solaris UFS cannot. Resizing is rather unsafe, the system and data should be backed up prior resizing. The partition should be defragmented prior resizing.
  3. Backup the user data, then reinstall the operating system and software from scratch into a smaller partition, finally restore the user data. This solution is most safe and reliable, though most laborious. Every file system for every operating system may be "resized" this way.
  4. Backup the entire software and data, then restore them into a smaller partition. This solution may fail for some operating systems, e.g. Solaris or Linux. Copying file by file is error prone and requires all file systems to be restored properly.

    For Solaris, in such a situation use ufsdump/ufsrestore utilities. They can be used to either shrink or enlarge all types of slices, including root. To use that method a storage should be provided that fits file of size equal to the size of slice contents.

    All MS operating systems may be backed up as a collection of files, and then restored into a smaller or larger partition. The change of file system is also possible, i.e. the system installed on FAT-16 may be restored on FAT-32 or NTFS and conversely. In case of Windows 9x, NT it is important to restore not only files but also the crucial drives letters, i.e. if applications were installed into D: they have to be restored into D:. For W2K crucial mount points must be restored additionally. User data and archive file systems usually need not to be restored to the same, logical location. To copy file by file of Windows 9x, NT or W2K, an extra operating system that can handle that must be used. That is, if we intend to copy NT on NTFS file by file, the system prohibits opening some files (e.g. registry files) and we have to boot additional copy of NT or W2K to do the job. This requires additional hard disk drive and plenty of storage room.

    Generally NT 4.0 is more robust than W2K. It is not so picky about drive letters and device IRQs assignment as W2K.