A GRUB Configuration for Multiple Solaris Instances
By user12611829 on Oct 13, 2005
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.
- 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.
- Resize the single NTFS file system (and associated partition) and create the remaining
partitions as listed in our
- 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.
- 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.
- 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 +1Let's take a closer look at one of the Solaris stanzas to see what's happening.
title Solaris 10 parttype (hd0,1) 0x83This 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) 0xbfThis 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) makeactiveThese two actions make our partition the active IDE partition which may be required for some of the Solaris 10 boot process.
chainloader +1Jump 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