In an earlier article I suggested that it might be possible to have more than one Solaris instance on a system. There are several ways that this can be done, some more supported than others.

Let's start with the supported method - Live Upgrade. Live Upgrade is one of the most useful features in Solaris, and this is the recommended method of maintaining multiple Solaris instances. You get the benefit of being able to share all of your data across all of your OS instances and recovery from upgrades is simple. And did I mention that this is the only supported method ?

It is quite possible that this experiment will take us well outside the design parameters of Live Upgrade, so let's consider some other possibilities.

Platform virtualization software such as VMware would do the trick, but we've placed a constraint of zero cost, and I'm not ready to give up - not yet. The Xen Project shows tremendous promise, but is still early days in development. So let's keep looking.

What does Solaris really require ? A single primary disk partition. That's it. Well, not exactly - there is an additional requirement that it be the only Solaris partition (id=0xbf). I notice that in our disk layout we had 2 available partitions, so if we can play games with partition IDs then maybe we can make this work.

This is where the order of OS installation became important. One feature of GRUB as bootloader is the ability to change partition IDs dynamically. We will use this feature to hide one Solaris instance from the other one. Let's look at how this plays in with the installation process.

1. Install Windows XP from the vendor recovery discs. This creates one large partition with the Windows bootloader in the Master Boot Record (MBR) and in the boot sector of the first partition. At this point you don't may not notice the significance of this, but you will shortly.
   
2. Resize the single NTFS file system (and associated partition) and create the remaining partitions as listed in our table.
   
3. Install Solaris 10 3/05. Now we have the Solaris bootloader in the MBR and in the boot sector of the second primary partition. The Solaris bootloader supports chaining which allows you to boot both of the operating systems you have installed so far. It does not support chaining to a logical partition (in the extended partition) so this is as far as we will go with the Solaris 10 bootloader.
   
4. Install Fedora Core 4 (or the Linux distribution of your choice). Now we will have GRUB in the MBR as well as the boot sector for the Linux root partition, which is in the extended area. This is what lets us play with partition IDs so that you can fake out the Solaris installer to put your next OS instance in the proper place.
   
5. Install Software Express for Solaris in the remaining primary partition. This will put the newboot bootloader in the boot sector of our new Solaris partition but will leave the Linux GRUB in the MBR. This is exactly what we want (for the moment - we will look at how to make use of the OpenSolaris bootloader - but that's another article for a later day).

The last factor of this equation is the GRUB configuration file. This will be introduced in step 4, which will make step 5 possible. For our example configuration, the GRUB configuration file /boot/grub/menu.lst looks like

default=0
timeout=5
splashimage=(hd0,5)/boot/grub/splash.xpm.gz
hiddenmenu

title Fedora Core (2.6.11-1.1369_FC4)
	root (hd0,5)
	kernel /boot/vmlinuz-2.6.11-1.1369_FC4 ro root=LABEL=/ selinux=0
	initrd /boot/initrd-2.6.11-1.1369_FC4.img

title Solaris 10
	parttype (hd0,1) 0x83
	parttype (hd0,2) 0xbf
	root (hd0,2)
	makeactive
	chainloader +1

title Software Express for Solaris
	parttype (hd0,2) 0x83
	parttype (hd0,1) 0xbf
	root (hd0,1)
	makeactive
	chainloader +1

title Windows XP
	rootnoverify (hd0,0)
	chainloader +1

Let's take a closer look at one of the Solaris stanzas to see what's happening.

title Solaris 10
	parttype (hd0,1) 0x83

This sets the ID of the second partition, aka (hd0,1), /dev/hda2, /dev/dsk/c0d0p2) to 0x83 which is a Linux file system. Not only will the current Solaris instance ignore it, but all other operating systems will think that it is proper data and leave it alone. This turns out to be very important for a Linux installer that might misinterpret other partition IDs and do something unexpected, like destroy the data.

	parttype (hd0,2) 0xbf

This sets the ID of our partition to 0xbf which is the new Solaris partition ID. It is now the only one of type 0xbf, so we have met all of our requirements. Very cool!

	root (hd0,2)
	makeactive

These two actions make our partition the active IDE partition which may be required for some of the Solaris 10 boot process.

	chainloader +1

Jump to the bootloader in the boot sector of our partition.

You would expect the stanza for the other Solaris instance to be similar, just swapping partition IDs - and you would be correct.

Why go to all this trouble ? Updates, specifically Fedora Core. At this point we are done with the Windows and Solaris configurations, but not with Fedora. Each kernel update will come with at least three new GRUB stanzas (the uniprocessor kernel, a Xen Dom0 kernel, and a DomU paravirtualized kernel). The RPM post-install scripts will modify /boot/grub/menu.lst, so it is much easier if we make this our primary bootloader.

Enough for now. Next time we'll actually do the first Solaris 10 3/05 installation and look at some of the post-install tasks that will make it easier for the frugal road warrior.

Technocrati Tags: Laptop Solaris Linux Multiboot Bootloaders