Multiple OS Installation

These instructions are for installing more than two operating systems on your hard drive. If you only need two operating systems (such as a Windows installation and a (K)ubuntu Linux installation), it is easiest to just use the (K)ubuntu installer to do it for you (as detailed on the main page).

Warning: As of version 9.10 (Karmic Koala), the (K)Ubuntu Desktop edition LiveCD installer uses Grub2 (which is difficult to customize) and does not allow the specific steps needed in this tutorial. DO NOT USE the Karmic Koala Desktop edition LiveCD for installation if you have a dedicated boot partition, use more than 2 operating systems, or chainload bootloaders. The (K)ubuntu Desktop edition LiveCD installer will overwrite your Master Boot Record and you will then be forced to re-create it later. This is a flaw in the LiveCD installer of Karmic Koala. Install the Alternate CD edition instead, or even the Ubuntu Server edition (and then add the ubuntu-desktop afterwards).

Warning: During installation of 10.04 (Lucid Lynx) and later, there is an advanced option (Ready to install -> Summary -> Advanced) to choose whether to install the GRUB2 bootloader into both the partition into which the (K)Ubuntu OS is installed as well as the Master Boot Record MBR) or just to install it into the partition into which the (K)Ubuntu OS is installed (only). If your system uses a boot partition, uses multiple OS (more than 2), or chainloads bootloaders then pay careful attention during this step. For systems with boot partitions that have already been configured (and to which the Master Boot Record already refers to as the partition which contains the initial bootloader), it is best not to overwrite the MBR during any OS installation.

Example, from the Desktop version GUI installer, a point in the installation will be reached:

In this example, this setting will cause the GRUB2 bootloader to be installed into /dev/sda6 only (the partition into which the new (K)Ubuntu OS is being installed). The MBR (Master Boot Record) will not be changed. However, if the default setting of /dev/sda were to be chosen, GRUB2 would not only be installed into partition /dev/sda6 (into which the (K)Ubuntu OS is installed) but also the MBR (designated as /dev/sda) would be changed. The copy of GRUB2 stored in /dev/sda6 wwould then be designated by the MBR as the master bootloader for all Operating Systems on the entire computer. This is undesirable if you wish to use a master bootloader (such as Grub Legacy stored in the boot partition) instead of GRUB2.

Introduction

If your computer, device, or hardware uses UEFI instead of a BIOS bootup system, then also see this page.

If your computer, device, or hardware uses Coreboot instead of a BIOS bootup system, then also see this page.

The method described here involves creating a small boot partition in which to store a set of Grub bootloader configuration files. (These files will be created during the first Ubuntu Linux OS installation and then copied to the boot partition where they can subsequently be edited.) The initial Grub menu will always be kept in this small boot partition. Each operating system will then keep its own set of bootloader configuration files within its own partition. The Grub menu residing in the boot partition will be only be used to chainload the specific bootloader files stored in the partition of whichever operating system is chosen from the menu (no matter whether the chosen operating system is a Windows, Mac, (K)ubuntu, or other Linux operating system).

Each operating system can therefore use the bootloader/configuration file that is peculiar to it, storing it in its own partition. If the kernel, filesystem, or even the bootloader files for that operating system changes (within its own partition) for any reason, it will not affect the kernel, filesystem, or bootloader files of the operating systems stored in the other partitions. It will also not affect the primary bootup menu (stored in the boot partition), and each operating system will be able keep its own independent bootup process intact.

This avoids a common problem with many operating system installers (including Ubuntu) which attempt to impose a single bootloader on all the operating systems residing on a hard drive. The installer overwrites the Master Boot Record so that it only points to the bootloader installed with that operating system (within that operating system's partition). When this happens, the bootloader files can only be edited while running that particular operating system and cannot be adjusted by any other operating system. Further, after this happens several times (following multiple OS installations), it eventually becomes difficult to remember which partition has the bootloader configuration files that the Master Boot Record points to. With the chainloading method, you don't have to worry about that, any longer. The Master Boot Record will be set to point to the bootloader configuration files stored in the boot partition at all times. Once this is set up, the Master Boot Record need never be changed.

Using Grub Legacy for the boot partition

This method uses Grub Legacy as the bootloader to be installed to the boot partition (because it is the easiest to customize). Starting with Karmic Koala 9.10, however, Ubuntu/Kubuntu uses Grub 2 (instead of Grub Legacy) by default.

An easy and fast method is to use an Ubuntu Server edition 9.04 LiveCD (which uses Grub Legacy) to install the first instance of Ubuntu Linux (and Grub Legacy). Use the minimal install (i.e. don't install any extra packages), in the interest of speed. Proceed with the installation instructions that install Grub to the Master Boot Record, as well as installing a second copy of Grub Legacy to the local partition. Then copy the Grub Legacy settings to the boot partition as described. Edit the Grub Legacy menu settings stored in the boot partition so that chainloading to each planned partition is enabled.

Once this is finished, re-install a newer version of Ubuntu/Kubuntu to the same partition (overwriting the 9.04 server version). However, this time do not allow the new installation process to overwrite the Master Boot Record. (We want the Master Boot Record always to use Grub Legacy, not Grub2.) Install Grub2 (this time) to the local partition only. This method is described in further detail below.

A second method involves installing (K)Ubuntu completely (using the LiveCD installer), then removing Grub2 from the (K)Ubuntu partition. Grub Legacy is then temporarily installed in its place and copied to the boot partition. The Master Boot Record is set to refer to this copy of Grub Legacy stored in the boot partition. After this has been done, Grub Legacy is then removed from the (K)Ubuntu installation (but left in place in the boot partition) and Grub2 re-installed in the (K)Ubuntu partition's /boot directory once again. This method is described in further detail here.

Now the Master Boot Record will always use Grub Legacy (stored in the boot partition) merely as a chainloader to each subsequent partition, where that chosen partition's particular bootloader will be run directly from within the partition (no matter if it is a Windows partition's bootloader, a (K)Ubuntu partition's bootloader (e.g. Grub2), or a Mac partition's bootloader).

Partition design

Three primary partitions and one extended partition are allowed on your hard drive. The extended partition can be divided into a very large number of logical partitions. Each Windows installation will need to be installed on a primary partition. All the Linux (including Ubuntu/Kubuntu) installations, though, can (and should) exist in logical partitions, so you can have as many as you want. The swap partition, also, can (and should) live on a logical partition.

The easiest way to do this is to use the GParted Live CD as a partition manager, or using the GParted application directly from the Ubuntu LiveCD (Menu -> System -> Administration -> GParted) or KDE Partition Manager from newer versions of the Kubuntu LiveCD.

At the minimum you will need:

one primary partition for each Windows OS

an extra small primary partition (which can be resized later, in case is needed). If a Windows boot partition exists as a second NTFS partition, it should be left alone. If there is a Windows recovery partition also installed, it can also be left alone as long as there are only two NTFS partitions total on the hard drive (i.e. there is no NTFS boot partition as well). If there are a total of 3 NTFS partitions on the hard drive, then the third Windows NTFS partition (the recovery partition) should be removed after creating Recovery CDs from it (see here).

one primary partition for the small boot partition (for storing a set of GRUB files)

an extended partition for the Linux OSs (should be the last partition on the hard drive)

my "extra" partition 2 Gb -- which I tend to format as filesystem FAT32 (but can be anything, including ext3). If this is a Windows boot (or recovery) partition, it can be left unchanged.

my Grub partition 50 - 100 Mb -- formatted to filesystem type ext3

the extended partition is the remainder

At the end of the hard drive I usually leave a few Gb of free space (to allow for extra logical partition needs that I have not foreseen). This can't be done unless the extended partition is the last partition.

I then divide the extended partition into logical partitions:

a /swap logical partition that is 2 Gb -- filesystem type linux-swap

a logical partition for the / (root) folder of each planned OS (at least 10 Gb each, but 20-50 Gb is better) -- formatted as ext3 (or ext4 if you are planning to use a newer Linux OS)

optionally, a logical partition for each specific use, such as for a groupware partition (like Kolab, for example). I make this about 20 Gb and format it as ext3, since most specific uses (like Kolab) will be comfortable with ext3. Another example is creating a partition for the /home directory.

Note: If you are re-arranging (re-partitioning and re-formatting) your hard drive after already having a Grub bootloader installed, you will not be able to boot into Windows (or anything else) until you re-install Grub as part of a Linux OS re-installation. Panic not. Just proceed in a calm and orderly fashion.

Windows partitions

It is easiest if your Windows partition is the first one installed. This is because the Windows bootloader looks for Windows in the first partition. Also, Windows installers are unpredictable and can overwrite anything that is already installed on the hard drive.

If you have a brand new computer with no OS pre-installed, partitioning and OS installation is much easier. Create all your partitions before installing Windows. Make the first partition NTFS (or the less secure FAT32, if you wish), intending it for the Windows installation. Then divide the remainder of the hard drive (using GParted) using the partitioning scheme outlined above.

Generally, a retail "boxed" version of Windows (instead of an OEM or "backup" copy) installs quite happily to the first pre-configured, pre-sized partition. Go ahead and install it there, then skip on ahead to installing the Linux OSs.

However, OEM and "backup" copies of Windows often have installation peculiarities (including pre-configured spamware, spyware, and specific hardware configurations) that will want to use the entire hard drive. Oh well, if you must, you must.

After doing so, you will then have to shrink the partition down to approximately 20-30 Gb (or your desired size).

Changing Windows partition sizes

Using Shrink Volume on Vista and Windows 7

Make sure you heed the warnings that you should change the size of Windows Vista and Windows 7 partitions from within Windows only (using Settings -> Control Panel -> Administrative Tools -> Computer Management -> Storage -> Disk Management -> Shrink Volume), or using specific Windows tools made exclusively for this purpose.

Unlike Windows XP (and earlier Windows versions), Vista and Windows 7 does not allow you to move the MFT (Master File Table) that controls the NTFS file structure. Inexplicably, Microsoft locates this near the middle (or end) of the partition, somewhat limiting the ability to resize (shrink) the partition completely. You will be able to gain some hard drive from the "Shrink Volume" command (under Settings -> Control Panel -> Administrative Tools -> Computer Management -> Storage -> Disk Management), but not all of of the hard drive. I knew of no partition software that could move the MFT to a different place on the hard drive safely, but this tutorial suggested that Perfect Disk worked for this purpose. I therefore tried the trial version of Perfect Disk, and it seemed to work for me very nicely. I was able to shrink my Vista partition, using the steps in the tutorial (and Perfect Disk), from 300 Gb to 74 Gb. This was perfect for me.

You must then reboot those Windows OSs (once or twice) to allow them to adjust themselves to the partition size change (before using GParted for any other tasks). I have ruined several Windows installations by using GParted to resize the partitions for Windows Vista and Windows 7, or by forgetting to reboot Windows prior to using GParted. During these reboots, the Windows bootloader stores information about the changed partition size in its configuration file. If it doesn't have the chance to do this, the Windows bootloader will no longer work properly, and you will not be able to boot Windows.

Reinstalling Vista or Windows 7 on a new partition

A popular way to regain a significant amount of your hard drive with Vista/Windows 7 is to first re-format and re-partition the hard drive, and then re-install Vista/Windows 7 afterwards. When this works, you can reinstall Vista/Windows 7 in as little as 30 Gb.

Using Windows Recovery Disks

For a Windows re-installation, you will either need a retail version of Windows or a "Recovery" disk provided by your OEM (computer) manufacturer. The "Recovery" disk must allow Windows re-installation to a partition of any size. (Some recovery disks only allow re-installation to the entire hard drive).

My eMachines, Dell, and Toshiba Recovery disks, for example, allowed re-installation to any size partition, but my HP Recovery Disks did not. The HP Recovery Disk erased the entire hard drive (and all the data on it) and re-created a single Windows partition. All partitions (and the data in them) were destroyed in the process. (I therefore do not recommend using HP Recovery disks for this method. For HP computers with a Recovery Disk, use the shrink volume method outlined above, instead).

Physical Recovery Disks are not always shipped with a new computer. For example, my eMachines box instead provided a utility (eMachines -> eMachines Recovery Management) to create (burn) a pair of Recovery DVDs using data stored on an image in a recovery partition. If your OEM manufacturer gives you a similar option of burning Recovery disks (instead of supplying Recovery CD/DVDs with your computer), make sure you burn these disks prior to reformatting/repartitioning your hard drive. If your hard drive becomes corrupted during the re-partitioning process and you haven't created Recovery Disks, it will be too late.

Once the Recovery Disks are burned, it is no longer necessary to keep the recovery partition (and Windows can be re-installed without it).

As outlined in my partitioning scheme, I reserved the first primary partition for Windows. This can either be left as free space at the beginning of the drive (to be formatted as NTFS by the Windows installer later), or it can be formatted (by GParted, for example) as an NTFS partition with the boot flag set. I left 60 Gb for this first primary partition area (although 40 Gb is probably more than enough, since my Vista re-install occupied only 22 Gb). The Windows Recovery disk was able to re-install Windows no matter which method I used. Since this was really a "new" install, I didn't have to worry about the MFT table location problem, which was placed by the Windows installer within the new partition without any difficulty.

Obviously, to completely re-install an operating system if you have been using your computer a long time would entail an awful lot of work. You would have to back up all your data files first, re-install all your programs after re-installing the operating system, and then restore the data files you had backed up. I wouldn't want to do this on anything but a new computer.

Windows XP (or earlier)

You can use GParted to resize a Windows XP partition directly (without needing re-installation), but it is still best to reboot Windows XP twice after resizing its partition (before taking any other steps with GParted). Review this tutorial's section "Making Shrink Volume Work." Although Windows XP does not have a shrink volume utility, to resize the partition using GParted, these steps must be taken anyway. Specifically:

then reboot once (which will erase the C:\pagefile.sys file). Defragment the hard drive. Then log off Windows and start GParted. Now you will be able to shrink the XP partition.

After resizing the NTFS Windows partition, quit GParted and log into Windows again. Chkdsk will be run automatically and the computer will reboot. Login to a user account in Windows. It will prompt you to reinstall new hardware (the resized partition). Accept. Now turn back on the services turned off in the steps listed above, in reverse order. To be safe, log off Windows and log in one extra time. Now you are finished resizing the Windows XP partition and can proceed to other disk manipulations with GParted (or other activities such as installing (K)Ubuntu).

Windows bootloaders

The Windows bootloader stores information about how big the partitions on the hard drive are. If you change a partition size, Windows checks the new partition size at the very next reboot (using either chkdsk in XP or a new utility in Vista/Windows 7). It then writes that info to its bootloader configuration file. If you start mucking around with other partitions before it has a chance to record the changes and reset itself accordingly, the Windows bootloader will not be able to read the partition table properly (and will then refuse to boot entirely).

Since Grub boots Windows merely by chainloading the Windows bootloader, if the Windows bootloader doesn't work (i.e. doesn't recognize its own changed partition), then you are sunk.

If you ignore these warnings, I almost guarantee you will fry your Windows partitioning scheme and be unable to boot up Windows.

Install Ubuntu server -> (the usual pleasantries about language and mice and keyboards and stuff)

-> "Starting up the partitioner" -> Partition Disks: Manual

When you see the list of partitions, you will have to configure them manually.

You should note the small (50-100 Mb) boot partition that was previously created for use as the partition for the Grub chainloader files. In my example it is /dev/sda3. Make a note of what yours is named.

Configure the swap partition.

This shouldn't need configuring if you set it up properly with GParted.

You can make sure that Use as: swap area is set.

Configure the root partition for the OS. Choose one of your logical partitions, which in my scheme is #6, is ext3, and has about 30 Gb.

Use as: Ext3 journaling file system.

Format the partition: Yes, format it

Mount point: / - the root file system

Bootable flag: off

Note: You should write down which device this / (root) partition is on. You will need this information later for Grub settings. On mine, it is /dev/sda6.

In this step, Grub must be installed both on the MBR (master boot record) as well as locally on the partition being installed (in this example /dev/sda6). The local version will be chainloaded by the MBR version. Therefore, install Grub a second time:

This assumes your first installed OS has its / (root) directory in /dev/hda6 (as in my example above). Grub Legacy counts the first partition as 0, so sda6 becomes (hd0,5), or hard drive 1 (it starts counting at zero), partition 6). If you want to chainload a bootloader on a second hard drive, partition 4 (/dev/sdb4), you would specify (hd1,3), instead, for example.

(I also put it an entry for my second planned OS, even though I haven't installed it yet. That will save me time later. For more examples, see this section.)

Return the permissions so that only root can change or execute the files:

Use whichever device that corresponds to your / (root) directory for this OS, of course.

This ensures that the Grub bootloader is installed to this OS's partition, as well.

Finish installation and reboot. This system ought to be selected as the Second Ubuntu OS, obviously.

Note: Once you have booted into this OS, you can now edit the chainloaded GRUB bootloader's local settings for this OS (at /boot/grub/menu.lst or /etc/default/grub) as usual, as you can for the first installed OS as well.

Changing main Grub boot menu settings

You can edit the local (chainloaded) Grub boot menu for each Linux OS that uses Grub Legacy (within the partition in which it is installed), if desired:

sudo nano /boot/grub/menu.lst

(kate can be used instead of nano as the text editor in Kubuntu, or gedit instead of nano in Ubuntu.)

You can edit the local (chainloaded) Grub boot menu for each Linux OS that uses Grub2 (within the partition in which it is installed), if desired (see these instructions):

Grub starts counting from 0, so the first hard drive is number 0 and the first partition is also number 0. sda6 (which is hard drive 1, partition 6) becomes (hd0,5). If you want to chainload a bootloader on a second hard drive, partition 4 (/dev/sdb4), you would specify (hd1,3).

For (K)Ubuntu 10.04 or later, the menu item for chainloading should be (if the OS is in /dev/sda7):

Return the permissions so that only root can change or execute the files (optional):

sudo chmod 744 /media/GRUBpartition/boot/grub/menu.lst

Using UUIDs for the main Grub bootloader menu

Although newer bootloader configurations specify partitions using their UUID designation (instead of using the (hd0,x) designation), this is problematic for the primary Grub bootloader. In current OS installation paradigms, when an operating system is re-installed within a partition, the UUID of that partition is simultaneously changed by the installer. If the primary Grub bootloader were to reference a partition by its UUID instead of by its position on the drive, (i.e. (hd0,x)), the primary Grub bootloader would no longer be able to find the partition whenever a new operating system was installed within it (and its UUID simultaneously changed).

For this reason, the primary Grub bootloader in the /boot partition should always use the rootnoverify (hd0,x) (instead of UUIDs) nomenclature to identify partitions.

Add MacOSX entry

You can add a chainloader entry for a MAC OS that you might have installed on its own partition (installed with its own bootloader on the partition). Here's the entry for a MAC that is on partition /dev/sda9 (equivalent to (hd0,8):

title Mac OS X
root (hd0,8)
makeactive
chainloader +1

Re-installing Grub Legacy after Windows upgrade or re-installation

Windows installations, re-installations, and upgrades rewrite the Master Boot Record so that it points to the Windows bootloader only (instead of to the copy of Grub in the boot partition). The Master Boot Record must therefore be re-written so that it will again point to the copy of Grub stored in your boot partition.

For this example, assume the boot partition is the /dev/sda3 partition (which is known as (hd0,2) to Grub Legacy).

You must use a version of a LiveCD that has Grub Legacy, i.e. Kubuntu/Ubuntu 9.04 (Jaunty) or earlier. Start the LiveCD and start a command-line terminal (Terminal in Ubuntu or Konsole in Kubuntu). From the command-line terminal start grub:

sudo grub

Then enter the commands to restore the Master Boot Record to point to the boot partition at /dev/sda3:

> root (hd0,2)
> setup (hd0)
> quit

Then reboot. Your previously created Grub bootup-menu options should again appear.

Other chainloader options

In Grub Legacy it is possible to specify the root of the partition to be chainloaded using a UUID instead of the hd(0,x) notation. If you do not know the UUID for the partition to be chainloaded, it can be discovered using:

sudo blkid

Replace the

root (hd0,6)

entry in the /boot/grub/menu.lst file (of the primary /boot partition)

with

uuid xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

where xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx represents the actual UUID of the partition to be chainloaded.

Example:

Replace the lines (in the /boot/grub/menu.lst file)

root (hd0,9)
chainloader +1

with the lines

uuid xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
chainloader +1

This method works no matter which operating system is to be chainloaded. It will not work, however, for the operating system stored in (hd0,9) due to a quirk (see below).

Will it work for bootable devices (such as USB flashdrives) that have a UUID? I don't know -- I haven't tried it yet!

This next method will only work when the operating system in the chainloaded partition uses Grub Legacy (and has a local /boot/grub/menu.lst stored within the partition):

Chainloading Grub2 from Grub Legacy

Grub2 is erratic. I no longer chainload it. Instead, it is possible to bypass Grub2 entirely and load an OS directly using Grub Legacy (stored in a boot partition, for example) using an entry in menu.lst of the format:

My old method for chainloading Grub2 (installed in this example in the /dev/sda7 partition) from Grub Legacy used an entry in the Grub Legacy configuration file (/boot/grub/menu.lst, stored in the standalone boot partition with the Grub Legacy files) with this format:

The (hd0,9) problem

Grub Legacy has a quirk -- it does not like to chainload (hd0,9) using the command chainloader +1. (Something about 9 + 1 = 10 requiring an extra digit, or something.)

Most people don't have more than 2 or 3 operating systems on their computer so it is usually not an issue. Here at Ubuntuguide, however, we chainload as many as 10 different OS on every machine (not including virtual machines).

If the operating system in a chainloaded partition happens to use Grub Legacy (and therefore uses /boot/grub/menu.lst locally), the alternative to

chainloader +1

is to use the command

configfile (hd0,9)/boot/grub/menu.lst

(This can be used for any partition in which the chainloaded operating system uses Grub Legacy, not just (hd0,9). It will not work, however, if the chainloaded operating system uses Grub2.)

This can alternatively be specified as

rootnoverify (hd0,9)
/boot/grub/menu.lst

It is also possible to chainload by specifying the UUID for the chainloaded partition (hd0,9):

uuid xxxxx-xxxx-xxxx-xxxx-xxxxx
/boot/grub/menu.lst

Of course, you must find out the UUID for (hd0,9) first:

sudo blkid

Protecting Grub Legacy from cracking

Manipulating partitions on the hard drive

Most users that have multiple operating systems eventually choose to delete, resize, or re-arrange the partitions containing the operating systems. This can become an anxiety-producing task especially when it comes to ensuring subsequent bootup capabilities.

For techniques to accomplish this successfully (for systems that have been configured according to the guidelines above), see: