Chapter 11 Custom JumpStart (Reference)

This chapter lists keywords and values that you can use in the rules file, profiles, and begin and finish scripts.

• Rule Keywords and Values

• Profile Keywords and Values

• Custom JumpStart Environment Variables

• Probe Keywords and Values

Rule Keywords and Values

Table 11–1 describes the keywords and values that you can use in the rules file. For detailed instructions to create a rules file, see Creating the rules File.

disksize c0t3d0 250-300

disksize rootdisk 750-1000

installed c0t3d0s1 Solaris 10_606

memsize 64-128

network 192.168.2.0

osname Solaris 10_606

probe disks

totaldisk 300-500

Profile Keywords and Values

This section describes the profile keywords and values that you can use in a profile. For detailed instructions to create a profile, see Creating a Profile.

Profile Keywords Quick Reference

Table 11–2 provides a quick way to determine which keywords you can use, based on your installation scenario. Unless otherwise noted in the keyword descriptions, the keyword can only be used with the initial installation option.

Profile Keyword Descriptions and Examples

archive_location Keyword

archive_location retrieval_type location

retrieval_type

The values of retrieval_type and location depend on where the Solaris Flash archive is stored. The following sections contain the values you can use for retrieval_type and location and examples of how to use the archive_location keyword.

• Archive Stored on an NFS Server

• Archive Stored on an HTTP or HTTPS Server

• Archive Stored on an FTP Server

• Archive Stored on a Local Tape

• Archive Stored on a Local Device

• Archive Stored on a Local File

location

Specifics for locations are noted in the following sections.

Solaris Flash archive cannot be properly created when a non-global zone is installed. The Solaris Flash feature is not compatible with the Solaris Zones partitioning technology. If you create a Solaris Flash archive, the resulting archive is not installed properly when the archive is deployed under these conditions:

• The archive is created in a non-global zone

• The archive is created in a global zone that has non-global zones installed

Archive Stored on an NFS Server

If the archive is stored on an NFS server, use the following syntax for the archive_location keyword.

archive_location nfs server_name:/path/filename retry n

server_name

The name of the server where you stored the archive.

path

The location of the archive to be retrieved from the specified server. If the path contains $HOST, the Solaris Flash installation utilities replace $HOST with the name of the clone system that you are installing.

filename

The name of the Solaris Flash archive file.

retry n

An optional keyword. n is the maximum number of times the Solaris Flash utilities attempt to mount the archive.

Example 11–1 Archive Stored on an NFS Server

archive_location nfs golden:/archives/usrarchive

archive_location nfs://golden/archives/usrarchive

Archive Stored on an HTTP or HTTPS Server

If the archive is stored on an HTTP server, use the following syntax for the archive_location keyword.

archive_location http://server_name:port/path/filename optional_keywords

If the archive is stored on an HTTPS server, use the following syntax for the archive_location keyword.

archive_location https://server_name:port/path/filename optional_keywords

server_name

The name of the server where you stored the archive.

port

An optional port. port can be a port number or the name of a TCP service that has a port number that is determined at runtime.

If you do not specify a port, the Solaris Flash installation utilities use the default HTTP port number, 80.

path

The location of the archive to be retrieved from the specified server. If the path contains $HOST, the Solaris Flash installation utilities replace $HOST with the name of the clone system that you are installing.

filename

The name of the Solaris Flash archive file.

optional_keywords

The optional keywords that you can specify when you retrieve a Solaris Flash archive from an HTTP server.

Example 11–2 Archive Stored on a HTTP or HTTPS Server

archive_location http://silver/archives/usrarchive.flar timeout 5 

Example of the auth basic user_name password keyword:

archive_location http://silver/archives/usrarchive.flar timeout 5 user1 secret

Archive Stored on an FTP Server

If the archive is stored on an FTP server, use the following syntax for the archive_location keyword.

archive_location ftp://user_name:password@server_name:port/path/filename optional_keywords

user_name:password

The user name and password that you need to access the FTP server in the profile file.

server_name

The name of the server where you stored the archive.

port

A is an optional port. port can be a port number or the name of a TCP service that has a port number that is determined at runtime.

If you do not specify a port, the Solaris Flash installation utilities use the default FTP port number, 21.

path

The location of the archive to be retrieved from the specified server. If the path contains $HOST, the Solaris Flash installation utilities replace $HOST with the name of the clone system that you are installing.

filename

The name of the Solaris Flash archive file.

optional_keywords

The optional keywords that you can specify when you retrieve a Solaris Flash archive from an FTP server.

Example 11–3 Archive Stored on an FTP Server

archive_location ftp://user1:secret@silver/archives/usrarchive.flar timeout 5

Archive Stored on a Local Tape

If the archive is stored on a tape, use the following syntax for the archive_location keyword.

archive_location local_tape device position

device

The name of the tape drive where you stored the Solaris Flash archive. If the device name is a canonical path, the Solaris Flash installation utilities retrieve the archive from the path to the device node. If you supply a device name that is not a canonical path, the Solaris Flash installation utilities add /dev/rmt/ to the path.

position

Designates the place on the tape drive where you saved the archive. If you do not supply a position, the Solaris Flash installation utilities retrieve the archive from the current position on the tape drive. By specifying a position, you can place a begin script or a sysidcfg file on the tape drive before the archive.

Example 11–4 Archive Stored on a Local Tape

archive_location local_tape /dev/rmt/0n 5

archive_location local_tape 0n 5

Archive Stored on a Local Device

You can retrieve a Solaris Flash archive from a local device if you stored the Solaris Flash archive on a file system-oriented, random-access device, such as a diskette or a DVD. Use the following syntax for the archive_location keyword.

You can retrieve an archive from stream-oriented devices, such as tape, by using the syntax for local tape.

archive_location local_device device path/filename file_system_type

device

The name of the drive where you stored the Solaris Flash archive. If the device name is a canonical path, the device is mounted directly. If you supply a device name that is not a canonical path, the Solaris Flash installation utilities add /dev/dsk/ to the path.

path

The path to the Solaris Flash archive, relative to the root of the file system on the device you specified. If the path contains $HOST, the Solaris Flash installation utilities replace $HOST with the name of the clone system that you are installing.

filename

The name of the Solaris Flash archive file.

file_system_type

Specifies the type of file system on the device. If you do not supply a file system type, the Solaris Flash installation utilities attempt to mount a UFS file system. If the UFS mount fails, the Solaris Flash installation utilities attempt to mount an HSFS file system.

Example 11–5 Archive Stored on a Local Device

To retrieve an archive from a local hard drive that is formatted as a UFS file system, use the following command:

archive_location local_device c0t0d0s0 /archives/$HOST

To retrieve an archive from a local CD-ROM that has an HSFS file system, use the following command:

archive_location local_device c0t0d0s0 /archives/usrarchive

Archive Stored on a Local File

You can retrieve an archive that you stored in the miniroot from which you booted the clone system as a local file. When you perform a custom JumpStart installation, you boot the system from a DVD, CD, or an NFS-based miniroot. The installation software is loaded and run from this miniroot. Therefore, a Solaris Flash archive that you stored in the DVD, CD, or NFS-based miniroot is accessible as a local file. Use the following syntax for the archive_location keyword.

archive_location local_file path/filename 

path

The location of the archive. The path must be accessible to the system as a local file while the system is booted from the Solaris Software - 1 CD or from the Solaris Operating System DVD. The system cannot access /net or any other automounted directory when it is booted from the Solaris Software - 1 CD or from the Solaris Operating System DVD.

filename

The name of the Solaris Flash archive file.

Example 11–6 Archive Stored on a Local File

archive_location local_file /archives/usrarchive

backup_media Profile Keyword

backup_media type path

You can use backup_media only with the upgrade option when disk space reallocation is required.

If non-global zones are installed, do not use this keyword. If this keyword is used in the JumpStart profile, the upgrade stops and an error message is displayed.

backup_media defines the media that is to be used to back up file systems if space needs to be reallocated during an upgrade because of insufficient space. If multiple tapes or diskettes are required for the backup, you are prompted to insert tapes or diskettes during the upgrade.

Example 11–7 backup_media Profile Keyword

backup_media local_tape /dev/rmt/0

backup_media local_diskette /dev/rdiskette1

backup_media local_filesystem /dev/dsk/c0t3d0s4

backup_media local_filesystem /export

backup_media remote_filesystem system1:/export/temp

backup_media remote_system user1@system1:/export/temp

boot_device Profile Keyword

boot_device device eeprom

boot_device designates the device where the JumpStart program is to install the root (/) file system and the system's boot device. boot_device must match any filesys keywords that specify the root (/) file system and the root_device keyword.

If you do not specify the boot_device keyword in a profile, the following boot_device keyword is specified by default during the installation:

boot_device any update

device

Use one of the following values.

SPARC: cwtxdysz or cxdysz

The disk slice where the JumpStart program places the root (/) file system, for example, c0t0d0s0.

x86: cwtxdy or cxdy

The disk where the JumpStart program places the root (/) file system, for example, c0d0.

existing

The JumpStart program places the root (/) file system on the system's existing boot device.

any

The JumpStart program chooses where to place the root (/) file system. The JumpStart program attempts to use the system's existing boot device. The JumpStart program might choose a different boot device if necessary.

eeprom

Choose to update or preserve the system's EEPROM.

The eeprom value enables you to update the system's EEPROM if you change the system's current boot device. By updating the system's EEPROM, the system can automatically boot from the new boot device.

---

Note –

x86: You must specify the preserve value.

---

update

The JumpStart program updates the system's EEPROM to the specified boot device so that the installed system automatically boots from it.

preserve

The boot device value in the system's EEPROM is not changed. If you specify a new boot device without changing the system's EEPROM, you need to change the system's EEPROM manually so it can automatically boot from the new boot device.

Example 11–8 boot_device Profile Keyword

boot_device c0t0d0s2 update

bootenv createbe Profile Keyword

bootenv createbe bename new_BE_name filesystem mountpoint:device:fs_options 
[filesystem...]

bootenv createbe keyword enables you to quickly create an empty-and-inactive boot environment at the same time you are installing the Solaris OS. At the least, you must create the root (/) file system. The slices are reserved for the file systems specified, but no file systems are copied. The boot environment is named, but not actually created until installed with a Solaris Flash archive. When the empty boot environment is installed with an archive, file systems are installed on the reserved slices. The following lists the values for bename and filesystem.

bename new_BE_name

bename specifies the name of the new boot environment to be created. new_BE_name can be no longer than 30 characters, can contain only alphanumeric characters, and can contain no multibyte characters. The name must be unique on the system.

filesystem mountpoint:device:fs_options

filesystem determines the type and number of file systems that are to be created in the new boot environment. At least one slice that contains the root (/) file system must be defined. File systems can be on the same disk or spread across multiple disks.

• mountpoint can be any valid mount point or – (hyphen), indicating a swap slice.

• device must be available when the operating system that is being installed is first booted. The device has no relation to JumpStart special storage devices such as free. The device cannot be a Solaris Volume Manager volume or Veritas Volume Manager volume. device is the name of a disk device, of the form /dev/dsk/cwtxdysz.

• fs_options can be one of the following:

  • ufs, which indicates a UFS file system.

  • swap, which indicates a swap file system. The swap mount point must be a – (hyphen).

For a profile example and background about using this keyword, see the following references:

client_arch Profile Keyword

client_arch karch_value ...

client_arch specifies that the operating system server is to support a different platform group than the server uses. If you do not specify client_arch in the profile, any diskless client that uses the operating system server must contain the same platform group as the server. You must specify each platform group that you want the operating system server to support.

Valid values for karch_value are sun4u and i86pc. For a detailed list of platform names and various systems, see Solaris Sun Hardware Platform Guide at http://docs.sun.com.

You can use client_arch only when system_type is specified as server.

client_root Profile Keyword

client_root root_size

client_root defines the amount of root space, root_size in Mbytes, to allocate for each client. If you do not specify client_root in a server's profile, the installation software allocates 15 Mbytes of root space per client. The size of the client root area is used in combination with the num_clients keyword to determine how much space to reserve for the /export/root file system.

You can use client_root only when system_type is specified as server.

client_swap Profile Keyword

client_swap swap_size

client_swap defines the amount of swap space, swap_size in Mbytes, to allocate for each diskless client. If you do not specify client_swap in the profile, 32 Mbytes of swap space is allocated by default.

You can use client_swap only when system_type is specified as server.

Example 11–9 client_swap Profile Keyword

The following example specifies that each diskless client is to have a swap space of 64 Mbytes.

client_swap 64

How the Size of swap Is Determined

If a profile does not specify the size of swap, the JumpStart program determines the size of the swap space, based on the system's physical memory. Table 11–5 shows how the size of swap is determined during a custom JumpStart installation.

The JumpStart program makes the size of swap no more than 20 percent of the disk where swap is located. The allocation is different if the disk contains free space after laying out the other file systems. If free space exists, the JumpStart program allocates the free space to swap, and if possible, allocates the amount that is shown in Table 11–5.

Physical memory plus swap space must total a minimum of 32 Mbytes.

cluster Profile Keyword (Adding Software Groups)

cluster group_name

cluster designates the software group to add to the system.

A software group is a metacluster that contains a collection of clusters and packages. The software group is installed by using the cluster keyword and group_name variable. This cluster keyword can only be installed in an initial installation. This cluster keyword refers to metaclusters found in the clustertoc(4) file.

A cluster is a collection of packages that is named SUNWname. A cluster is installed by using the cluster keyword and cluster_name variable. A cluster can be added or removed from a software group (metacluster) in an initial install or an upgrade.

The group_name for each software group is listed in the following table.

The following limitations apply:

• You can specify only one software group in a profile.

• The software group must be specified before other cluster and package entries.

• If you do not specify a software group with cluster in the profile, the end–user software group, SUNWCuser, is installed on the system.

For more information about software groups, see Disk Space Recommendations for Software Groups.

cluster Profile Keyword (Adding or Deleting Clusters)

cluster cluster_name add_delete_switch

cluster designates whether a cluster is to be added or deleted from the software group that is to be installed on the system.

cluster_name

The name of the cluster that must be in the form SUNWCname.

add_delete_switch

An optional keyword that indicates whether to add or delete the cluster that is specified. Use the value add or delete. If you do not specify add or delete, add is used by default.

When you use cluster during an upgrade, the following conditions apply:

• All clusters that are already on the system are automatically upgraded.

• If you specify cluster_name add, and cluster_name is not installed on the system, the cluster is installed.

• If you specify cluster_name delete, and cluster_name is installed on the system, the package is deleted before the upgrade begins.

If non-global zones are installed, do not use this keyword to upgrade. If this keyword is used, the upgrade continues, but the keyword is ignored.

A software group is a metacluster that contains a collection of clusters and packages. The software group is installed by using the cluster keyword and group_name variable. This cluster keyword can only be installed in an initial installation. This cluster keyword refers to metaclusters found in the clustertoc(4) file.

A cluster is collection of packages. Clusters can be grouped together to form a software group (metacluster). A cluster name is always in the form of SUNW<name>. A cluster is installed by using the cluster keyword and cluster_name variable. A cluster can be added or removed from a software group (metacluster) in an initial install or an upgrade.

dontuse Profile Keyword

dontuse disk_name ...

By default, the JumpStart program uses all of the operational disks on the system when partitioning default is specified. dontuse designates one or more disks that you do not want the JumpStart program to use. disk_name must be specified in the form cxtydzor cydz, for example, c0t0d0.

You cannot specify the dontuse keyword and the usedisk keyword in the same profile.

x86: fdisk Profile Keyword

fdisk disk_name type size

fdisk defines how the fdisk partitions are set up on an x86 based system. You can specify fdisk more than once. When fdisk partitions an x86 based system, the following occurs:

• All fdisk partitions on the disk are preserved unless you delete the partitions with the fdisk keyword by assigning size the value of delete or 0. Also, all existing fdisk partitions are deleted when size is set to all.

• A Solaris fdisk partition that contains a root (/) file system is always designated as the active partition on the disk.

  ---

  Note –

  The system boots from the active partition by default.

  ---

• If the fdisk keyword is not specified in a profile, the following fdisk keyword is used by default during the installation.

  fdisk all solaris maxfree

• fdisk entries are processed in the order in which the entries are listed in the profile.

disk_name

Use the following values to specify where the fdisk partition is to be created or deleted:

• cxtydz or cydz – A specific disk, for example, c0t3d0.

• rootdisk – The variable that contains the value of the system's root disk, which is determined by the JumpStart program as described in How the System's Root Disk Is Determined.

• all – All the selected disks.

type

Use the following values to specify the type of fdisk partition that is to be created or deleted on the specified disk:

• solaris – A Solaris fdisk partition (SUNIXOS fdisk type).

• dosprimary – An alias for primary DOS fdisk partitions, not for fdisk partitions that are extended or reserved for data DOS. When you delete fdisk partitions by assigning size the value delete, dosprimary is an alias for the DOSHUGE, DOSOS12, and DOSOS16 fdisk types. When you create an fdisk partition, dosprimary is an alias for the DOSHUGE fdisk partition.

• DDD – An integer fdisk partition. DDD is an integer between 1 and 255 inclusive.

  ---

  Note –

  You can specify this value only if size is delete.

  ---

• 0xHH – A hexadecimal fdisk partition. HH is a hexadecimal number between 01 and FF.

  ---

  Note –

  You can specify this value only if size is delete.

  ---

The following table shows the integer and hexadecimal numbers for some of the fdisk types.

fdisk Type	DDD	HH
DOSOS12	1	01
PCIXOS	2	02
DOSOS16	4	04
EXTDOS	5	05
DOSHUGE	6	06
DOSDATA	86	56
OTHEROS	98	62
UNIXOS	99	63

size

Use one of the following values:

• DDD – An fdisk partition of size DDD in Mbytes is created on the specified disk. DDD must be an integer, and the JumpStart program automatically rounds the number up to the nearest cylinder boundary. Specifying a value of 0 is the same as specifying delete.

• all – An fdisk partition is created on the entire disk. All existing fdisk partitions are deleted.

  ---

  x86 only –

  The all value can be specified only if type is solaris.

  ---

• maxfree – An fdisk partition is created in the largest contiguous free space on the specified disk. If an fdisk partition of the specified type already exists on the disk, the existing fdisk partition is used. A new fdisk partition is not created on the disk.

  ---

  x86 only –

  The disk must contain at least one unused fdisk partition. Also, the disk must have free space or the installation fails. The maxfree value can be specified only if type is solaris or dosprimary.

  ---

• delete – All fdisk partitions of the specified type are deleted on the specified disk.

filesys Profile Keyword (Mounting Remote File Systems)

filesys server:path server_address mount_pt_name mount_options

By using filesys with the listed values, the JumpStart program sets up the installed system to automatically mount remote file systems when the system boots. You can specify filesys more than once.

server

The name of the server where the remote file system is located, followed by a colon.

path

The remote file system's mount-point name. For example, /usr or /export/home

server_address

The IP address of the server that is specified in server:path. If a name service is not running on the network, the server_address value can be used to populate the /etc/hosts file with the server's host name and IP address. If you are not specifying the server's IP address, you must specify a minus sign (-). For example, if you have a name service that is running on the network, you do not need to specify the server's IP address.

mount_pt_name

The name of the mount point on which the remote file system is to be mounted.

mount_options

One or more mount options, which is the same as the -o option of the mount(1M) command. The mount options are added to the /etc/vfstab entry for the specified mount_pt_name.

---

Note –

If you need to specify more than one mount option, the mount options must be separated by commas and no spaces (ro,quota for example).

---

Example 11–10 filsys Profile Keyword

filesys sherlock:/export/home/user2 - /home

filesys Profile Keyword (Creating Local File Systems)

filesys slice size file_system optional_parameters

By using filesys with the values that are listed, the JumpStart program creates local file systems during the installation. You can specify filesys more than once.

slice

Use one of the following values:

any

The JumpStart program places the file system on any disk.

---

Note –

You cannot specify any when size is existing, all, free, start:size, or ignore.

---

cwtxdysz or cxdysz

The disk slice where the JumpStart program places the file system, for example, c0t0d0s0 or c0d0s0.

rootdisk.sn

The variable that contains the value for the system's root disk, which is determined by the JumpStart program as described in How the System's Root Disk Is Determined. The sn suffix indicates a specific slice on the disk.

size

Use one of the following values:

num

The size of the file system is set to num in Mbytes.

existing

The current size of the existing file system is used.

---

Note –

When you use the existing value, you can change the name of an existing slice by specifying file_system as a different mount_pt_name.

---

auto

The size of the file system is automatically determined, depending on the software that is selected.

all

The specified slice uses the entire disk for the file system. When you specify the all value, no other file systems can be placed on the specified disk.

free

The remaining unused space on the disk is used for the file system.

---

Note –

If free is used as the value to filesys, the filesys entry must be the last entry in a profile.

---

start:size

The file system is explicitly partitioned. start is the cylinder where the slice begins. size is the number of cylinders for the slice.

file_system

The file_system value is optional and used when slice is specified as any or cwtxdysz. If file_system is not specified, unnamed is set by default. If unnamed is set, you cannot specify the optional_parameters value. Use one of the following values:

mount_pt_name

The file system's mount-point name, for example, /var.

swap

The specified slice is used as swap.

overlap

The specified slice is defined as a representation of a disk region. The VTOC value is V_BACKUP. By default, slice 2 is an overlap slice that is a representation of the whole disk.

---

Note –

You can specify overlap only when size is existing, all, or start:size.

---

unnamed

The specified slice is defined as a raw slice, so slice does not have a mount-point name. If you do not specify file_system, unnamed is used by default.

ignore

The specified slice is not used or recognized by the JumpStart program. You can use this option to specify that you want a file system to be ignored on a disk during installation. The JumpStart program creates a new file system on the same disk with the same name. You can use ignore only when partitioning existing is specified.

optional_parameters

Use one of the following values:

preserve

The file system on the specified slice is preserved.

---

Note –

preserve can be specified only when size is existing and slice is cwtxdysz.

---

mount_options

One or more mount options, which is the same as the -o option of the mount(1M) command. The mount options are added to the /etc/vfstab entry for the specified mount_pt_name.

---

Note –

If you need to specify more than one mount option, the mount options must be separated by commas and no space (ro,quota, for example).

---

filesys Profile Keyword (Creating RAID-1 Volumes)

filesys mirror[:name]slice [slice] size file_system optional_parameters

By using the filesys mirror keywords with the values that are listed, the JumpStart program creates the RAID-1 and RAID-0 volumes that are necessary to create a mirrored file system. You can specify filesys mirror more than once to create RAID-1 volumes (mirrors) for different file systems.

The filesys mirror keyword is only supported for initial installations.

name

This optional keyword enables you to name the RAID-1 volume (mirror). Mirror names must start with the letter “d”, followed by a number between 0 and 127, for example, d100. If you do not specify a mirror name, the custom JumpStart program assigns a mirror name for you. For guidelines about how to name mirrors, see RAID Volume Name Requirements and Guidelines for Custom JumpStart and Solaris Live Upgrade.

slice

This value specifies the disk slice where the custom JumpStart program places the file system you want to duplicate. The slice value must follow the format cwtxdysz, for example c0t0d0s0 or c0t0d0s5. The custom JumpStart program creates a RAID-0 volume (single-slice concatenation) on the slice, and creates a RAID-1 volume to mirror the concatenation. You can specify up to two slices for two RAID-0 volumes.

size

This value specifies the size, in Mbytes, of the file system.

file_system

This value specifies the file system that you are duplicating. The custom JumpStart program creates the RAID-1 volume from the slices that are specified and mounts the RAID-1 volume on the specified file system. In addition to critical file systems, such as root (/), /usr, and /var, you can also specify swap as the file system.

optional_parameters

One or more mount options, which is the same as the -o option of the mount(1M) command. The mount options are added to the /etc/vfstab entry for the specified file_system. If you need to specify more than one mount option, the mount options must be separated by commas and no spaces, for example, ro,quota.

For more information about creating mirrored file systems during your installation, see Chapter 12, Creating RAID-1 Volumes (Mirrors) During Installation (Overview).

forced_deployment Profile Keyword (Installing Solaris Flash Differential Archives)

forced_deployment 

forced_deployment forces the installation of a Solaris Flash differential archive onto a clone system that is different than the software expects.

If you use forced_deployment, all new files are deleted to bring the clone system to the expected state. If you are not certain that you want files deleted, use the default, which protects new files by stopping the installation.

geo Profile Keyword

geo region

geo designates the regional locale or locales that you want to install on a system or to add when upgrading a system. region designates a geographical area that contains the locales that you want to install. Values you can specify for region are listed in the following table.

If non-global zones are installed, do not use this keyword to upgrade. If this keyword is used, the upgrade continues, but the keyword is ignored.

A complete list of the component locale values that compose each regional locale that is listed previously is presented in International Language Environments Guide.

You can specify a geo keyword for each locale you need to add to a system.

install_type Profile Keyword

install_type initial_upgrade_flash_switch

install_type defines whether to erase and install a new Solaris OS on a system, upgrade the existing Solaris OS on a system, or install a Solaris Flash archive on the system.

You must specify install_type in a profile, and install_type must be the first profile keyword in every profile.

You must use one of the following options for the initial_upgrade_flash_switch:

initial_install

Specifies to perform an initial installation of the Solaris OS

upgrade

Specifies to perform an upgrade of the Solaris OS

flash_install

Specifies to install a Solaris Flash archive that overwrites all files

flash_update

Specifies to install a Solaris Flash differential archive that overwrites only the files that are specified

Some profile keywords can only be used with the initial_install option. Some profile keywords can only be used with the upgrade option. Some profile keywords can only be used with the flash_install option.

layout_constraint Profile Keyword

layout_constraint slice constraint minimum_size

layout_constraint designates the constraint auto-layout has on a file system if auto-layout needs to reallocate space during an upgrade because of space problems.

slice

Specifies the file system's disk slice on which to specify the constraint. You must specify the system's disk slice in the form cwtxdysz or cxdysz.

constraint

Use one of the following constraints for the specified file system:

changeable

Auto-layout can move the file system to another location and it can change the file system size. The changeable constraint can only be specified on file systems that are mounted by the /etc/vfstab file. You can change the file system's size by specifying the minimum_size value.

When you mark a file system as changeable and minimum_size is not specified, the file system's minimum size is set to 10 percent more than the minimum size that is required. For example, if the minimum size for a file system is 100 Mbytes, the changed size is 110 Mbytes. If minimum_size is specified, any free space that remains, original size minus minimum size, is used for other file systems.

movable

Auto-layout can move the file system to another slice on the same disk or different disk. The file system size remains the same.

available

Auto-layout can use all of the space on the file system to reallocate space. All of the data in the file system is lost. The available constraint can only be specified on file systems that are not mounted by the /etc/vfstab file.

collapse

Auto-layout moves and collapses the specified file system into the parent file system. You can use the collapse option to reduce the number of file systems on a system as part of the upgrade. For example, if a system has the /usr and /usr/share file systems, collapsing the /usr/share file system moves the file system into /usr, the parent file system. You can specify the collapse constraint only on file systems that are mounted by the /etc/vfstab file.

minimum_size

Specifies the size of the file system after auto-layout reallocates space. The minimum_size option enables you to change the size of a file system. The size of the file system might be larger if unallocated space is added to the file system. But, the size is never less than the value you specify. The minimum_size value is optional. Use this value only if you have marked a file system as changeable and the minimum size cannot be less than what the file system needs for the existing file system contents.

Example 11–11 layout_constraint Profile Keyword

layout_constraint c0t3d0s1 changeable 200

layout_constraint c0t3d0s4 movable

layout_constraint c0t3d1s3 available

layout_constraint c0t2d0s1 collapse

local_customization Profile Keyword (Installing Solaris Flash Archives)

local_customization local_directory

Before you install a Solaris Flash archive on a clone system, you can create custom scripts to preserve local configurations on the clone system. The local_customization keyword designates the directory where you have stored these scripts. local_directory is the path to the script on the clone system.

For information about predeployment and postdeployment scripts, see Creating Customization Scripts in Solaris 10 6/06 Installation Guide: Solaris Flash Archives (Creation and Installation).

locale Profile Keyword

locale locale_name

You can use locale with both the initial installation and upgrade options.

locale designates the locale packages you want to install or add when upgrading for the specified locale_name. The locale_name values are the same as those values that are used for the $LANG environment variable. International Language Environments Guide contains a list of valid locale values.

When you use the locale keyword, consider the following:

• If you have preconfigured a default locale, the locale is automatically installed. The English language packages are installed by default.

• You can specify a locale keyword for each locale you need to add to a system.

• If non-global zones are installed, do not use this keyword to upgrade. If this keyword is used, the upgrade continues, but the keyword is ignored. Locales already installed on the system are upgraded automatically.

metadb Profile Keyword (Creating State Database Replicas)

metadb slice [size size-in-blocks] [count number-of-replicas]

The metadb keyword enables you to create Solaris Volume Manager state database replicas (mediates) during your custom JumpStart installation. You can use the metadb keyword multiple times in your profile file to create state database replicas on different disk slices.

slice

You must specify the disk slice on which you want the custom JumpStart program to place the state database replica. The slice value must follow the format cwtxdysz.

size size-in-blocks

The size optional keyword enables you to specify the size, in blocks, of the state database replica to be created. If you do not specify a size value, the custom JumpStart program uses a default size of 8192 blocks for the state database replica.

count number-of-replicas

You can specify the number of state database replicas you are creating by setting the optional count keyword value in your profile. If you do not specify a count value, the custom JumpStart program creates three state database replicas by default.

For more information about creating Solaris Volume Manager state database replicas during your installation, see State Database Replicas Guidelines and Requirements.

no_content_check Profile Keyword (Installing Solaris Flash Archives)

no_content_check

When installing a clone system with a Solaris Flash differential archive, you can use the no_content_check keyword to ignore file-by-file validation. File-by-file validation ensures that the clone system is a duplicate of the master system. Avoid using this keyword unless you are sure the clone system is a duplicate of the original master system.

If you use no_content_check, all new files are deleted to bring the clone system to the expected state. If you are not certain that you want files deleted, use the default, which protects new files by stopping the installation.

For information about installing Solaris Flash differential archives, see To Prepare to Install a Solaris Flash Archive With a Custom JumpStart Installation.

no_master_check Profile Keyword (Installing Solaris Flash Archives)

no_master_check

When installing a clone system with a Solaris Flash differential archive, you can use the no_master_check keyword to ignore checking the clone system to make sure it was built from the original master system. Avoid using this keyword unless you are sure the clone system is a duplicate of the original master system.

For information about installing Solaris Flash differential archives, see To Prepare to Install a Solaris Flash Archive With a Custom JumpStart Installation.

num_clients Profile Keyword

num_clients client_num

When a server is installed, space is allocated for each diskless client's root (/) and swap file systems. num_clients defines the number of diskless clients, client_num, that a server supports. If you do not specify num_clients in the profile, five diskless clients are allocated by default.

You can use num_clients only when system_type is specified as server.

package Profile Keyword

package package_name [add [retrieval_type location]| delete]

You can use package with both the initial installation and upgrade options. The package keyword enables you to do the following:

• Add a package to the software group from the Solaris distribution that is to be installed.

• Add a package to the software group from outside the distribution that is being installed.

• Exclude or remove a package from the software group that is to be installed or upgraded.

• Add a package from outside the distribution that is being installed when installing a Solaris Flash archive.

package_name

Specifies the package name in the form SUNWname. To view detailed information about packages and their names, on an installed system, use the pkginfo -l command.

add | delete

Specifies to add or remove the specified package. If you do not specify add or delete, add is used by default.

---

Note –

You can add more than one package by adding another package entry to the profile and omitting the location. The location of the previous package is used for all subsequent packages if the location is left blank.

---

[retrieval_type location]

Specifies the addition of a package or packages that are located outside the Solaris distribution that is being installed. The values of retrieval_type and location depend on where the package is stored. The following sections contain the values you can use for retrieval_type and location and examples of how to use the package_name keyword.

If non-global zones are installed, do not use this keyword to upgrade. If this keyword is used, the upgrade continues, but the keyword is ignored.

Packages Stored on an NFS Server

If the package is stored on an NFS server, use one of the following syntaxes for the package keyword.

package package_name add nfs server_name:/path [retry n]
package package_name add nfs://server_name:/path [retry n]

package_name

Specifies the package name in the form SUNWname. To view detailed information about packages and their names, on an installed system, use the pkginfo -l command.

server_name

Specifies the name of the server where you stored the package.

path

Specifies the location of the package directory on the specified server. If the path contains $HOST, $HOST is replaced with the name of the host system that you are installing.

retry n

Is an optional keyword. n is the maximum number of times the installation process attempts to mount the directory.

Example 11–12 Adding a Package by Using NFS

In this example, the package profile keyword adds the SUNWnew package from the NFS location nfs://golden/packages/Solaris_10_606/. If a mount fails, the NFS mount is tried five times.

package SUNWnew add nfs golden:/packages/Solaris_10 6/06 retry 5

Packages Stored on an HTTP Server

If the package is stored on an HTTP server, use one of the following syntaxes for the package keyword.

package package_name add http://server_name[:port] path optional_keywords
package package_name add http server_name[:port] path optional_keywords

package_name

Specifies the package name in the form SUNWname. To view detailed information about packages and their names, on an installed system, use the pkginfo -l command.

server_name

Specifies the name of the server where you stored the package.

port

Specifies an optional port. port can be a port number or the name of a TCP service that has a port number that is determined at runtime.

If you do not specify a port, the default HTTP port number 80 is used.

path

Specifies the location of the package to be retrieved from the specified server. When using an HTTP server, the package must be in package datastream format.

optional_keywords

Specifies the optional keywords to use when you retrieve a package from an HTTP server.

Example 11–13 Adding a Package by Using HTTP

In this example, the package profile keyword adds all the packages listed in the Solaris 10_606 directory from the HTTP location http://package.central/Solaris_10_606. If five minutes pass and no data is received, the package data is retrieved again. Previous package data is discarded. Either of the following formats can be used.

package SUNWnew add http package.central/Solaris_10_606 timeout 5 

package SUNWnew add http://package.central/Solaris_10_606 timeout 5 

Example 11–14 Adding a Package by Using HTTP with a Proxy Port

In this example, the package profile keyword adds all the packages listed in the Solaris_10_606 directory from the HTTP location http://package.central/Solaris_10_606. The package is retrieved across a firewall by using the proxy keyword.

package SUNWnew add http://package.central/Solaris_10_606 proxy webcache.east:8080

Packages Stored on a Local Device

You can retrieve a Solaris package from a local device if you stored the package on a file system-oriented, random-access device, such as a diskette or a DVD-ROM. Use the following syntax for the package keyword.

package package_name add local_device device path file_system_type

package_name

Specifies the package name in the form SUNWname. To view detailed information about packages and their names, on an installed system, use the pkginfo -l command.

device

Specifies the name of the drive where the Solaris package resides. If the device name is a canonical path, the device is mounted directly. If you supply a device name that is not a canonical path, the installation utility adds /dev/dsk/ to the path.

path

Specifies the path to the Solaris package, relative to the root (/) file system on the device you specified.

file_system_type

Specifies the type of file system on the device. If you do not supply a file system type, the installation utility attempts to mount a UFS file system. If the UFS mount fails, the installation utility attempts to mount an HSFS file system.

Example 11–15 Adding a Package by Using a Local Device With a UFS File System

In this example, the package profile keyword adds the SUNWnew package from the directory /Solaris_10_606/Product from the local device c0t6d0s0. This is a UFS file system.

package SUNWnew add local_device c0t6d0s0 /Solaris_10_606/Product ufs

Example 11–16 Adding a Package by Using a Local Device From an HSFS File System

In this example, the package profile keyword adds the SUNWnew package from the directory /Solaris_10_606/Product from the local device c0t6d0s0. This is an HSFS file system.

package SUNWnew add local_device c0t6d0s0 /Solaris_10_606/Product  hsfs

Packages Stored on a Local File

A package can be installed from the miniroot from which you booted the system. When you perform a custom JumpStart installation, you boot the system from a DVD, CD, or an NFS-based miniroot. The installation software is loaded and run from this miniroot. Therefore, a package that you stored in the DVD, CD, or NFS-based miniroot is accessible as a local file. Use the following syntax for the package keyword.

package package_name add local_file path 

package_name

Specifies the package name in the form SUNWname. To view detailed information about packages and their names, on an installed system, use the pkginfo -l command.

path

Specifies the location of the package. The path must be accessible to the system as a local file while the system is booted from the Solaris Software - 1 CD or from the Solaris Operating System DVD. The system cannot access /net when it is booted from the Solaris Software - 1 CD or from the Solaris Operating System DVD.

Example 11–17 Adding a Package by Using a Local File

In this example, the package profile keyword adds the SUNWnew package from the /Solaris_10_606/Product directory.

package SUNWnew add local_file /Solaris_10_606/Product

Limitations When Using the package Keyword

Note these limitations when using the package keyword:

• Some packages are required and cannot be deleted.

• You cannot individually add or delete localization packages by using the package profile keyword. To add localization packages, use the locale profile keyword.

• Packages cannot be retrieved from an FTP server location or local backup, such as tape.

• Packages within the Solaris distribution being installed cannot be added from alternate locations. If a package from the Solaris distribution is specified, the package cannot be followed by an alternative location in order to maintain consistency with the resulting installed system.

• In order to install without manual intervention, the package must be installable by using the pkgadd command. The same admin file must be used to install the software group packages and the package that resides in another location.

  • If the retrieval_type is HTTP, then the package must be in stream format.

  • If the retrieval_type is NFS server, local device, or local file, then the package should follow standard packaging format with the directory name being the same as the package being installed.

  • If a package is being added from a separate location and a package depends on another package that is not currently installed, the package is not installed. An error message is logged into the install or upgrade log file.

• If the package is being installed with a Solaris Flash archive, follow these guidelines.

  • Any package installed must be compatible with the archive.

  • If a package is present in the archive, the JumpStart overwrites the existing package.

Upgrade Behavior When Using the package Keyword

When you use package for an upgrade, the JumpStart program performs the following actions:

• All packages already on the system are automatically upgraded.

• If you specify package_name add and package_name is not installed on the system, the package is installed.

• If you specify package_name delete and package_name is installed on the system, the package is deleted before the upgrade begins.

• If you specify package_name delete and package_name is not installed on the system, the package is not installed if the package is part of a cluster that is designated to be installed.

partitioning Profile Keyword

partitioning type

partitioning defines how the disks are divided into slices for file systems during the installation.

If you do not specify partitioning in the profile, the default type of partitioning is used by default.

type

Use one of the following values:

default

The JumpStart program selects the disks and creates the file systems on which to install the specified software, except for any file systems that are specified by the filesys keywords. rootdisk is selected first. The JumpStart program uses additional disks if the specified software does not fit on rootdisk.

existing

The JumpStart program uses the existing file systems on the system's disks. All file systems except /, /usr, /usr/openwin, /opt, and /var are preserved. The JumpStart program uses the last mount-point field from the file system superblock to determine which file-system mount point the slice represents.

---

Note –

When you use both the filesys and partitioning existing profile keywords, you must set size size to existing.

---

explicit

The JumpStart program uses the disks and creates the file systems that are specified by the filesys keywords. If you specify only the root (/) file system with the filesys keyword, all of the Solaris software is installed in the root (/) file system.

---

Note –

If you use the explicit profile value, you must use the filesys keyword to specify the disks to use and file systems to create.

---

patch Profile Keyword

patch patch_id_list | patch_file patch_location optional_keywords]

patch_id_list

Specifies the patch ID numbers that are to be installed. The list should be a list of comma-separated Solaris patch IDs. The patches are installed in the order specified in the list. Do not add a space after the comma, for example: 112467-01,112765-02.

patch_file

A file with a list of patches that is found in the patch_location. The patches are installed in the order specified in the file.

patch_location

Specifies the location where the patches reside. The locations allowed are the following:

• NFS server

• HTTP server

• Local device

• Local file

optional_keywords

Optional keywords depend on where patches are stored. The following sections describe the possible locations and optional keywords.

If non-global zones are installed, do not use this keyword to upgrade. If this keyword is used, the upgrade continues, but the keyword is ignored.

Patches Stored on an NFS Server

If the patch is stored on an NFS server, use one of the following syntaxes for the patch keyword.

patch patch_id_list | patch_file nfs server_name:/patch_directory [retry n]
patch patch_id_list | patch_file nfs://server_name/patch_director  [retry n]

patch_id_list

Specifies the patch ID numbers that are to be installed. The list should be a list of comma-separated Solaris patch IDs. The patches are installed in the order specified in the list.

patch_file

A file with a list of patches that is found in the patch_location. The patches are installed in the order specified in the file.

server_name

Specifies the name of the server where you stored the patches.

patch_directory

Specifies the location of the patch directory on the specified server. The patches must be in standard patch format.

retry n

Is an optional keyword. n is the maximum number of times the install utility attempts to mount the directory.

Example 11–18 Adding a Patch With an Ordered List by Using NFS

In this example, the patch profile keyword adds all the patches listed in the patch file from the NFS patch directory nfs://patch_master/Solaris/v10_606/patches. Patches are installed in the order listed in the patch. If a mount fails, the NFS mount is tried five times.

patch patch_file nfs://patch_master/Solaris/v10_606/patches retry 5

Example 11–19 Adding a Patch by Using NFS

In this example, the patch profile keyword adds the patches 112467–01 and 112765–02 from the patch directory /Solaris/v10_606/patches on the server patch_master.

patch 112467-01,112765-02 nfs patch_master:/Solaris/v10_606/patches

Patches Stored on an HTTP Server

If the patch is stored on an HTTP server, use one of the following syntaxes for the patch keyword.

patch  patch_id_list | patch_file http://server_name [:port] patch_directory optional_http_keywords

patch  patch_id_list | patch_file http server_name [:port] patch_directory optional_http_keywords

patch_id_list

Specifies the patch ID numbers that are to be installed. The list should be a list of comma-separated Solaris patch IDs. The patches are installed in the order specified in the list. Do not add a space after the comma, for example: 112467-01,112765-02.

patch_file

A file with a list of patches that is found in the patch_location. The patches are installed in the order specified in the file.

server_name

Specifies the name of the server where you stored the patch.

port

Specifies an optional port. port can be a port number or the name of a TCP service that has a port number that is determined at runtime.

If you do not specify a port, the default HTTP port number 80 is used.

patch_directory

Specifies the location of the patch directory to be retrieved from the specified server. When using an HTTP server, the patch must be in JAR format.

optional_keywords

Specifies the optional keywords to use when you retrieve a patch from an HTTP server.

Example 11–20 Adding a Patch With an Ordered List by Using HTTP

In this example, the patch profile keyword adds all the patches listed in the patch_file file from the HTTP location http://patch.central/Solaris/v10_606/patches. The patches are installed in the order specified in the file the patch file. If five minutes pass and no data is received, the patch data is retrieved again. Previous patch data is discarded.

patch patch_file http://patch.central/Solaris/v10_606/patches timeout 5

Example 11–21 Adding a Patch by Using HTTP

In this example, the patch profile keyword entry adds the patches 112467–01 and 112765–02 from the patch location http://patch_master/Solaris/v10_606/patches.

patch 112467-01,112765-02 http://patch.central/Solaris/v10_606/patches

Patches Stored on a Local Device

You can retrieve a Solaris package from a local device if you stored the package on a file system-oriented, random-access device, such as a diskette or a DVD-ROM. Use the following syntax for the patch keyword.

patch patch_id_list | patch_file local_device \
device path file_system_type

patch_id_list

Specifies the patch ID numbers that are to be installed. The list should be a list of comma-separated Solaris patch IDs. The patches are installed in the order specified in the list. Do not add a space after the comma, for example: 112467-01,112765-02.

patch_file

A file with a list of patches that is found in the patch_location. The patches are installed in the order specified in the file.

device

Specifies the name of the drive where the Solaris package resides. If the device name is a canonical path, the device is mounted directly. If you supply a device name that is not a canonical path, the installation utility adds /dev/dsk/ to the path.

path

Specifies the path to the Solaris patch, relative to the root (/) file system on the device you specified.

file_system_type

Specifies the type of file system on the device. If you do not supply a file system type, the installation utility attempts to mount a UFS file system. If the UFS mount fails, the installation utility attempts to mount an HSFS file system.

Example 11–22 Adding a Patch With an Ordered List by Using a Local Device

In this example, the patch profile keyword adds all the patches listed in the patch_file file from the directory /Solaris_10_606/patches from the local device c0t6d0s0. The patch file determines the order of patches to be installed.

patch patch_file c0t6d0s0 /Solaris_10_606/patches

Example 11–23 Adding a Patch by Using a Local Device

In this example, the patch profile keyword adds the patches 112467–01 and 112765–02 from the patch directory /Solaris_10_606/patches from local device c0t6d0s0.

patch 112467-01,112765-02 local_device c0t6d0s0 /Solaris_10_606/patches

Patches Stored on a Local File

A patch can be installed from the miniroot from which you booted the system. When you perform a custom JumpStart installation, you boot the system from a DVD, CD, or an NFS-based miniroot. The installation software is loaded and run from this miniroot. Therefore, a patch that you stored in the DVD, CD, or NFS-based miniroot is accessible as a local file. Use the following syntax for the patch keyword.

patch patch_id_list | patch_file local_file patch _directory 

patch_id_list

Specifies the patch ID numbers that are to be installed. The list should be a list of comma-separated Solaris patch IDs. The patches are installed in the order specified in the list. Do not add a space after the comma, for example: 112467-01,112765-02.

patch_file

A file with a list of patches that is found in the patch_location. The patches are installed in the order specified in the file.

patch_directory

Specifies the location of the patch directory. The patch directory must be accessible to the system as a local file while the system is booted from the Solaris Software - 1 CD or from the Solaris Operating System DVD. The system cannot access /net when it is booted from the Solaris Software - 1 CD or from the Solaris Operating System DVD.

Example 11–24 Adding a Patch With an Ordered List by Using a Local File

In this example, the patch profile keyword adds all the patches that are listed in the patch_file file from the /Solaris_10_606/patches directory. The patch file determines the order of patches to be installed.

patch patch_cal_file /Solaris_10_606/patches

Example 11–25 Adding a Patch by Using a Local File

In this example, the patch profile keyword adds the patches 112467–01 and 112765–02 from the patch directory /Solaris_10_606/patches.

patch 112467-01,112765-02 local_file /Solaris_10_606/patches

Limitations When Using the patch Keyword

Note the following limitations when using the patch keyword:

• Patches cannot be retrieved from FTP locations or local backup, such as tape.

• Signed patches cannot be added.

• Patches must be installable with the patchadd command.

• If a patch depends on a patch that is not currently installed, the patch is not installed. An error message is logged into the installation or upgrade log file.

• You must determine the correct order of the patches for a correct installation of the patches.

root_device Profile Keyword

root_device slice

root_device designates the system's root disk. How the System's Root Disk Is Determined contains additional information.

When you are upgrading a system, root_device designates the root (/) file system and the file systems that are mounted by its /etc/vfstab file to be upgraded. You must specify root_device if more than one root (/) file system can be upgraded on a system. You must specify slice in the form cwtxdysz or cxdysz.

When you use the root_device keyword, consider the following:

• If you specify root_device on a system with only one disk, the root_device and the disk must match. Also, any filesys keywords that specify the root (/) file system must match root_device.

• If you are upgrading a RAID-1 volume (mirror), the value that is specified for root_device should be one side of the mirror. The other side of the mirror is automatically upgraded.

Example 11–26 root_device Profile Keyword

root_device c0t0d0s2

How the System's Root Disk Is Determined

A system's root disk is the disk on the system that contains the root (/) file system. In a profile, you can use the rootdisk variable in place of a disk name, which the JumpStart program sets to the system's root disk. Table 11–8 describes how the JumpStart program determines the system's root disk for the installation.

The JumpStart program only determines a system's root disk size during an initial installation. You cannot change a system's root disk during an upgrade.

system_type Profile Keyword

system_type type_switch

system_type defines the type of system on which the Solaris OS is to be installed.

type_switch represents the option standalone or server, which you use to indicate the type of system on which the Solaris software is to be installed. If you do not specify system_type in a profile, standalone is used by default.

usedisk Profile Keyword

usedisk disk_name ...

By default, the JumpStart program uses all of the operational disks on the system when you specify partitioning default. The usedisk profile keyword designates one or more disks that you want the JumpStart program to use. You must specify disk_name in the form cxtydz or cydz, for example, c0t0d0 or c0d0s0.

If you specify usedisk in a profile, the JumpStart program uses only the disks that you specify after the usedisk keyword.

You cannot specify the usedisk keyword and the dontuse keyword in the same profile.

Limiting Profile Keywords When Upgrading With Non-Global Zones

When non-global zones are installed, you can use the custom JumpStart program to upgrade. Only two profile keywords should be used in the profile, the install_type and root_device keywords.

Because some keywords affect non-global zones, some keywords cannot be included in a profile. For example, using keywords that add packages, reallocate disk space, or add locales would affect non-global zones. If you use keywords that adversely affect non-global zones, these keywords are either ignored or prevent the upgrade from being completed. For a list of keywords that should not be used in a profile, see the following table.

For more information on non-global zones, see the following:

• Upgrading When Solaris Zones are Installed on a System

• Chapter 16, Introduction to Solaris Zones, in System Administration Guide: Solaris Containers-Resource Management and Solaris Zones

Custom JumpStart Environment Variables

You can use environment variables in your begin and finish scripts. For example, a begin script might extract the disk size, SI_DISKSIZES, and install or not install particular packages on a system, based on the actual disk size the script extracts.

Information that is gathered about a system is stored in these environment variables, which are generally set or not, depending on the rule keywords and values you use in the rules file.

For example, information about which operating system is already installed on a system is only available in SI_INSTALLED after the installed keyword is used.

Table 11–10 describes these variables and their values.

Probe Keywords and Values

Table 11–11 describes each rule keyword and its equivalent probe keyword.

Always place probe keywords at or near the beginning of the rules file.