To timidly go where many have gone before

A couple of times in the past, I've spent some time tracking down exactly what scripts/programs are called during Jumpstart and where certain bits of information are determined, but that information is scattered around on bits of paper, in email, and in files that I've lost track of.

Right now, what I'm looking for is how Jumpstart determines what disk to use when you specify "rootdisk" in a profile. For example if you have the following:

partitioning    explicit
filesys         rootdisk.s0      8192   /               logging
filesys         rootdisk.s1      8192   /var            logging
[ ... ]

Jumpstart will pick a disk to use as the root disk and then use that choice consistently through the rest of the process (via $SI_ROOTDISK.) (Or at least it's supposed to do so consistently. I just ran across this. I've never seen the problem, but apparently someone else has.)

The code for determining this is in the chkprobe script (e.g., /export/jumpstart/5.10-sparc-6_06/Solaris_10/Tools/Boot/usr/sbin/install.d/chkprobe.) This is what should happen in most cases:

        if [ -z "${SI_ROOTDISK}" ] ; then
                for i in /dev/dsk/*s0 ; do
                    SI_CDDEVICE=`basename ${i}`
                    findcd -t ${SI_CDDEVICE} > /dev/null 2>&1
                    if [ $? != 0 ] ; then
                        SI_ROOTDISK=${SI_CDDEVICE}
                        break;
                    fi
                done
        fi

Given the ordering presented by the glob, this essentially means that the lowest-numbered disk on the lowest-numbered target on the lowest-numbered controller will be used as the root disk. What's interesting is this bit of code before the above section:

        # see if there is a device c0t3d0s0
        if [ -z "${SI_ROOTDISK}" -a -b /dev/dsk/c0t3d0s0 ] ; then
            findcd -t c0t3d0s0 > /dev/null 2>&1
            if [ $? != 0 ] ; then
                SI_ROOTDISK=c0t3d0s0
            fi
        fi

So we have a special case for c0t3d0s0. I assume this was necessary back when Sun hardware would present SCSI target 0 as sd3 (for SunOS 4) or c0t3d0s0 (for Solaris.) I'd actually forgotten about that little quirk until I ran across this snippet of code.

Copyright notice from the above-mentioned chkprobe script:

# Copyright 2005 Sun Microsystems, Inc.  All rights reserved.
# Use is subject to license terms.