Less Known Solaris features...

The concept of this further installations steps relies pretty much completly on the concept of a so called finish script. Do you remember the rules.ok file? There was a finish script specified in that file for all installations:

bash-3.2$ cat rules.ok
any any Utils/begin = Utils/finish
# version=2 checksum=3114


The installation of the Solaris Operating Environment is equal to the normal Jumpstart process, as it relies on the same functions. But then JET comes into the game. After the installation has completed, the script Utils/finish is executed. But where is this file. It´s relative to an directory we´ve specified before. Or to be exact, JET did that for is.
This is a snippet from the menu.lst for our system.

title Solaris_11 Jumpstart
kernel /I86PC.Solaris_11-1/platform/i86pc/kernel/unix - install nowin -
B install_config=192.168.10.1:/opt/SUNWjet,sysid_config=192.168.10.1:/opt/SUNWje
t/Clients/togusa,install_media=192.168.10.1:/export/install/media/solaris/x86/nv
87,install_boot=192.168.10.1:/export/install/media/solaris/x86/nv87/boot
module /I86PC.Solaris_11-1/x86.miniroot

The Utils/finish is relativ to install_config, thus the executed finish script 192.168.10.1:/opt/SUNWjet/Utils/finish. The NFS mount specified in install_config is one of the first mounts done on the new system and we can use the content of this directory throughout the installation process. By the way: This is the reason, why the rules.ok is located at this strange position.

We can study the further process in logfile of the installation. The complete log is located at /var/opt/sun/jet/ in the file jumpstart_install.log. Let´s start. At first the finish script starts to take copy some components from the Jumpstart server to the local disk.

Creating directory: /a/var/opt/sun/jet/post_install
Creating directory: /a/var/opt/sun/jet/Utils
Creating directory: /a/var/opt/sun/jet/config
Creating directory: /a/var/opt/sun/jet/js_media/patch
Creating directory: /a/var/opt/sun/jet/js_media/pkg
Copying file Clients/togusa/sysidcfg to /a/var/opt/sun/jet/config/sysidcfg
Copying file Clients/togusa/profile to /a/var/opt/sun/jet/config/profile
Copying file Clients/togusa/host.config to /a/var/opt/sun/jet/config/host.config
Copying file Utils/solaris/releaseinfo to /a/var/opt/sun/jet/config/releaseinfo
Copying functions to /a/var/opt/sun/jet/Utils/lib
Copying file Clients/togusa/module_hints to /a/var/opt/sun/jet/config/module_hints

As you you see, the JET copies over part of the toolkit as well as configuration files to the new position. But why are all those directories relative to /a. Well this is easy. In the netbooted mini root, the local disks are mounted relative to /a. The reasoning behind this copy is relatively simple. In the next boots the contents of /opt/SUNWjet/ aren´t available any longer, as the system doesn´t mount it in the next steps. The post installation scripts rely on some helper function. The simplest way to ensure their availability under all circumstances (even when your installation disables the network) is a simple copy.

The next step is the mounting of the directories with patches and product.

Mounting nfs://192.168.10.1/export/install/patches on /var/opt/sun/jet/js_media/patch
Mounting nfs://192.168.10.1/export/install/pkgs on /var/opt/sun/jet/js_media/pkg

Now it get´s a little bit complicated, but i will simplify it as far as i can. Depending on the complexity of the setup your configuration may use one or more so called products. A product in JET-speak is a JET module for the installation and configuration of a certain area of the operating system. In any case you will use the product base_config but there may be several ones. Our example uses the products base_config, custom, sds and jass. The JET framework gathers this information from the configuration template. It´s stored in this line:

base_config_products=" custom sbd sds jass"

The framework takes this information and to execute the install script in any of this directories. For example it starts at first the install script in /opt/SUNWjet/Products/base_config/solaris as this is default for every installation, after this it will step forward by executing the install script in any of the product directories. The install script has two important roles. At first it installs packages, patches and files according to the configuration in the templates. At second it registers so called post_install scripts.

Post installation scripts

post_install scripts are executed at the next boots. You can order this scripts by specifing a certain boot level. After the execution of all scripts in a boot level, the system reboots. For example all scripts with boot level 1 are executed after the first reboot, all post_install scripts with the boot level 2 are executed after the second reboot and so on. These scripts are installed in /var/opt/sun/jet/post_install

But how get this scripts to execution at the following reboots. JET copies a init.d script to the new system. On Solaris 10 it creates a matching SMF service. The function of this script is quite simple: Gather the actual boot level by reading the file /var/opt/sun/jet/post_install/Platform, execute all scripts in the boot level, increment the bootlevel by one and reboot the system.

An example for boot levels and postinstall scripts

We´ve done the first boot. It booted from the network. The installation of the Solaris Operating Environment succeeded, thus the script from the finish column is executed by the netbooted installation system. After some configuration tasks the system starts to register postinstall scripts.

SDS: Installing sds....
SDS: Copying file sds_functions to /a/var/opt/sun/jet/Utils/sds_functions
SDS: Creating directory: /a/var/opt/sun/jet/post_install/Platform/1
SDS: Register postinstall script 'create_fmthard' for boot 1
SDS: Register postinstall script 'set_boot_device' for boot 1
SDS: Register postinstall script 'create_metadb' for boot 1
SDS: Register postinstall script 'create_root_mirror' for boot 1
SDS: Register postinstall script 'attach_mirrors' for boot z
SDS: Register postinstall script 'create_user_devices' for boot 1
SDS: Register postinstall script 'attach_user_mirrors' for boot z
SDS: WARNING: unable to locate specified md.tab for SDS.
SDS: Enable md:mirrored_root_flag in /etc/system


You see, that the SDS product registered some scripts for boot level 1 and some for boot level z. Let´s look further into the installation log. This happens after the first reboot:

SDS: Running 001.sds.001.create_fmthard
fmthard: New volume table of contents now in place.
SDS: Running 001.sds.001.set_boot_device
SDS: Setting OBP nvramrc rootdisk path
[...]
SDS: Create 3 copies on c1d1s7
metadb: waiting on /etc/lvm/lock
SDS: Running 001.sds.003.create_root_mirror
SDS: Setting OBP nvramrc rootmirror path
[...]
SDS: Installing GRUB on Alternate Boot Disk.
SDS: Running 001.sds.007.create_user_devices


Later on you you will recognize the scripts for boot level z


Running additional install files for reboot z
SDS: Running 003.sds.001.attach_mirrors
SDS: Attach d12 to d10
SDS: Attach d22 to d20
SDS: Attach d12 to d10
d10: submirror d12 is attached
SDS: Attach d22 to d20
d20: submirror d22 is attached
SDS: Running 003.sds.002.attach_user_mirrors


With this mechanism, you can implement installation processes with package or programm installations that need several boots to fullfil.

The end of the post installation

At the very end the init.d script is deleted together with the matching SMF service. The logfiles and the post intallation scripts stay on the local disk.