Less Known Solaris features: Jumpstart Enterprise Toolkit - Part 13: Deep dive to post installation

As i told you before much of the configuration takes place after the installation executed by the orignal Jumpstart mechanism. We used several modules of the JET toolkit so far, thus this is a good moment to do a deep dive into the process that takes place after the normal Jumpstart installation.
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<br />
any any                 Utils/begin     =       Utils/finish<br />
# version=2 checksum=3114<br />

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<br />
        kernel /I86PC.Solaris_11-1/platform/i86pc/kernel/unix  - install nowin -<br />
B install_config=,sysid_config=<br />
t/Clients/togusa,install_media=<br />
87,install_boot=<br />
        module /I86PC.Solaris_11-1/x86.miniroot

The Utils/finish is relativ to install_config, thus the executed finish script 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<br />
Creating directory: /a/var/opt/sun/jet/Utils<br />
Creating directory: /a/var/opt/sun/jet/config<br />
Creating directory: /a/var/opt/sun/jet/js_media/patch<br />
Creating directory: /a/var/opt/sun/jet/js_media/pkg<br />
Copying file Clients/togusa/sysidcfg to /a/var/opt/sun/jet/config/sysidcfg<br />
Copying file Clients/togusa/profile to /a/var/opt/sun/jet/config/profile<br />
Copying file Clients/togusa/host.config to /a/var/opt/sun/jet/config/host.config<br />
Copying file Utils/solaris/releaseinfo to /a/var/opt/sun/jet/config/releaseinfo<br />
Copying functions to /a/var/opt/sun/jet/Utils/lib<br />
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:// on /var/opt/sun/jet/js_media/patch<br />
Mounting nfs:// 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....<br />
SDS: Copying file sds_functions to /a/var/opt/sun/jet/Utils/sds_functions<br />
SDS: Creating directory: /a/var/opt/sun/jet/post_install/Platform/1<br />
SDS: Register postinstall script 'create_fmthard' for boot 1<br />
SDS: Register postinstall script 'set_boot_device' for boot 1<br />
SDS: Register postinstall script 'create_metadb' for boot 1<br />
SDS: Register postinstall script 'create_root_mirror' for boot 1<br />
SDS: Register postinstall script 'attach_mirrors' for boot z<br />
SDS: Register postinstall script 'create_user_devices' for boot 1<br />
SDS: Register postinstall script 'attach_user_mirrors' for boot z<br />
SDS: WARNING: unable to locate specified md.tab for SDS.<br />
SDS: Enable md:mirrored_root_flag in /etc/system<br />

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

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

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

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.