 Dual Booting SPARC SolarisTM
Kelley Shaw
The concept of dual-boot configurations for computers
has been around for quite some time, and one major benefit of multi-boot
configurations is that they allow you to test and use different operating
systems without requiring separate, dedicated computers.
In the world of SPARC Solaris, a common multi-boot
configuration includes two or more different versions of Solaris, rather
than two or more unrelated operating systems. Configuring multi-boot setups
for Solaris on SPARC systems is simple compared to x86/x64 multi-boot
configurations. There are no special requirements -- you use only
Solaris installation tools that you are probably already familiar with. You
don't have to decide which boot loader to use, you don't have
to worry whether the boot loader will be able to find your second OS, and
you don't have to spend time figuring out which OS should be loaded
first (it doesn't matter). So, if you've successfully
implemented any dual-boot configuration on an x86/x64 system, configuring
dual-boot on a SPARC system will be a breeze.
There are several scenarios in which a SPARC Solaris
multi-boot configuration could be of benefit. For example, you may have an
application that you developed that works under Solaris 2.6, but you want
to upgrade to Solaris 8. Before committing yourself, you want to test your
code under Solaris 8. If you don't have an extra SPARC system
available, you could configure your system to dual boot between Solaris 2.6
and Solaris 8, while sharing your application code directories between the
two Solaris versions. Or, you may be a Solaris consultant working from home
with only one SPARC system. You may have clients who use Solaris 2.6, other
clients who use Solaris 9, and yet others who use Solaris 10. With a
triple-boot configuration in place, you can simply boot to the appropriate
version of Solaris depending on which client you are assisting at the
moment.
In this article, I'll present two examples for
configuring SPARC Solaris dual-boot environments. I'll also address
post-installation issues, including how to share directories, files, and
accounts between the two Solaris versions. And, I'll present a shell
script that automates the process of switching from one version of Solaris
to the other.
Summary of Hardware/Software Used in Examples
In the examples presented here, I used a SunBlade 150
with two 20-GB internal disks and 640MB of RAM. The examples use Solaris 8
and Solaris 10, but you can use any versions of Solaris that are supported
by your SPARC hardware.
Scenario 1: Install Both Solaris 8 and Solaris 10 on Disk 1
In this scenario, we'll install both versions of
Solaris on a single disk. Each Solaris version will have its own root file
system (/) and its own /var file system. Solaris 8 will occupy Slices 0 and
3, and Solaris 10 will occupy Slices 4 and 5. Slice 1 (swap) will be
"reused" by each Solaris version. Additionally, Slices 6 and 7
will be used for data file systems shared between the two versions of
Solaris (/export/home and /scratch). This scenario is very efficient
because it requires only one disk and both versions of Solaris share the
same area on the disk for swap. In this scenario, a second disk could be
utilized for mirroring the boot disk or for backup purposes.
To begin, perform an "initial" install of
Solaris 8 as you normally would. (It does not matter which Solaris version
is installed first. If you already have an instance of Solaris installed
that you want to preserve, and you also have available partitions for a
second instance of Solaris, leave the existing Solaris instance in place
and proceed with installing the "second" Solaris instance.)
When asked to lay out file systems, select
"Manual Layout" and then "Customize". Lay out the
file systems on Disk 1 according to your preferences. Figure 1 shows how I
configured my partitions for Solaris 8 on the primary disk (c0t0d0).
Make sure you leave enough free space so that you will
be able to install Solaris 10 later -- I left 7697 MB free. The sizes
specified in Figure 1 are examples only. Set the partition sizes according
to your own situation. Complete the Solaris 8 installation, ignoring any
messages about unused disk space on Disk 1.
One side effect of the Solaris installation process is
that the NVRAM parameter "boot-device" will be set so that the
system will automatically boot into the newly installed Solaris instance.
Note the value of this parameter so that you can define an NVRAM alias for
it later. You can find the value of "boot-device" in two ways.
If you are logged into your newly installed instance of Solaris 8, issue
the following command in a terminal window at the shell prompt:
# eeprom boot-device
boot-device=disk:a disk net
If you are at the OBP (ok prompt):
ok printenv boot-device
boot-device = disk:a disk net
Notice that the value of "boot-device" is
actually a list of boot devices. At boot time, the system will attempt to
boot each device in the list, in the order listed, until a valid boot
device is found. In this particular example, "disk" and
"net" refer to predefined NVRAM aliases. This will be discussed
in more detail later in this scenario.
Shut down your system and perform the Solaris 10
installation. It is up to you to determine whether your second Solaris
instance will use the same identity information (i.e., hostname, IP
address) as the original instance. Since you will only be able to boot one
instance at a time, there will be no conflicts if you use the same identity
information. When prompted, select "Initial Install" (as
opposed to "Upgrade Install"). Specify "Custom
Install" so that you can manually configure the file systems. Select
the same disk you used for the Solaris 8 instance. When asked if you want
to preserve existing data, answer in the affirmative. Preserve and rename
Slices 0 and 3 and simply preserve (do not rename) Slices 1, 6, and 7.
Figure 2 shows the Solaris 10 "Specify Data To Preserve" window
to illustrate how I preserved and renamed slices.
Notice that I renamed the mount point for Slice 0 from
"/" to "/root.sol8", and I renamed the mount point
for Slice 3 from "/var" to "/var.sol8". You can
select any names for these mountpoints that are meaningful to you. When you
proceed to the next window, you can lay out your new partitions for Solaris
10. Slices 4 and 5 are the only unused slices on the primary disk and so
are the only slices you will be allowed to modify. The Solaris 10
installation provides default mountpoints and sizes for the unused
partitions (see Figure 3).
In this particular case, the default values that the
Solaris 10 installation program provided for Slices 4 and 5 are almost
right for my purposes, with the exception that I want to rename the mount
point for Slice 5 to /var. Figure 4 shows how I configured Slices 4 and 5.
Complete the Solaris 10 installation. In the same way
that installing Solaris 8 caused the NVRAM parameter
"boot-device" to be set so that your system booted from Slice 0
of the primary disk, the Solaris 10 installation will modify
"boot-device" so that your system attempts to boot from Slice 4
of the primary disk first. On my system, the value of
"boot-device" after the Solaris 10 installation is:
# eeprom boot-device
boot-device=/pci@1f,0/ide@d/disk@0,0:e disk:a disk net
Notice that "pci@1f,0/ide@d/disk@0,0:e"
was prepended to the previous value of "boot-device". The
Solaris 10 installation program uses an explicit hardware device path
rather than an alias to specify the boot device.
To make the process of switching from one Solaris
version to the other a bit more self-explanatory, it is convenient to
create an NVRAM alias for each Solaris instance. To define our aliases, we
need to know the explicit hardware path of the disk used to install the
Solaris instances. We can figure that out by looking at the current value
of "boot-device". We know that the hardware path to our disk is
"/pci@1f,0/ide@d/disk@0,0". The ":e" refers to
Slice 4 of the disk.
Let's create our aliases. Go to the OpenBoot
PROM (ok prompt) either by shutting down your system (init 0) or pressing
STOP-A. There is no "cut and paste" in the OBP, and manually
typing out long hardware paths can be error prone. Fortunately, we can use
a shortcut provided by the OBP by issuing the show-disks command:
ok show-disks
a) /pci1f,0/ide@d/cdrom
b) /pci1f,0/ide@d/disk
q) NO SELECTION
Enter Selection, q to quit:
The menu presented by the show-disks command lists
"incomplete" hardware paths that can serve as starting points
for explicit hardware paths. Note that hardware paths will vary greatly by
architecture. The results of the show-disks command on your system may look
very different. On my system, if I select "b" at the menu,
I'll see the following message:
/pci@1f,0/ide@d/disk has been selected.
Type ^Y (Control-Y) to insert it in the command line.
e.g. ok nvalias mydev ^Y
for create devalias mydev for
/pci@1f,0/ide@d/disk
So now, I can create the 'sol10' alias:
ok nvalias sol10 ^Y
which results in:
ok nvalias sol10 /pci@1f,0/ide@d/disk
Now I need to add the remainder of the hardware path.
From looking at the value of "boot-device" above, I know I need
to add "@0,0:e":
ok nvalias sol10 /pci@1f,0/ide@d/disk@0,0:e
Do the same thing to create a 'sol8'
alias, but this time, add "@0,0:a" to the path returned by
"show-disks" because the Solaris 8 root file system is located
on Slice 0. Next, set the "boot-device" NVRAM parameter so that
the system will attempt to boot first from whichever Solaris version you
consider the "default". If Solaris 8 is the default, then:
ok setenv boot-device sol8 sol10 net
When the system is booted without interruption,
Solaris 8 will boot. If you want to boot Solaris 10, you can enter STOP-A
during boot (or "init 0" if the system is up and running) and
then enter the following command at the ok prompt:
ok boot sol10
If you prefer to select the Solaris version every time
you boot, set the "auto-boot?" NVRAM parameter to
"false". This will cause the ok prompt to appear every time you
boot:
ok setenv auto-boot? false
Now, when you boot your system and the ok prompt
appears, enter either "boot sol8" or "boot sol10".
You can also write scripts that run at the OS level to
switch from one Solaris environment to the other. See "Switching
Scripts" in the "Post-Installation Details" below for
more information.
Scenario 2: Install Solaris 8 on Disk 1 and Solaris 10 on Disk 2
Using the same basic procedure as presented in
Scenario 1, you could alternatively lay out your system so that one Solaris
instance is installed on Disk 1 and the other Solaris instance is installed
on Disk 2. In this case, you can choose which disk you want to hold each of
the shared file systems (such as /export/home or scratch areas). On my
system, this layout is a good choice because my disks are only 20GB and I
like to build in a bit of breathing room for my file systems. Also, I
prefer to break out /opt and /usr from my root file system. However, in
this scenario, I won't have an "extra" disk for mirroring
or backup purposes.
For the Solaris 8 installation, I select my primary
disk (c0t0d0) and lay it out as shown in Figure 5.
For the Solaris 10 installation, I select my second
disk (c0t2d0) and lay it out as shown in Figure 6 (ignoring the first
disk).
As in Scenario 1, set the NVRAM device aliases for
"sol8" and "sol10" to reference the correct disk
slices. The "sol8" alias will reference Slice 0 (or
"a") on Disk 1, and the "sol10" alias will
reference Slice 0 (or "a") on Disk 2. For example:
ok nvalias sol8 /pci@1f,0/ide@d/disk@0,0:a
ok nvalias sol10 /pci@1f,0/ide@d/disk@2,0:a
ok setenv boot-device sol8 sol10 net
Post-Installation Details
Once you have successfully installed multiple versions
of Solaris on your system, there are some post-installation issues to
consider. For example, how can you avoid confusion as to which version of
Solaris you are currently booted into? You will tire quickly of entering uname -a over and over. How will you share system configuration changes
between the multiple Solaris versions? How will you switch from one
instance of Solaris to the other? In this section, I'll present some
ideas that address these questions.
Command-Line Prompt
It may be confusing to end users (i.e., you!) as to
which environment they are in. You can add several lines to the global
initialization files to help clarify things. For example, the following
lines in /etc/profile will set the command prompt to clarify to users
(including "root") which Solaris environment they are working
in:
OSVER='uname -r'
if [ '/usr/ucb/whoami' = 'root' ]
then
PS1="'hostname' $OSVER# "
else
PS1="'hostname' $OSVER>> "
fi
export PS1
Now, if a user logs into the Solaris 8 environment,
his prompt would appear as follows:
mysys 5.8 >>
Alternatively, if a user logs into the Solaris 10
environment, his prompt would be:
mysys 5.10 >>
The prompt for "root" will be:
mysys 5.8#
or
mysys 5.10#
User Initialization Scripts
In both of the dual-boot examples presented in this
article, Solaris 8 and Solaris 10 share the same home directories. Each
user has initialization scripts (i.e., .profile/.kshrc, .login/.cshrc) in
his or her home directory that are executed at login. The exact same
initialization scripts will be executed regardless of which Solaris
environment they log into.
Users can modify these initializations scripts to
include logic that checks for the current Solaris version. They can then
address subtleties between the two Solaris versions. For example, in
Solaris 10, the df command can be used with the -h flag to make the output
of df more "human readable". However, Solaris 8 does not
recognize the -h flag. So a user could create an alias for df that uses an
appropriate flag, depending on the Solaris version. Consider the following
.kshrc file:
mysys 5.10>> more .kshrc
if [ 'uname -r' = "5.10" ]
then
alias df="df -h"
else
alias df="df -k"
fi
In this .kshrc file, the result of the uname -r command is checked to determine how to set an appropriate alias for the df command. You can also use initialization scripts to appropriately set
environmental variables, such as $PATH and $LD_LIBRARY_PATH, based on the
currently booted Solaris version.
Common System Files
In multi-boot configurations, it is convenient to
"share" certain system files between the different Solaris
versions. For example, you may want to ensure that any user accounts that
are created/modified under one Solaris instance are also created/modified
on the other Solaris instance. When you create or modify a user account in
Solaris, several system files are affected including /etc/passwd and
/etc/shadow.
One approach to duplicate account information between
the Solaris instances is to copy modified files from the current Solaris
instance to the other Solaris instance. You can mount the
"other" Solaris version's root file system and copy over
the appropriate files. Then, when you boot into the "other"
version, the account modifications are already in place. For example,
mysys 5.10# useradd -u 501 -s /usr/bin/ksh -d /export/home/derek -m derek
mysys 5.10# passwd derek
New Password:
Re-enter new Password:
passwd: password successfully changed for derek
mysys 5.10# mount /dev/dsk/c0t0d0s0 /root.sol8
mysys 5.10# cp /etc/shadow /root.sol8/etc/shadow
mysys 5.10# cp /etc/passwd /root.sol8/etc/passwd
Similarly, /etc/auto_master, /etc/auto_home, etc., can
be shared. Any system files that can be shared between the Solaris versions
can be copied in the same way. Obviously, the use of name services on your
network, such as NIS or LDAP, would eliminate the need for some of these
file duplication tasks.
One note of caution: Do not directly share system
files that contain "instance-dependent" information. For
example, the /etc/vfstab file would not be a good file to blindly copy from
one instance to the other. In this case, you might want to write a script
that extracts the lines from /etc/vfstab that you want to share rather than
copying the entire file.
"Switching" Scripts
Copying system configuration files from one Solaris
instance to the other can quickly become cumbersome and unmanageable.
Carefully written scripts can help solve this issue, as well as automate
switching from one Solaris version to the other. For example, Listing 1
shows a script designed to switch from Solaris 8 to Solaris 10, or vice
versa. But first, it prompts the user to copy common files from the current
environment to the "other" Solaris environment. See the
embedded comments for detailed information.
Summary
Configuring a Solaris SPARC multi-boot environment is
as easy as installing Solaris multiple times. It does not require any
special tools or knowledge -- if you know how to install a single
instance of Solaris, you are 95% of the way there. The remaining 5%
involves careful planning of how you will lay out your file systems and
determining how files and file systems will be shared between the various
instances, if desired. The payoff is the ability to easily access multiple
versions of SPARC Solaris without dedicating a separate computer to each
instance.
Kelley Shaw is a Systems Engineer at Commercial Data
Systems, a specialized system integrator with unique solutions in the areas
of multi-level security and diskless boot. Kelley has 20 years of hands-on
Unix administration experience and also teaches Solaris System
Administration classes. Kelley can be reached at kshaw@cdsinc.com.
|