Solaris Live Upgrade Inactive Boot Environment Compliance

When using Solaris Live Upgrade and creating a new boot environment, avoid problems by following these guidelines.

• Your package procedure scripts must be independent of the current active operating environment. Procedure scripts define actions that occur at particular points during package installation and removal. Four procedure scripts can be created with these predefined names: preinstall, postinstall, preremove, and postremove. Package procedure scripts must be independent of the currently active operating environment because an inactive boot environment could be switched by using Solaris Live Upgrade.

  • These scripts must not start or stop any processes or depend on the output of commands such as ps or truss, which are operating-system dependent and report information about the currently running system.

  • Procedure scripts are free to use other standard UNIX commands such as expr, cp, and ls and other commands that facilitate shell scripting. But, the inactive boot environment must not be modified except within the rules outlined in the section, Custom JumpStart Program and Solaris Live Upgrade Inactive Boot Environment Requirements.

  • All scripts must be written in Bourne shell (/bin/sh). Bourne shell is the interpreter used by the pkgadd command to execute the procedure scripts.

  • Package procedure scripts must not invoke commands that were added in the 2.6 and later releases. For example, package procedure scripts cannot invoke the pgrep command. Since the 2.6 release, many commands have had additional features added. Package procedure scripts must not use any command options that did not exist in the 2.6 release. For example, the -f option of the umount command was added in the Solaris 7 release. To verify that a specific command or option is supported in the Solaris 2.6 release, see the Solaris 2.6 Reference Manual AnswerBook on http://docs.sun.com.

• All packages must pass pkgchk validation. After a package is created and before it is installed, it must be checked with the following command.

  # pkgchk -d dir_name pkg_name

  dir_name

  Specifies the name of the directory where the package resides

  pkg_name

  Specifies the name of the package

  For example, if a package exists at /export/SUNWvxvm, then you would issue the following command.

  # pkgchk -d /export SUNWvxvm

  No errors should be displayed.

  After a package is created, it must be tested by installing it in an inactive boot environment location using the -R dir_name option to pkgadd. After the package is installed, it must be checked for correctness using pkgchk, as in this example.

  # pkgadd -d . -R /a SUNWvxvm # pkgchk -R /a SUNWvxvm

  No errors should be displayed.

• Also, packages must not execute commands delivered by the package itself. This is to maintain diskless compatibility and avoids running commands that might require shared libraries that are not installed yet.

These requirements for creating, modifying, and deleting files can be verified using a variety of commands. For example, the dircmp or fssnap commands can be used to verify that packages behave properly. Also, the ps command can be used for testing daemon compliance by making sure daemons are not stopped or started by the package. The truss, pkgadd -v, and pkgrm commands can test runtime package installation compliance, but might not work in all situations. In the following example, the truss command strips out all read-only, non-$TEMPDIR access and shows only non-read-only access to paths that do not lie within the specified inactive boot environment.

# TEMPDIR=/a; export TEMPDIR
# truss -t open /usr/sbin/pkgadd -R ${TEMPDIR} SUNWvxvm \
2>&1 > /dev/null | grep -v O_RDONLY | grep -v \
'open("'${TEMPDIR}

For detailed information on the commands referenced in this section, see the man pages dircmp(1), fssnap(1M), ps(1), truss(1), pkgadd(1M), pkgchk(1M), or pkgrm(1M).