Multiple OS's and GRUB chainloading

I want to have multiple OS installations and I have been advised that chain loading using GRUB is a good way to handle this. I have looked at tutorials on the web but I still have some questions before I can start.

I want:

Windows XP: 20 GB. For running some school stuff and a game which does not work through WINE.
Xubuntu 9.04: 85 GB. My main OS.
Another Linux distribution: 15 GB . For experimenting and trying Linux distributions out.

I will:

Wipe and install various distributions quite often on the 15
Use dd to make a copy of my Windows partition after installing it and getting things to work as I like. My experience is that Windows needs to be re-installed maybe once per year to not get bloated and slow.

I have been told:

To use GRUB chain loading. It will make it easier when kernel upgrades are made in the Linux distributions, as they modify the GRUB boot-menu.

To my understanding I need to: (I might very well be mistaken)

Install Windows first.
Then install Xubuntu and let it write over the MBR with GRUB (I guess this is the default).
Get the GRUB on the MBR start Windows XP if I want to (it's done by default), start Xubuntu using the kernel of my choice or defer execution to the boot sector of my other Linux distribution. The actual chain loading will only occur when I want to start my experimental install of Linux.

I wonder:

Is step 3 above correct and a good way to handle this?
Is it also a good way to use chain-loading for both Xubuntu and my experimental Linux installation?
How do I get a Linux distribution to install the boot loader it comes with to the boot sector of its partition and not to the MBR?
If I can't get it to not touch the MBR. Then I could make a backup of the MBR using dd and then write it back after installing my experimental Linux installation. But then, how would I get the boot loader (lets say GRUB) into the boot sector of the experimental Linux installation? How would it work if said Linux installation gets a new kernel update and needs to update the GRUB menu?

Solution 1:

I have a similar issue with my new netbook. I have Windows, Ubuntu Netbook Remix, and another Linux OS on it. Because the first two don't change, but the third is likely to, I used these instructions to repair my GRUB.

Basically, lets assume that your Xubuntu is on the second partition on your hard drive (/dev/hda2 or (hd0,1)). The instructions from that link boil down to:

$>grub
grub>root (hd0,1)
grub>setup (hd0)
grup>quit

The only thing to keep in mind about this is that the GRUB will always refer to /boot/grub/menu.lst on your Xubunut partition. So whenever you change your Linux OS, you will need to look at its /boot/grub/menu.lst and copy the entry for itself into the one in Xubunut. Other than that, you should be fine.

Let me know if there is anything else you need or if there is anything that I could explain more clearly.

Solution 2:

Is step 3 above correct and a good way to handle this?

No, you should add an entry to xubuntu's menu.lst for the experimental linux distro.

Is it also a good way to use chain-loading for both Xubuntu and my experimental Linux installation?

As I said, no chainloading needed. That would just complicate things.

How do I get a Linux distribution to install the boot loader it comes with to the boot sector of its partition and not to the MBR?

You don't want this, you want it not to be installed at all. How you do this depends on the distribution of course.

If I can't get it to not touch the MBR. Then I could make a backup of the MBR using dd and then write it back after installing my experimental Linux installation. But then, how would I get the boot loader (lets say GRUB) into the boot sector of the experimental Linux installation? How would it work if said Linux installation gets a new kernel update and needs to update the GRUB menu?

Again, no need to backup the MBR. If something goes wrong, just reinstall grub from a live cd. zodoz explained that part well.

Solution 3:

General advise when messing with Grub: Build yourself a grub boot disk first. You can find an iso image in the Ubuntu package grub-rescue-pc and after installing that you can find the file in /usr/lib/grub-rescue/grub-rescue-cdrom.iso. Having such a disk handy saves a lot of time when the MBR gets messed up, which happens a lot when installing new OSs.

About the install itself, chainloading in step 3 isn't really needed, you could also just start the other OS from within the given grub, but that might require manually adding the boot entries instead of letting the OS generate them automatically (see /etc/grub.d/40_custom).

In general I wouldn't waste to much time planing ahead, when you have a grub boot disk ready its trivial to recover from a messed up MBR, just type:

  configfile (hd...)/boot/grub/grub.conf`

To let the Grub boot disk load the grub config file of your Linux, then boot into that and restore the MBR with grub-setup. Just play with different setups to find one that you like.

Solution 4:

In my experience, the best way to deal with this is letting your main linux os (Xubuntu) manage the grub. Don't install the grub when the other OS installs. Then after it installs, boot into Xubuntu and run sudo update-grub to make your other os appear in the list.

If you are using grub2 (grub-pc) install os-prober to let it handle the windows partition. You can Add your own configurations in /etc/grub.d/40_custom and not worry it will be changed.

Of course, you should always have a livecd at hand when some other os (*cough * windows * cough*) modifies the MBR when reinstalling.

Solution 5:

I leave Windows on its own drive, with the Windows bootloader in that MBR, but I have my BIOS boot the other drive (with all kinds of *NIX) first - it chainloads Windows. Because I altered the boot order in the BIOS, I also need to swap hd0 with hd1 in the grub config to chainload windows.

Edit: You might also consider a virtual machine for trying out other linux distros. Sun's VirtualBox has been working well for me. You'll need the disk space to hold all the extra images, though.