Multiple OS Installation

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 (or later) 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 serious flaw in the LiveCD installer of Karmic Koala and later (including Lucid Lynx). Use the Ubuntu Server edition instead (and then later add the ubuntu-desktop).

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).

Introduction

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.

Here is some info about this method:

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. Only versions of Ubuntu/Kubuntu 9.04 or earlier can be used for installing Grub Legacy to the boot partition, therefore.

The easiest way is to use an Ubuntu Server edition 9.04 LiveCD (which uses Grub Legacy) to install the first instance of Ubuntu Linux. 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 your new version of Ubuntu/Kubuntu to the same partition (overwriting the 9.04 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.

Now the Master Boot Record will use Grub Legacy (stored in the boot partition) merely as a chainloader to each subsequent partition, where that chosen partition's particular bootloader will then be run directly from the partition (no matter if it is a Windows bootloader, an Ubuntu bootloader, or a Mac 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.

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 I need it). If there is a Windows recovery partition already installed, I leave it alone (as my second partition).
one primary partition for the small boot partition (for storing a set of GRUB files)
an extended partition for the Linux OSs (must be the last partition on the hard drive)

In general I make:

my Windows partition 20 - 30 Gb -- filesystem type NTFS (or can even be FAT32) and with the boot flag checked
my "extra" partition 2 Gb -- which I tend to format as filesystem FAT32 (but can be anything, including ext3). If this is a Windows recovery partition, I leave it 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)
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. Anther 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.

For a re-installation, however, 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 NTSC by the Windows installer later), or it can be formatted (by GParted, for example) as an NTSC 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).

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 your first Linux OS

Read Using Grub Legacy for the boot partition to see why I recommend using Ubuntu Server edition 9.04 for this step.

Reboot into the Ubuntu 9.04 LiveCD (in my example I use the Ubuntu 9.04 Server edition 9.04 (Jaunty) LiveCD).

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.

-> Finish partitioning and write changes to disk -> "Installing the base system" -> ... ->

->"Install the Grub boot loader to the master boot record?": YES -> Continue

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:

-> Go Back -> Install the Grub boot loader on a hard disk -> "Install the Grub boot loader to the master boot record?": NO -> Device for boot loader installation: /dev/sda6 -> Continue

Copy boot files to the small Grub partition

Boot into your newly-installed Ubuntu 9.04 OS. Open a command-line terminal (if you have installed a desktop).

Make a new directory and mount it in your new Ubuntu OS.

sudo mkdir /media/GRUBpartition
sudo mount /dev/sda3 -t ext3 /media/GRUBpartition
sudo mkdir /media/GRUBpartition/boot
sudo mkdir /media/GRUBpartition/boot/grub

Note: Use whatever the device name of your small Grub partition is (mine is /dev/sda3)

Make sure there are full read/write write permissions (this step may be optional).

sudo chmod 777 /media/GRUBpartition/boot/grub

Copy all your grub files to the new partition

sudo cp -r /boot/grub/* /media/GRUBpartition/boot/grub

Edit the menu.lst

sudo nano /media/GRUBpartition/boot/grub/menu.lst

Place a chainloader entry as the first entry:

## ## End Default Options ##
title  First (K)ubuntu OS (chainloader)
rootnoverify	(hd0,5)
chainloader	+1

title Second (K)ubuntu OS (chainloader)
rootnoverify   (hd0,6)
chainloader    +1

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.)

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

sudo chmod 744 /media/GRUBpartition/boot/grub
sudo chmod 744 /media/GRUBpartition/boot/grub/*

Reinstall Grub to MBR

Now that the files are copied, we need to tell Grub Legacy to look for them there. Do this step from your Ubuntu 9.04 OS command-line terminal.

Start Grub Legacy:

sudo grub
grub> find /boot/grub/stage1

You should see the places there are grub configuration files.

(hd0,2)
(hd0,5)

Note that (hd0,2) corresponds to the small Grub partition (/dev/sda3), according to the counting method outline above. (hd0,5) corresponds to your first Linux OS (in the example /dev/sda6).

Make the small Grub partition the loadable Grub location.

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

Install your second Linux OS

Again I'm going to use (K)ubuntu for the example, although any OS can now be installed.

Reboot into an Ubuntu LiveCD (I recommend a Server edition, because some Desktop editions overwrite the Master Boot Record automatically, which is not at all desirable at this stage).

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.

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 #7, is ext4, and has about 30 Gb.

Use as: Ext4 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 the / (root) partition is on. You will need this information later for Grub settings. On mine, it is /dev/sda7.

-> Finish partitioning and write changes to disk. (It is OK to format the swap and / (root) partitions.) -> "Installing the base system" -> ... ->

"Installing Grub boot loader" ->

"Install the Grub boot loader to the master boot record?": NO

"Install the Grub boot loader on a hard disk": /dev/sda7

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) 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

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):

sudo nano /etc/default/grub
sudo update-grub

To change the main Grub boot menu, you will have to change the menu.lst found on the small Grub boot partition.

If you are doing this from a Linux OS other than the first one you installed, again make a new directory for mounting:

sudo mkdir /media/GRUBpartition

Mount the directory

sudo mount /dev/sda3 -t ext3 /media/GRUBpartition

Note: Use whatever the device name of your small Grub partition is (mine is /dev/sda3)

Make sure there are full read/write write permissions (this step may be optional).

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

Edit the menu.lst

sudo nano /media/GRUBpartition/boot/grub/menu.lst

Edit or add new chainloader entries:

## ## End Default Options ##
title  First (K)ubuntu OS (chainloader)
rootnoverify	(hd0,5)
chainloader	+1

title Second (K)ubuntu OS (chainloader)
rootnoverify   (hd0,6)
chainloader    +1

title Newest Whizbang OS on second hard drive, partition 4 (chainloader)
rootnoverify   (hd1, 3)
chainloader    +1

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).

Return the permissions so that only root can change or execute the files (this step may be 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/sda2:

> 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):

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

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

with the lines

uuid xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
configfile /boot/grub/menu.lst

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 Kubuntuguide, 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