From JetResources
Jump to: navigation, search


JumpStart was developed by Sun Microsystems to enable Solaris systems to be installed - preferably without intervention. In Sun offices,most user desktops were Sun workstations, and the local IT departments needed some way of maintaining them. This meant building new systems as well as reprovisioning the OS to existing systems. When an office has over 1000 workstations to build, automation is key.

JumpStart was introduced along with Solaris 2, and provides a basic mechanism for getting the OS onto the system; it also provides a couple of hooks to allow system customisation, but the actual work of customisation is left up to the implementor.

Process Overview

The process of JumpStart (on SPARC) starts with the operator configuring the JumpStart server to respond to the various protocols involved and then initiating the actual JumpStart process from the target system.

Basic JumpStart

For a basic JumpStart, the JumpStart server will provide the mini-root boot environment and access to the media; this mimics the process of booting from a CD (or tape if you are old enough to remember), but without actually needing the physical media.

On the JumpStart server:

1. Insert the Solaris media (CDROM/DVD) assumed
2. Change directory into the media and under the 'Tools' directory, locate and run the 'setup_install_server' command
3. The installation media is copied to the local system
4. Change directory to the local copy of the media
5. From the 'Tools' directory in the local copy, run the 'add_install_client' command, providing:
   * Client name
   * IP address
   * Ethernet (MAC) address
   * CPU architecture

This populates the /etc/ethers and /etc/bootparams files and ensures that rpc.bootparamd and in.rarpd are now running. At this point, you can proceed to the client system and from the OpenBoot PROM, run the command:

ok boot net - install

The system should boot off the network and start running the Solaris Installation program, just as if you had booted off CDROM or DVD. This process is still interactive but if this doesn't work, then you need to fix things before trying to make things more complicated!

Intermediate JumpStart

The next level up from the basic JumpStart involves pre-answering the questions, so the OS installation can be performed non-interactively. This involves a bit more work from you (the operator) in advance.

On the JumpStart server create a configuration directory:

# mkdir /jumpstart
# share -F nfs -o ro,anon=0 /jumpstart

Into this directory, copy the following item from the Solaris media directory:

  • Misc/jumpstart_sample/check

Create the following files in your /jumpstart directory

  • rules
any any - profile -
  • profile
install_type  initial_install
system_type   standalone
partitioning  explicit
cluster       SUNWCXall
filesys       rootdisk.s0  free  /
filesys       rootdisk.s1  2048  swap
  • sysidcfg (N.B. the settings in this file change per Solaris release!)
network_interface=PRIMARY {protocol_ipv6=no}

Then you need to validate the rules file by running the script check that we copied from the jumpstart_sample area. Once this completes, re-run the add_install_client command, this time also specifying

  • location of the sysidcfg file
  • location of the rules file

So, for example

# add_install_client -i <target sys ip> -e <target sys mac> \
  -s \
  -c -p <target name> <target sys arch>

Once this is done, then you can restart your target system:

ok boot net - install

If you get everything right, then your target system should boot off the network and install Solaris.

Advanced JumpStart

To really make JumpStart useful, we need to do more than just install a basic vanilla image of Solaris to the system. We need our applications, settings, user accounts, etc, etc. The clue to how to do this lies in the rules file. With a small modification we can specify a script to be executed at the end of the Solaris installation:

any any - profile finish

All we need to do now, is re-run the check script and write our finish script. More on that later, but you can see the potential.


The FAQ has some entries for troubleshooting, but we'll cover the most obvious ones here.

  • ARP/RARP timeout : this can mean one of serveral things
    • You put the wrong MAC address into the add_install_client command. Check /etc/ethers against the target system and make sure you have the right values. If you need to edit /etc/ethers, then kill and restart in.rarpd
    • Your target system is not physically connected (on the same subnet) to the JumpStart server. If you know this is the case, then you need to look at the manuals for JumpStart Boot Servers or using DHCP for JumpStart. Basic JumpStart only works across the same subnet to which the JumpStart server is connected.
    • Your client has local-mac-address? set to TRUE in the boot prom and you got the MAC address from the banner command. If local-mac-address? is set to true, then each interface uses it's own MAC address and not the main one held in the Boot Prom. You can either set local-mac-address? back to false or strangely as it sounds, at the OBP prompt, cd to the network device you wish to boot from and run the .properties command to find the actual local mac address.
    • Lastly, you are connected to a switch (probably Cisco) that has spanning tree enabled on the port. Part of the spanning tree mechanism involves watching the port to see what's connected before passing packets. This means that for 30 seconds or so, the port acts as /dev/null and sinks all packets. Be patient young jedi - give it a minute or so before assuming it's broken!
  • ARP/RARP's stop, but system still doesn't boot : check /etc/bootparams and make sure that you have the right information in there. Pay particular attention to the IP address of the server from which the target system will get it's boot and media from. On multi-homed systems, sometimes add_install_client puts the wrong IP address here and the target system can't reach the right IP address so stops dead.
  • Basic System Identification questions asked : This means that you probably have either a typo in the 'sysidcfg' file or that the version of Solaris you are using needs more or less in the sysidcfg file than you supplied!
    • If you get asked all the questions, you have something in the file that this version of Solaris doesn't understand (or a typo), so it has ignored th e whole file
    • If you only get asked one or two questions, you have missed something from the file that this version of Solaris needs. You can normally narrow this down by checking the jumpstart_sample directory for examples and compare against your version.
    • But, if it can't find your sysidcfg file, then it will also go interactive - great!

Post Installation Configuration

So all we have to do is write a script to finish the configuration; that shouldn't be a problem..... Well, in the great scheme of things, we need to be aware of the environment that we are writing this script for. The script is run before the target system reboots, so

  • The root filesystem (/) is actually the NFS mounted miniroot from the JumpStart server, and is mounted read-only
  • The kernel, modules and general filesystem is a subset of Solaris, so not all the tools you want might be there
  • Our new root filesystem is mounted at a location defined by $ROOTDIR in the environment from which we are called (normally set to /a)
  • If we make a typo in the script, we need to repeat the whole installation to get to this point again - long debug cycles
  • If we need to run scripts after the first reboot, we need to schedule (rc script/svc) and manage them ourselves

In all, this is the point where System Administrators can fully see the power of JumpStart, but can also realise that it's going to take a while to write and test the scripts, which might actually be longer than it would take to install the systems by hand! The jumpstart_sample area has some simple scripts for setting root passwords etc, and there are many resources on the 'net that have example JumpStart code.


In essence, raw JumpStart is very powerful but at the same time, takes a time investment to reap the rewards. In small organisations, that investment might be too much to justify. In a large environment of 1000's of systems, it's easy to see why it is worth spending the time to get it right. Once you have a working system, it will grow - trust me!

--Marty 12:35, 22 January 2006 (GMT)