After an obscenely long struggle I finally have both Solaris 10 and Solaris Nevada installed on my Ultra 20 workstation. As usual, since I have gone through the pain of getting it working, I'm explaining the process here to save others the trouble.
Installing these two friendly operating systems in a dual-boot configuration is not as simple as it may sound. The first thing you need to know is that Solaris doesn't like there to be more than one Solaris partition on a disk. The trick to installing two different versions of Solaris on the same disk is installing them both in the same partition. Because Solaris subdivides partitions into slices, it's possible to install Solaris 10 in one set of slices and Solaris Nevada is another set of slides. An advantage of this configuration is that some of the slices can be shared between both operating systems.
Here's my slice layout:
- Slice 0: Solaris 10 root
- Slice 1: Swap
- Slice 3: Solaris Nevada root
- Slice 6: /usr/local
- Slice 7: /export/home
Notice that only slices 1 and 3 are specific for an operating system. All of the rest of my slices are shared, including the swap space. Not only does this help conserve on disk space, but it also saves me from having to install two copies of everything. I use /usr/local as the repository for all my shared software. Note that /opt is not in a shared slice. The reason is that /opt is where software packages live, and software packages don't necessarily live only under /opt. I found it was less hassle to maintain two separate /opt directories than to try to coerce one instance of Solaris into recognizing software packages from another instance.
When Solaris 10 is loaded, slice 0 is mounted as /, and slice 3 is mounted as /s11. When Solaris Nevada is loaded, slice 0 is mounted as /s10, and slice 3 is mounted as /. By cross-mounting the root directories, I'm able to get even better sharing between operating systems. It also makes it very easy to do maintenance.
That was the easy part. The hard part was getting Solaris Nevada installed. When I installed Solaris 10 update 2, I laid out my slices more or less as I described above, with the assumption that at some point in the future I would install Solaris Nevada. When I eventually got around to trying it, I found I was unable to get past the install step where Solaris Nevada tried to lay out the disk and build its file systems. Apparently there was something about the partition that Solaris 10 update 2 had inherited from the previous install of Solaris 10 (no update) that was inherently bad. Unfortunately, at the time I didn't know that. Instead I went on banging my head against the problem intermittently for about 4 months. Finally, last week I decided to try to solve the problem by upgrading my Solaris 10 update 2 to update 3, in the hopes that an upgrade install would make something better. To make a long story short, I left my system in a state where starting over was my best option. During my fresh install of update 3, I used a terminal window to delete the previous Solaris partition, allowing the update 3 install to really start from scratch. After the install finished, I rebooted and tried Solaris Nevada build 61. I was much relieved to find that the Solaris Nevada install worked without a hitch. Unfortunately, after rebooting, there was a problem with the video driver which prevented the X console from running properly. In a last ditch effort, I pulled out my old build 55b DVD, and it installed and run fine. I'm writing with post from 55b.
Now, here's where the cross-linked roots come in handy. After installing Solaris Nevada, the Solaris Nevada boot loader was in charge, and it didn't know anything about Solaris 10. In order to make Solaris 10 bootable, I had to edit the /boot/grub/menu.lst file to add menu entries for Solaris 10. Essentially I copied the information from /s10/boot/grub/menu.lst into the file. According to the Solaris docs, there's a better way to do the same thing with the eeprom command, but it wasn't obvious to me how. An important part of adding the Solaris 10 boot information into the Solaris Nevada boot loader menu was the
root (hd0,0,a) line, which tells the boot loader to root the boot paths at slice 0 of partition 1 of disk 0. Don't forget to include that!
The last little bit of advice I can offer is about application paths. Because /export/home is shared, users' desktops will have the same path information associated with menus and icons under both operating systems. I used symbolic links to smooth over any differences in paths between the two operating systems. Also pay attention to the application paths associated with MIME types in your browsers. One other thing you have to watch is version issues with configuration files, particularly with GNOME. Since you're now using the same home directory for multiple desktop versions, you have the potential run into problems.