Multi-boot Recommendations and Suggestions

Preface: This presentation describes a complex multi-boot environment and attempts to point out many possible issues. If all that is desired is a multi-boot environment consisting of Windows and one Linux distribution then don't be intimidated by all the technical considerations. Most Linux distribution's default installation will handle this latter case without effort.


  1. Back up your existing OS and data, make sure you have installation media and licensing data (for commercial OSes) in case something goes wrong. Alternatively, use dd (with a Live Trial CD?).

  2. Check for partition space. You may have to repartition or resize to have room. Some distributions may be able to do this for you.

  3. Know (or set) the Administrative account's password on the existing OSes. You may need this for recovery.

  4. Know how to 'repair' the Master Boot Record (MBR) for the existing OS. If you decide later that you want to return to only that OS then you will need to use this procedure to overwrite the GRUB boot loader which will be installed below. See the “Other Problem Solving Ideas” section.

  5. Don't attempt this when you are not at peak performance (drowsy, in a hurry, distracted, etc.) You want to be thinking clearly and putting full focus on the process to avoid making mistakes.

  6. For each OS you want to multi-boot, become familiar with the installation process (practice elsewhere) to learn the options and issues. Making a mistake adding another OS after you have two or three OSes successfully multi-booting (easy to do) could have very time-consuming consequences.

  7. Create a GRUB boot diskette by following the instructions in 'info grub'. Also read about the following GRUB commands at minimum (it would be better to read all of 'info grub'): cat, geometry, find and root. If things go bad you may need to use these to find a bootable installation and boot to it manually. The general process is:


  1. Create a separate partition for /boot and have all Linux distributions boot from there – 100MB should be adequate for several distributions. Make this partition ext2 (“lowest common denominator” recognized by the most distributions) because a journal uses a lot of space. An alternative is for each install to have it's own /boot area but this method has it's own set of issues. What is known of those issues won't be covered here so you will have to discover and address them yourself.

  2. Decide what order to install the OSes. Windows, if desired, should probably be first since it doesn't even acknowledge non-MS OSes. If other non-Linux OSes are desired (Solaris, BSD or OS/2 for example), consider their capabilities carefully. Those with more limited multi-boot capabilities should probably be installed before Linux, articles on the Web recommended installing Solaris second if it was desired. For Linux, install the distributions in “oldest software” order. Generally this means earlier releases before later ones. However, for “contemporary” (roughly same time period) releases you should consider which uses the oldest variants of software. Formerly (and maybe still) SuSE tended to use older versions of software than Red Hat. The reason for this consideration is the suggestion above about a common /boot partition. The ext2 version on that partition needs to be recognized by all distributions. There have been situations where a later version of Fedora wass installed and then, attempting to install an earlier version of SuSE, there were errors about the version of ext2 on the /boot partition.

  3. Decide which distribution's GRUB you want to use. The reason for this (per 'info grub') is that grub's stage1 file is installed into the MBR and knows the location of the next stage by a block list. This forces the use of a particular 'next stage' file which is file system independent. From experience, different grub packages have some minor but significant differences. They don't recognize all of the others key words, particularly in regard to the splash menu. Deciding which GRUB variant you want to use decides what splash menu capabilities you have. Either install the desired variant first (via a GRUB boot diskette or careful choice of the first distribution to install) and don't allow subsequent installations to update the MBR or install it last.

  4. Boot to the first distribution's installation CD. Red Hat-based installations create an extended partition when forced to (number of partitions requested), the GUI doesn't have a way to manually do this. However, you can toggle to a terminal prompt (Ctrl-Alt-F2) and force the desired partitioning with either parted or fdisk (this may be another reason to install a SuSE distribution first). Also, there are some concerns about using fdisk (see man fdisk) particularly in earlier Linux versions. Unfortunately, earlier versions of parted were considered somewhat experimental. The man pages of earlier versions of Linux also expressed concern about the reliability of extended partitions as well. Do your research to see if there are any known fdisk problems with the distributions you are using. This is the reason for the following suggestions:

Complete the first installation. Considerations to take into account:

  1. (Assuming a single /boot) after each (Linux) install, create a <distribution-version> subdirectory under both /boot and /boot/grub. Copy all files in both of these directories to their respective <distribution-version> subdirectories. Change grub.conf/menu.lst to point to the new location. Reboot and test. The reason is that later installations will overwrite at least some of the files in the /boot partition without warning. Pay particular attention to saving the kernel, init and grub.conf files.

  2. Install the next Linux distribution following the suggestions given above for the first installation.

  3. Edit /boot/grub/grub.conf to merge the previous grub.conf with the current one. Generally this means simply appending the previous file's menu items to the current one and possibly changing the boot default. For some reason you may need to change the path references to be more fully qualified than they were previously. Be very careful doing the editing, a simple mistake here can put you into a non-bootable situation and having to resort to the GRUB diskette recovery.

Other problem solving ideas:

  1. Want to return to Windows only? Boot to the Linux distribution and use fdisk to make sure that the Windows partition is the one which is active (marked for boot). Boot to the Windows installation CD and, at least for Windows XP/server 2003, select the repair option which will start the recovery console. {For Windows 2000 see Microsoft Knowledgebase article Q229716 (the Recovery Console should be installed ahead of time). WARNING: For Windows NT, do your research, some references state that there is a Recovery Console or that later Windows OSes' Recovery Console will work on NT, still other references list using fdisk /mbr. It is not at all clear.} Select the path from the list (probably #1) and supply the administrator's password. Once at the command prompt type 'fixmbr' and respond with a 'y' (without the quotes) to the prompt. For older Windows it may be as simple as running 'fdisk /mbr'.

  2. Forgot to save a /boot partition file? Find it's RPM and copy it to the hard disk. Use Midnight Commander to drill into the RPM, select the file you need and copy it (using Midnight Commander) to the appropriate /boot location. If you have applied updates the safer way is to boot to rescue mode and reinstall grub or the package.

  3. Forgot to specify that strange mouse? At least in KDE Alt-F1 brings up the application menu. The Arrow keys, Tab, Shift-Tab and Enter work as expected. You can even emulate a pseudo-mouse by going into KDE's Control Panel, selecting Peripherals followed by Mouse, go to the Mouse Navigation tab and enable it. This allows you to enable Num-Lock and use the numeric key pad arrow keys to move the mouse pointer. The '5' key acts as a mouse click. Crude but adequate in a bad situation.

  4. Errors about multiple root (/) or /boot partitions You may get this error with a single drive (multiple partitions labeled “/”) or when a additional multi-boot drive is added to a system (there may well be multiples – one or more on each disk) along with a failure to mount the partition. The solution can be to refer to at least the /boot partition by it's UUID rather than it's label in fstab. Use dumpe2fs to determine the UUID. This solution is not available for the root partition because the kernel doesn't recognize UUID as a valid kernel parameter. In this situation the device reference will have to be used or the partition label (and references) changed. For reiserfs use debugreiserfs to view partition information and reiserfstune to set it. Another issue is that booting on the second drive may start fine but get errors because menu.lst was updated properly but fstab still has references to the drive as hda.


There are probably hundreds of thousands of documents on the Web about multi-booting various operating systems. Query for 'multiboot' and other parameters (such as 'Windows', 'Linux', “Solaris', etc.) to narrow down your results.