Solaris Jumpstart, Part 2 - Profiles
Requirement #1: Standard Partitioning Scheme For All Servers
Setting up a jumpstart profile with a standard partitioning scheme is very trivial, when you have a small number of servers or all your servers have identical hardware. But this requirement presented me with a challenge. I support around 15-20 different models of Sun and Fujitsu (Sun clone) servers running Solaris 8, 9 and 10. The only thing they share in common is that every one of our Solaris servers, no matter its purpose, contains two internal disks of the same size, either 36, 73 or 147GB so that they may be mirrored together for redundancy. Some servers may even contain additional internal disks. Because of this, I wrote a Begin script that automatically generates a profile based upon the OS version and hardware detected. The Sun documentation calls these generated profiles derived profiles.
Because of the variety of hardware I support, there are many things to consider:
1. The root disk is not always c0t0d0.
Jumpstart will always select the rootdisk by picking the first disk to show up in a probe… c0t0d0 in this case. Thankfully I have never run into an instance where an alphanumeric sort of all detected cXtXdX devices did not show the correct rootdevice as first in the list.
2. On a system where you have more than two internal disks, which is the secondary (mirror) disk?
Consider this real-world example from one of my servers:
c0t0d0 - 73GB
c0t1d0 - 147GB
c1t0d0 - 73GB
c1t1d0 - 147GB
Which is the secondary disk, the one you want to mirror to? Jumpstart doesn’t know or care. To you and me, its obviously going to be c1t0d0. However, if all four of these devices were the same size, which would make the best choice of a mirror disk? Most people would agree that mirroring across controllers makes the most sense, so it’d still be c1t0d0.
The ability to configure disksuite (SVM) mirroring of the root disk in a jumpstart profile was introduced in Solaris 9. Prior to that the only way you could mirror the disks during the system build was with a script you would put at /etc/rc2.d/S99firstboot (or some such name) that ran the disksuite commands, updated vfstab and rebooted the system on the first boot. This works fine, but you still need to figure out which disk to mirror to.
The begin script takes care of this issue. It takes an inventory of all drives detected by the kernel via the ${SI_DISKLIST} and ${SI_DISKSIZES} variables.
The following order of logic is used to select a mirror disk:
- Is there only one disk of the same size besides the rootdevice? If so, select it.
- If there are multiple disks matching the size of the selected root device, do any of them have the same target number but different controller number? If so, that’s what we want.
- If there are multiple disks matching the size of the selected root device, but all the ones on other controllers have differing target numbers, pick the first one found on another controller.
- If the only disks matching the size of the root device are on the same controller as the root device, pick the first one from that same controller.
Note About Configuring Disk Mirroring via Profile vs Mirroring At First Boot:
With Solaris 8 builds, we have no choice but to partition the root disk and install the OS to it, saving the mirroring step until the first boot of the new system. With Solaris 9 and 10, we can set up the disk mirroring in the profile itself.
However, with Solaris 9, I have found that configuring mirroring at profile time rather than at first boot gives us a significant performance penalty when installing the OS. Installing Solaris 9 with all updated patches takes 4 hours when disk mirroring is configured in the profile. It takes only two hours when the mirroring is done at first boot. Solaris 10 is lightning fast (in comparison) with mirroring configured in the profile, so I have not had to try and get it to set up mirroring on first boot.
3. Which packages do you install?
Different versions of the OS contain different package cluster names, etc. Depending on the contents of the variable ${SI_OSNAME}, we write the appropriate package cluster list to the derived profile.
With all these items addressed, we can write out the profile!
Sample generated profile for Solaris 9:
install_type initial_install
system_type standalone
locale C
partitioning explicit
isa_bits 64
cluster SUNWCXall
filesys mirror:d0 c0t0d0s0 c0t1d0s0 15120 / logging
filesys mirror:d10 c0t0d0s1 c0t1d0s1 10240 swap
filesys c0t0d0s2 all overlap
filesys mirror:d30 c0t0d0s3 c0t1d0s3 10240 /opt logging
filesys mirror:d40 c0t0d0s4 c0t1d0s4 10240 /var logging
filesys c0t0d0s5 free
filesys c0t1d0s5 free
metadb c0t0d0s7
metadb c0t1d0s7
Tags: fujitsu, jumpstart, perl, solaris, solaris jumpstart, sun