JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris 10 9/10 Installation Guide: Solaris Live Upgrade and Upgrade Planning
search filter icon
search icon

Document Information

Preface

Part I Upgrading With Solaris Live Upgrade

1.  Where to Find Solaris Installation Planning Information

2.  Solaris Live Upgrade (Overview)

3.  Solaris Live Upgrade (Planning)

4.  Using Solaris Live Upgrade to Create a Boot Environment (Tasks)

5.  Upgrading With Solaris Live Upgrade (Tasks)

6.  Failure Recovery: Falling Back to the Original Boot Environment (Tasks)

7.  Maintaining Solaris Live Upgrade Boot Environments (Tasks)

8.  Upgrading the Solaris OS on a System With Non-Global Zones Installed

9.  Solaris Live Upgrade (Examples)

10.  Solaris Live Upgrade (Command Reference)

Part II Upgrading and Migrating With Solaris Live Upgrade to a ZFS Root Pool

11.  Solaris Live Upgrade and ZFS (Overview)

12.  Solaris Live Upgrade for ZFS (Planning)

13.  Creating a Boot Environment for ZFS Root Pools

14.  Solaris Live Upgrade For ZFS With Non-Global Zones Installed

Part III Appendices

A.  Troubleshooting (Tasks)

B.  Additional SVR4 Packaging Requirements (Reference)

Preventing Modification of the Current OS

Using Absolute Paths

Using the pkgadd -R Command

Differences Between $PKG_INSTALL_ROOT and $BASEDIR Overview

Guidelines for Writing Scripts

Maintaining Diskless Client Compatibility

Verifying Packages

Preventing User Interaction When Installing or Upgrading

Setting Package Parameters For Zones

For Background Information

C.  Using the Patch Analyzer When Upgrading (Tasks)

Glossary

Index

Preventing Modification of the Current OS

Following the requirements in this section keeps the currently running OS unaltered.

Using Absolute Paths

For an installation of an operating system to be successful, packages must recognize and correctly respect alternate root (/) file systems, such as a Solaris Live Upgrade inactive boot environment.

Packages can include absolute paths in their pkgmap file (package map). If these files exist, they are written relative to the -R option of the pkgadd command. Packages that contain both absolute and relative (relocatable) paths can be installed to an alternative root (/) file system as well. $PKG_INSTALL_ROOT is prepended to both absolute and relocatable files so all paths are resolved properly when being installed by pkgadd.

Using the pkgadd -R Command

Packages being installed by using the pkgadd -R option or being removed using the pkgrm -R option must not alter the currently running system. This feature is used by custom JumpStart, Solaris Live Upgrade, non-global zones and diskless client.

Any procedure scripts that are included in the packages being installed with the pkgadd command -R option or being removed by using the pkgrm command -R option must not alter the currently running system. Any installation scripts that you provide must reference any directory or file that is prefixed with the $PKG_INSTALL_ROOT variable. The package must write all directories and files with the $PKG_INSTALL_ROOT prefix. The package must not remove directories without a $PKG_INSTALL_ROOT prefix.

Table B-1 provides examples of script syntax.

Table B-1 Examples of Installation Script Syntax

Script Type
Correct Syntax
Incorrect Syntax
Bourne shell “if” statement fragments
if [ -f ${PKG_INSTALL_ROOT}\
/etc/myproduct.conf ] ; then
if [ -f /etc/myproduct.conf ] ; \
 then
Removing a file
/bin/rm -f ${PKG_INSTALL_ROOT}\
/etc/myproduct.conf
/bin/rm -f /etc/myproduct.conf 
Changing a file
echo "test=no" > ${PKG_INSTALL_ROOT}\
/etc/myproduct.conf
echo "test=no" > \
/etc/myproduct.conf

Differences Between $PKG_INSTALL_ROOT and $BASEDIR Overview

$PKG_INSTALL_ROOT is the location of the root (/) file system of the machine to which you are adding the package. The location is set to the -R argument of the pkgadd command. For example, if the following command is invoked, then $PKG_INSTALL_ROOT becomes /a during the installation of the package.

# pkgadd -R /a SUNWvxvm

$BASEDIR points to the relocatable base directory into which relocatable package objects are installed. Only relocatable objects are installed here. Nonrelocatable objects (those that have absolute paths in the pkgmap file) are always installed relative to the inactive boot environment, but not relative to the $BASEDIR in effect. If a package has no relocatable objects, then the package is said to be an absolute package (or nonrelocatable), and $BASEDIR is undefined and not available to package procedure scripts.

For example, suppose a package's pkgmap file has two entries:

1 f none sbin/ls 0555 root sys 3541 12322 1002918510
1 f none /sbin/ls2 0555 root sys 3541 12322 2342423332

The pkginfo file has a specification for $BASEDIR:

BASEDIR=/opt

If this package is installed with the following command, then ls is installed in /a/opt/sbin/ls, but ls2 is installed as /a/sbin/ls2.

# pkgadd -R /a SUNWtest

Guidelines for Writing Scripts

Your package procedure scripts must be independent of the currently running OS to prevent modifying the OS. 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.

Table B-2 Guidelines For Creating Scripts

Guidelines
Affects Solaris Live Upgrade
Affects non-global zones
Scripts must be written in Bourne shell (/bin/sh). Bourne shell is the interpreter that is used by the pkgadd command to execute the procedure scripts.
X
X
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.
X
X
Scripts are free to use other standard UNIX commands such as expr, cp, and ls and other commands that facilitate shell scripting.
X
X
Any commands that a script invokes must be available in all supported releases, since a package must run on all of those releases. Therefore, you cannot use commands that were added or removed after the Solaris 8 release.

To verify that a specific command or option is supported in a Solaris 8, 9, or 10 release, see the specific version of Solaris Reference Manual AnswerBook on http://docs.sun.com.

X

Maintaining Diskless Client Compatibility

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

Verifying Packages

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

Example B-1 Testing a Package

After a package is created, it must be tested by installing it in an alternate root (/) file system location by using the -R dir_name option to pkgadd. After the package is installed, it must be checked for correctness by using pkgchk, as in this example.

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

No errors should be displayed.

Example B-2 Testing a Package on /export/SUNWvxvm

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

# pkgchk -d /export SUNWvxvm

No errors should be displayed.

Other commands can check the package when you are creating, modifying, and deleting files. The following commands are some examples.

# 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}