Solaris 10 5/08 Installation Guide: Custom JumpStart and Advanced Installations

Chapter 8 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

Table 8–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.

Table 8–1 Descriptions of Rule Keywords and Values

Keyword

Value

Matches

any

minus sign (-)

Anything. The any keyword always succeeds.

arch

processor_type

Valid values for processor_type are the following:

SPARC: sparc
x86: i386

A system's processor type.

The uname -p command reports the system's processor type.

disksize

actual_disk_name size_range

actual_disk_name – A disk name in the form cxtydz, such as c0t3d0 or c0d0, or the special word rootdisk. If rootdisk is used, the disk to be matched is determined in the following order:

SPARC: The disk that contains the preinstalled boot image, which is a new SPARC based system with factory JumpStart installed
The c0t3d0s0 disk, if the disk exists
The first available disk that is searched in kernel probe order

size_range – The size of the disk, which must be specified as a range of Mbytes (x-x).

Note –

When calculating size_range, remember that a Mbyte equals 1,048,576 bytes. A disk might be advertised as a “535–Mbyte” disk, but the disk might contain only 510 million bytes of disk space. The JumpStart program views the “535–Mbyte” disk as a 510–Mbyte disk because 535,000,000 / 1,048,576 = 510. A “535–Mbyte” disk does not match a size_range equal to 530–550.

The name and size of a system's disk in Mbytes.

Example:

disksize c0t3d0 250-300

In the example, the JumpStart program attempts to match a system disk that is named c0t3d0. The disk can hold between 250 and 300 Mbytes of information.

Example:

disksize rootdisk 750-1000

In the example, the JumpStart program attempts to match a disk in the following order:

A system disk that contains a preinstalled boot image
The c0t3d0s0 disk, if the disk exists
The first available disk that can hold between 750 Mbytes and 1 Gbyte of information

domainname

actual_domain_name

A system's domain name, which controls how a naming service determines information.

If you have a system already installed, the domainname command reports the system's domain name.

hostaddress

actual_IP_address

A system's IP address.

hostname

actual_host_name

A system's host name.

If you have a system that is already installed, the uname -n command reports the system's host name.

installed

slice version

slice – A disk slice name in the form cwtxdysz, such as c0t3d0s5, or the special words any or rootdisk. If any is used, the JumpStart program attempts to match all of the system's disks in kernel probe order. If rootdisk is used, the disk to be matched is determined in the following order:

SPARC: The disk that contains the preinstalled boot image, which is a new SPARC based system with factory JumpStart installed
The c0t3d0s0 disk, if the disk exists
The first available disk that is searched in kernel probe order

version – A version name or the special words any or upgrade. If any is used, any Solaris or SunOS release is matched. If upgrade is used, any Solaris release that is supported and can be upgraded is matched.

If the JumpStart program finds a Solaris release but is unable to determine the version, the version that is returned is SystemV.

A disk that has a root (/) file system that corresponds to a particular version of Solaris software.

Example:

installed c0t3d0s1 Solaris 10

In the example, the JumpStart program attempts to match a system that has a Solaris root (/) file system on c0t3d0s1.

karch

actual_platform_group

Valid values are sun4u, i86pc, and prep. A list of systems and their corresponding platform group is presented in the Solaris Sun Hardware Platform Guide at http://docs.sun.com.

A system's platform group.

If you have a system that is already installed, the arch -k command or the uname -m command reports the system's platform group.

memsize

physical_mem

The value must be a range of Mbytes, x-x, or a single Mbyte value.

A system's physical memory size in Mbytes.

Example:

memsize 64-128

The example tries to match a system with a physical memory size between 64 and 128 Mbytes.

If you have a system that is already installed, the output of the prtconf command, line 2, reports the system's physical memory size.

model

actual_platform_name

A system's platform name. See the Solaris Sun Hardware Platform Guide at http://docs.sun.com for a list of valid platform names.

To find the platform name of an installed system, use the uname -i command or the output of the prtconf command, line 5.

Note –

If the actual_platform_name contains spaces, you must replace spaces with underscores (_).

Example:

SUNW,Sun_4_50

network

network_num

A system's network number, which the JumpStart program determines by performing a logical AND between the system's IP address and the subnet mask.

Example:

network 192.168.2.0

The example tries to match a system with a 192.168.2.8 IP address, if the subnet mask is 255.255.255.0.

osname

Solaris_x

A version of Solaris software that is already installed on a system.

Example:

osname Solaris 10

In the example, the JumpStart program attempts to match a system with the Solaris 10 5/08 OS already installed.

probe

probe_keyword

A valid probe keyword or a valid custom probe keyword.

Example:

probe disks

The example returns the size of a system's disks in Mbytes and in kernel probe order, for example, c0t3d0s1, c0t4d0s0, on a SPARC based system. The JumpStart program sets the SI_DISKLIST, SI_DISKSIZES, SI_NUMDISKS, and SI_TOTALDISK environment variables.

Note –

The probe keyword is unique in that the keyword does not attempt to match an attribute and run a profile. The probe keyword returns a value. Consequently, you cannot specify begin scripts, profiles, and finish scripts with the probe rule keyword.

Probe keywords are described in Chapter 5, Creating Custom Rule and Probe Keywords (Tasks).

totaldisk

size_range

The value must be specified as a range of Mbytes (x-x).

Note –

When calculating size_range, remember that one Mbyte equals 1,048,576 bytes. A disk might be advertised as a “535–Mbyte” disk, but the disk might have only 510 million bytes of disk space. The JumpStart program views the “535–Mbyte” disk as a 510–Mbyte disk because 535,000,000 / 1,048,576 = 510. A “535–Mbyte” disk does not match a size_range equal to 530–550.

The total disk space on a system in Mbytes. The total disk space includes all the operational disks that are attached to a system.

Example:

totaldisk 300-500

In the example, the JumpStart program tries to match a system with a total disk space between 300 and 500 Mbytes.

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 8–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.

Table 8–2 Profile Keywords Overview


	Installation Scenarios
Profile Keyword	Standalone System (Nonnetworked)	Standalone System (Networked) or Server	OS Server	Upgrade	Upgrade With Disk Space Reallocation
`archive_location` (installing Solaris Flash archives)	X	X
`backup_media`					X
`boot_device`	X	X	X
`bootenv createbe`	X	X	X
`client_arch`			X
`client_root`			X
`client_swap`			X
`cluster` (adding software groups)	X	X	X
`cluster` (adding or deleting clusters)	X	X	X	X	X
`dontuse`	X	X	X
`fdisk` (x86 only)	X	X	X
`filesys` (mounting remote file systems)		X	X
`filesys` (creating local file systems)	X	X	X
`filesys` (creating mirrored file systems)	X	X	X
`forced_deployment` (installing Solaris Flash differential archives)	X	X
`geo`	X	X	X	X	X
`install_type`	X	X	X	X	X
`layout_constraint`					X
`local_customization` (installing Solaris Flash archives)	X	X
`locale`	X	X	X	X	X
`metadb` (creating state database replicas)	X	X	X
`no_master_check` (installing Solaris Flash differential archives)	X	X
`no_content_check` (installing Solaris Flash differential archives)	X	X
`num_clients`			X
`package`	X	X	X	X	X
`partitioning`	X	X	X
`patch`	X	X	X	X	X
`root_device`	X	X	X	X	X
`system_type`	X	X	X
`usedisk`	X	X	X

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.

location

Specifics for locations are noted in the following sections.

Caution –

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 8–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.

Table 8–3 Optional Keywords to Use With archive_location HTTP


Keyword	Value Definition
`auth basic` `user_name password`	If the archive is located on an HTTP server that is password protected, you must include the user name and password that you need to access the HTTP server in the profile file. Note – The use of this authentication method in a profile that is intended for use with custom JumpStart is risky. Unauthorized users might have access to the profile file that contains the password.
`timeout` `min`	The `timeout` keyword enables you to specify, in minutes, the maximum length of time that is allowed to pass without receipt of data from the HTTP server. If a timeout occurs, the connection is closed, reopened, and resumed. If you specify a `timeout` value of 0 (zero), the connection is not reopened. If a timeout reconnection occurs, the Solaris Flash installation utilities attempt to resume the installation at the last known position in the archive. If the Solaris Flash installation utilities cannot resume the installation at the last known position, the retrieval restarts from the beginning of the archive and the data that was retrieved prior to the timeout is discarded. If a timeout reconnection occurs while a package is being installed, the package is retried from the beginning of the package and the data that was retrieved prior to the timeout is discarded.
`proxy` `host:port`	The `proxy` keyword enables you to specify a proxy host and proxy port. You can use a proxy host to retrieve a Solaris Flash archive from the other side of a firewall. You must supply a proxy port when you specify the `proxy` keyword.

Example 8–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

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.

Table 8–4 Optional Keywords to Use With archive_location FTP


Keyword	Value Definition
`timeout` `min`	The `timeout` keyword enables you to specify, in minutes, the maximum length of time that is allowed to pass without receipt of data from the HTTP server. If a timeout occurs, the connection is closed, reopened, and resumed. If you specify a `timeout` value of 0 (zero), the connection is not reopened. If a timeout reconnection occurs, the Solaris Flash installation utilities attempt to resume the installation at the last known position in the archive. If the Solaris Flash installation utilities cannot resume the installation at the last known position, the retrieval restarts from the beginning of the archive and the data that was retrieved prior to the timeout is discarded. If a timeout reconnection occurs while a package is being installed, the package is retried from the beginning of the package and the data that was retrieved prior to the timeout is discarded.
`proxy` `host:port`	The `proxy` keyword enables you to specify a proxy host and proxy port. You can use a proxy host to retrieve a Solaris Flash archive from the other side of a firewall. You must supply a proxy port when you specify the `proxy` keyword.

Example 8–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 8–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.

Note –

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 8–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 8–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.

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.

Valid `type` Value	Valid `path` Value	Specification
`local_tape`	`/dev/rmt/n`	A local tape drive on the system that is being upgraded. `path` must be the character (raw) device path for the tape drive. `n` is the number of the tape drive.
`local_diskette`	`/dev/rdisketten`	A local diskette drive on the system that is being upgraded. `path` must be the character (raw) device path for the diskette drive. `n` is the number of the diskette drive. Diskettes that you use for the backup must be formatted.
`local_filesystem`	`/dev/dsk/cwtxdysz` `/file_system`	A local file system on the system that is being upgraded. You cannot specify a local file system that is being changed by the upgrade. `path` can be a block device path for a disk slice. For example, the `tx` in `/dev/dsk/cwtxdysz` might not be needed. Or, `path` can be the absolute path to a file system that is mounted by the `/etc/vfstab` file.
`remote_filesystem`	`host:/file_system`	An NFS file system on a remote system. `path` must include the name or IP address of the remote system, `host`, and the absolute path to the NFS file system, `file_system`. The NFS file system must have read/write access.
`remote_system`	`user@host:/directory`	A directory on a remote system that can be reached by a remote shell, `rsh`. The system that is being upgraded must have access to the remote system through the remote system's `.rhosts` file. `path` must include the name of the remote system `host` and the absolute path to the directory `directory`. If a user login ID `user` is not specified, `root` is used by default.

Example 8–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 8–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:

For an example of a profile	Example 3–11
For background about using Solaris Live Upgrade that creates, upgrades, and activates inactive boot environments	Chapter 2, Solaris Live Upgrade (Overview), in Solaris 10 5/08 Installation Guide: Solaris Live Upgrade and Upgrade Planning
For background about using a Solaris Flash archive	Chapter 1, Solaris Flash (Overview), in Solaris 10 5/08 Installation Guide: Solaris Flash Archives (Creation and Installation)

`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.

Note –

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.

Note –

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.

Note –

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

Example 8–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 8–5 shows how the size of swap is determined during a custom JumpStart installation.

Table 8–5 Determining swap Size


Physical Memory (in Mbytes)	Swap Space (in Mbytes)
16–64	32
64–128	64
128–512	128
Greater than 512	256

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 8–5.

Note –

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.

Note –

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.

Software Group	group_name
Reduced Network Support Software Group	`SUNWCrnet`
Core System Support Software Group	`SUNWCreq`
End User Solaris Software Group	`SUNWCuser`
Developer Solaris Software Group	`SUNWCprog`
Entire Solaris Software Group	`SUNWCall`
Entire Solaris Software Group Plus OEM Support	`SUNWCXall`

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 in Solaris 10 5/08 Installation Guide: Planning for Installation and Upgrade.

`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.

Note –

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.

Note –

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 where the installation takes place. The root disk 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 naming 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 naming 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 8–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.

Note –

The root disk is determined by the JumpStart program and determines where the OS is to be installed. The rules file uses a probe keyword "rootdisk,” but this keyword is used differently than the "rootdisk" keyword used in the JumpStart profile. You cannot set the place of installation by using the probe keyword “rootdisk” in the rules file. The probe keyword, rootdisk, determines where to boot from during the installation. See Table 8–10.

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.

Note –

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 in Solaris 10 5/08 Installation Guide: Planning for Installation and 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 8, Creating RAID-1 Volumes (Mirrors) During Installation (Overview), in Solaris 10 5/08 Installation Guide: Planning for Installation and Upgrade.

`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.

Caution –

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.

Value	Description
`N_Africa`	Northern Africa, including Egypt
`C_America`	Central America, including Costa Rica, El Salvador, Guatemala, Mexico, Nicaragua, Panama
`N_America`	North America, including Canada, United States
`S_America`	South America, including Argentina, Bolivia, Brazil, Chile, Colombia, Ecuador, Paraguay, Peru, Uruguay, Venezuela
`Asia`	Asia, including Japan, Republic of Korea, People's Republic of China, Taiwan, Thailand
`Ausi`	Australasia, including Australia, New Zealand
`C_Europe`	Central Europe, including Austria, Czech Republic, Germany, Hungary, Poland, Slovakia, Switzerland
`E_Europe`	Eastern Europe, including Albania, Bosnia, Bulgaria, Croatia, Estonia, Latvia, Lithuania, Macedonia, Romania, Russia, Serbia, Slovenia, Turkey
`N_Europe`	Northern Europe, including Denmark, Finland, Iceland, Norway, Sweden
`S_Europe`	Southern Europe, including Greece, Italy, Portugal, Spain
`W_Europe`	Western Europe, including Belgium, France, Great Britain, Ireland, Netherlands
`M_East`	Middle East, including Israel

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

Note –

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.

Note –

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

Note –

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.

Limitation	Description
This keyword is used only with upgrade option.	You can use `layout_constraint` only for the upgrade option when you need to reallocate disk space.
If you do not specify the `layout_constraint` keyword	The JumpStart program lays out the disk as follows: File systems that require more space for the upgrade are marked changeable. File systems that are on the same disk as the file system that requires more space and that are mounted by the `/etc/vfstab` file are marked changeable. Remaining file systems are marked fixed because auto-layout cannot change the file systems.
If you specify one or more `layout_constraint` keywords	The JumpStart program lays out the disk as follows: File systems that require more space for the upgrade are marked changeable. File systems for which you specified a `layout_constraint` keyword are marked with the specified constraint. The remaining file systems are marked fixed.
If the file system is not marked changeable	You cannot change the constraint on file systems that require more space for the upgrade because the file systems must be marked changeable. You can use the `layout_constraint` keyword to change the `minimum_size` values on file systems that require more space for the upgrade.
If file systems require more space for upgrade	To help auto-layout reallocate space, select more file systems to be changeable or movable, especially those file systems that are located on the same disks as the file systems that require more space for the upgrade.

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 8–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 5/08 Installation Guide: Solaris Flash Archives (Creation and Installation).

`locale` Profile Keyword

locale locale_name

Note –

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.

`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 in Solaris 10 5/08 Installation Guide: Planning for Installation and Upgrade.

`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.

Caution –

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.

Note –

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.

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 8–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/. If a mount fails, the NFS mount is tried five times.

package SUNWnew add nfs golden:/packages/Solaris_10 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.

Table 8–6 Optional package Keywords to Use With HTTP


Keyword	Value Definition
`timeout` `min`	The `timeout` keyword enables you to specify, in minutes, the maximum length of time that is allowed to pass without receipt of data from the HTTP server. If a timeout occurs, the connection is closed, reopened, and resumed. If you specify a `timeout` value of 0 (zero), the connection is not reopened. If a timeout reconnection occurs, the package is retried from the beginning of the package and the data that was retrieved prior to the timeout is discarded.
`proxy` `host:port`	The `proxy` keyword enables you to specify a proxy host and proxy port. You can use a proxy host to retrieve a Solaris package from the other side of a firewall. You must supply a proxy port when you specify the `proxy` keyword.

Example 8–13 Adding a Package by Using HTTP

In this example, the package profile keyword adds all the packages listed in the Solaris 10 directory from the HTTP location http://package.central/Solaris_10. 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 timeout 5

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

Example 8–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 directory from the HTTP location http://package.central/Solaris_10. The package is retrieved across a firewall by using the proxy keyword.

package SUNWnew add http://package.central/Solaris_10 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 8–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/Product from the local device c0t6d0s0. This is a UFS file system.

package SUNWnew add local_device c0t6d0s0 /Solaris_10/Product ufs

Example 8–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/Product from the local device c0t6d0s0. This is an HSFS file system.

package SUNWnew add local_device c0t6d0s0 /Solaris_10/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 8–17 Adding a Package by Using a Local File

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

package SUNWnew add local_file /Solaris_10/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.

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 8–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/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/patches retry 5

Example 8–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/patches on the server patch_master.

patch 112467-01,112765-02 nfs patch_master:/Solaris/v10/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

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.

Table 8–7 Optional patch Keywords to Use With HTTP


Keyword	Value Definition
`timeout` `min`	The `timeout` keyword enables you to specify, in minutes, the maximum length of time that is allowed to pass without receipt of data from the HTTP server. If a timeout occurs, the connection is closed, reopened, and resumed. If you specify a `timeout` value of 0 (zero), the connection is not reopened. If a timeout reconnection occurs, the package is retried from the beginning of the package and the data that was retrieved prior to the timeout is discarded.
`proxy` `host:port`	The `proxy` keyword enables you to specify a proxy host and proxy port. You can use a proxy host to retrieve a Solaris package from the other side of a firewall. You must supply a proxy port when you specify the `proxy` keyword.

Example 8–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/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/patches timeout 5

Example 8–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/patches.

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

Patches Stored on a Local Device

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 8–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/patches from the local device c0t6d0s0. The patch file determines the order of patches to be installed.

patch patch_file c0t6d0s0 /Solaris_10/patches

Example 8–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/patches from local device c0t6d0s0.

patch 112467-01,112765-02 local_device c0t6d0s0 /Solaris_10/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 8–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/patches directory. The patch file determines the order of patches to be installed.

patch patch_cal_file /Solaris_10/patches

Example 8–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/patches.

patch 112467-01,112765-02 local_file /Solaris_10/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.

Note –

The root disk is determined by the JumpStart program and determines where the OS is to be installed. The rules file uses a probe keyword "rootdisk," but this keyword is used differently than the "rootdisk" keyword used in the JumpStart profile. You cannot set the place of installation by using the probe keyword “rootdisk” in the rules file. The probe keyword, rootdisk, determines where to boot from during the installation. See Table 8–10.

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 8–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 8–8 describes how the JumpStart program determines the system's root disk for the installation.

Note –

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.

Table 8–8 How JumpStart Determines a System's Root Disk (Initial Installation)


Stage	Action
1	If the `root_device` keyword is specified in the profile, the JumpStart program sets `rootdisk` to the root device.
2	If `rootdisk` is not set and the `boot_device` keyword is specified in the profile, the JumpStart program sets `rootdisk` to the boot device.
3	If `rootdisk` is not set and a `filesys cwtxdysz` `size` `/` entry is specified in the profile, the JumpStart program sets `rootdisk` to the disk that is specified in the entry.
4	If `rootdisk` is not set and a `rootdisk.sn` entry is specified in the profile, the JumpStart program searches the system's disks in kernel probe order for an existing root file system on the specified slice. If a disk is found, the JumpStart program sets `rootdisk` to the found disk.
5	If `rootdisk` is not set and `partitioning existing` is specified in the profile, the JumpStart program searches the system's disks in kernel probe order for an existing root file system. If a root file system is not found or more than one is found, an error occurs. If a root file system is found, the JumpStart program sets `rootdisk` to the found disk.
6	If `rootdisk` is not set, the JumpStart program sets `rootdisk` to the disk where the root (`/`) file system is installed.

`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.

Note –

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

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 8–9 describes these variables and their values.

Table 8–9 Installation Environment Variables


Environment Variable	Value
`SI_ARCH`	The hardware architecture of the install client. The `SI_ARCH` variable is set when the `arch` keyword is used in the `rules` file.
`SI_BEGIN`	The name of the begin script, if one is used.
`SI_CLASS`	The name of the profile that is used to install the install client.
`SI_DISKLIST`	A comma-separated list of disk names on the install client. The `SI_DISKLIST` variable is set when the `disksize` keyword is used and matched in the `rules` file. The `SI_DISKLIST` and `SI_NUMDISKS` variables are used to determine the physical disk to use for the `rootdisk`. `rootdisk` is described in How the System's Root Disk Is Determined.
`SI_DISKSIZES`	A comma-separated list of disk sizes on the install client. The `SI_DISKSIZES` variable is set when the `disksize` keyword is used and matched in the `rules` file.
`SI_DOMAINNAME`	The domain name. The `SI_DOMAINNAME` variable is set when the `dommainname` keyword is used and matched in the `rules` file.
`SI_FINISH`	The name of the finish script, if one is used.
`SI_HOSTADDRESS`	The install client's IP address.
`SI_HOSTNAME`	The install client's host name. The `SI_HOSTNAME` variable is set when the `hostname` keyword is used and matched in the `rules` file.
`SI_INSTALLED`	The device name of a disk with a specific operating system on the disk, for example, Solaris, SunOS, or System V. The `SI_INSTALLED` variable is set when the `installed` keyword is used and matched in the `rules` file. `SI_INST_OS` and `SI_INST_VER` are used to determine the value of `SI_INSTALLED`.
`SI_INST_OS`	The name of the operating system. `SI_INST_OS` and `SI_INST_VER` are used to determine the value of `SI_INSTALLED`.
`SI_INST_VER`	The version of the operating system. `SI_INST_OS` and `SI_INST_VER` are used to determine the value of `SI_INSTALLED`.
`SI_KARCH`	The install client's kernel architecture. The `SI_KARCH` variable is set when the `karch` keyword is used and matched in the `rules` file.
`SI_MEMSIZE`	The amount of physical memory on the install client. The `SI_MEMSIZE` variable is set when the `memsize` keyword is used and matched in the `rules` file.
`SI_MODEL`	The install client's model name. The `SI_MODEL` variable is set when the `model` keyword is used and matched in the `rules` file.
`SI_NETWORK`	The install client's network number. The `SI_NETWORK` variable is set when the `network` keyword is used and matched in the `rules` file.
`SI_NUMDISKS`	The number of disks on an install client. The `SI_NUMDISKS` variable is set when the `disksize` keyword is used and matched in the `rules` file. The `SI_NUMDISKS` and `SI_DISKLIST` variables are used to determine the physical disk to use for the `rootdisk`. `rootdisk` is described in How the System's Root Disk Is Determined.
`SI_OSNAME`	The operating system release on the Solaris software image. For example, you can use the `SI_OSNAME` variable in a script if you are installing the Solaris software on systems that are based on the version of the operating system on the Solaris Operating System DVD or the Solaris Software - 1 CD image.
`SI_ROOTDISK`	The device name of the disk that is represented by the logical name `rootdisk`. The `SI_ROOTDISK` variable is set when the `disksize` or the `installed` keyword is set to `rootdisk` in the `rules` file. The `SI_ROOTDISK` variable sets the device to boot from during the installation. Note – You cannot set the place of installation by using the probe keyword “`rootdisk`” in the rules file. For information on the "`rootdisk`" variable that is set in a JumpStart profile, see How the System's Root Disk Is Determined.
`SI_ROOTDISKSIZE`	The size of the disk that is represented by the logical name `rootdisk`. The `SI_ROOTDISKSIZE` variable is set when the `disksize` or the `installed` keyword is set to `rootdisk` in the `rules` file.
`SI_TOTALDISK`	The total amount of disk space on the install client. The `SI_TOTALDISK` variable is set when the `totaldisk` keyword is used and matched in the `rules` file.

Probe Keywords and Values

Table 8–10 describes each rule keyword and its equivalent probe keyword.

Note –

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

Table 8–10 Descriptions of Probe Keywords


Rule Keyword	Equivalent Probe Keyword	Description of Probe Keyword
`any`	None
`arch`	`arch`	Determines the kernel architecture, i386 or SPARC, and sets `SI_ARCH`.
`disksize`	`disks`	Returns the size of a system's disks in Mbytes in kernel probe order, c0t3d0s0, c0t3d0s1, c0t4d0s0. `disksize` sets `SI_DISKLIST`, `SI_DISKSIZES`, `SI_NUMDISKS`, and `SI_TOTALDISK`.
`domainname`	`domainname`	Returns a system's NIS or NIS+ domain name or blank and sets `SI_DOMAINNAME`. The `domainname` keyword returns the output of domainname(1M).
`hostaddress`	`hostaddress`	Returns a system's IP address, the first address that is listed in the output of ifconfig(1M) `-a` that is not lo0, and sets `SI_HOSTADDRESS`.
`hostname`	`hostname`	Returns a system's host name that is the output from uname(1) `-n` and sets `SI_HOSTNAME`.
`installed`	`installed`	Returns the version name of the Solaris OS that is installed on a system and sets `SI_ROOTDISK` and `SI_INSTALLED`. If the JumpStart program finds a Solaris release but is unable to determine the version, the version that is returned is `SystemV`.
`karch`	`karch`	Returns a system's platform group, for example i86pc or sun4u, and sets `SI_KARCH`. For a list of platform names, see Solaris Sun Hardware Platform Guide at `http://docs.sun.com`.
`memsize`	`memsize`	Returns the size of physical memory on a system in Mbytes and sets `SI_MEMSIZE`.
`model`	`model`	Returns a system's platform name and sets `SI_MODEL`. For a list of platform names, see the Solaris Sun Hardware Platform Guide at `http://docs.sun.com`.
`network`	`network`	Returns a system's network number, which the JumpStart program determines by performing a logical AND between the system's IP address and the subnet mask. The system's IP address and the subnet mask are extracted from the first address that is listed in the output of ifconfig(1M) `-a` that is not lo0. The `network` keyword sets `SI_NETWORK`.
`osname`	`osname`	Returns the version and operating system name of the Solaris OS that is found on a CD and sets `SI_OSNAME`. If the JumpStart program finds a Solaris release but is unable to determine the version, the version that is returned is `SystemV`.
	`rootdisk`	Returns the name and size in Mbytes of a system's root disk and sets `SI_ROOTDISK`.
`totaldisk`	`totaldisk`	Returns the total disk space on a system (in Mbytes) and sets `SI_TOTALDISK`. The total disk space includes all of the operational disks that are attached to a system.

Chapter 8 Custom JumpStart (Reference)

Rule Keywords and Values

Profile Keywords and Values

Profile Keywords Quick Reference

Profile Keyword Descriptions and Examples

archive_location Keyword

Archive Stored on an NFS Server

Example 8–1 Archive Stored on an NFS Server

Archive Stored on an HTTP or HTTPS Server

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

Archive Stored on an FTP Server

Example 8–3 Archive Stored on an FTP Server

Archive Stored on a Local Tape

Example 8–4 Archive Stored on a Local Tape

Archive Stored on a Local Device

Example 8–5 Archive Stored on a Local Device

Archive Stored on a Local File

Example 8–6 Archive Stored on a Local File

backup_media Profile Keyword

Example 8–7 backup_media Profile Keyword

boot_device Profile Keyword

Example 8–8 boot_device Profile Keyword

bootenv createbe Profile Keyword

client_arch Profile Keyword

client_root Profile Keyword

client_swap Profile Keyword

Example 8–9 client_swap Profile Keyword

How the Size of swap Is Determined

cluster Profile Keyword (Adding Software Groups)

cluster Profile Keyword (Adding or Deleting Clusters)

dontuse Profile Keyword

x86: fdisk Profile Keyword

filesys Profile Keyword (Mounting Remote File Systems)

Example 8–10 filsys Profile Keyword

filesys Profile Keyword (Creating Local File Systems)

filesys Profile Keyword (Creating RAID-1 Volumes)

forced_deployment Profile Keyword (Installing Solaris Flash Differential Archives)

geo Profile Keyword

install_type Profile Keyword

layout_constraint Profile Keyword

Example 8–11 layout_constraint Profile Keyword

local_customization Profile Keyword (Installing Solaris Flash Archives)

locale Profile Keyword

metadb Profile Keyword (Creating State Database Replicas)

no_content_check Profile Keyword (Installing Solaris Flash Archives)

no_master_check Profile Keyword (Installing Solaris Flash Archives)

num_clients Profile Keyword

package Profile Keyword

Packages Stored on an NFS Server

Example 8–12 Adding a Package by Using NFS

Packages Stored on an HTTP Server

Example 8–13 Adding a Package by Using HTTP

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

Packages Stored on a Local Device

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

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

Packages Stored on a Local File

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

Limitations When Using the package Keyword

Upgrade Behavior When Using the package Keyword

partitioning Profile Keyword

patch Profile Keyword

Patches Stored on an NFS Server

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

Example 8–19 Adding a Patch by Using NFS

Patches Stored on an HTTP Server

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

Example 8–21 Adding a Patch by Using HTTP

Patches Stored on a Local Device

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

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

Patches Stored on a Local File

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

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

Limitations When Using the patch Keyword

root_device Profile Keyword

Example 8–26 root_device Profile Keyword

How the System's Root Disk Is Determined

system_type Profile Keyword

usedisk Profile Keyword

`archive_location` Keyword

`backup_media` Profile Keyword

Example 8–7 `backup_media` Profile Keyword

`boot_device` Profile Keyword

Example 8–8 `boot_device` Profile Keyword

`bootenv createbe` Profile Keyword

`client_arch` Profile Keyword

`client_root` Profile Keyword

`client_swap` Profile Keyword

Example 8–9 `client_swap` Profile Keyword

How the Size of `swap` Is Determined

`cluster` Profile Keyword (Adding Software Groups)

`cluster` Profile Keyword (Adding or Deleting Clusters)

`dontuse` Profile Keyword

x86: `fdisk` Profile Keyword

`filesys` Profile Keyword (Mounting Remote File Systems)

Example 8–10 `filsys` Profile Keyword

`filesys` Profile Keyword (Creating Local File Systems)

`filesys` Profile Keyword (Creating RAID-1 Volumes)

`forced_deployment` Profile Keyword (Installing Solaris Flash Differential Archives)

`geo` Profile Keyword

`install_type` Profile Keyword

`layout_constraint` Profile Keyword

Example 8–11 `layout_constraint` Profile Keyword

`local_customization` Profile Keyword (Installing Solaris Flash Archives)

`locale` Profile Keyword

`metadb` Profile Keyword (Creating State Database Replicas)

`no_content_check` Profile Keyword (Installing Solaris Flash Archives)

`no_master_check` Profile Keyword (Installing Solaris Flash Archives)

`num_clients` Profile Keyword

`package` Profile Keyword

Limitations When Using the `package` Keyword

Upgrade Behavior When Using the `package` Keyword

`partitioning` Profile Keyword

`patch` Profile Keyword

Limitations When Using the `patch` Keyword

`root_device` Profile Keyword

Example 8–26 `root_device` Profile Keyword

`system_type` Profile Keyword

`usedisk` Profile Keyword