Definition: Custom JumpStart Installation

A custom JumpStart installation is a type of installation in which the Solaris software is automatically installed on a system based on a user-defined profile. You can create customized profiles for different types of users.

---

Note - Appendix D, "Sample Custom JumpStart Installation" provides an example of how a fictitious site is prepared for custom JumpStart installations.

---

---

Note - Instructions in this chapter are valid for either an x86 or SPARC server that is being used for custom JumpStart installations. An x86 server can provide custom JumpStart files for SPARC systems, and a SPARC system can provide custom JumpStart files for x86 systems.

---

Reasons to Choose a Custom JumpStart Installation

You should choose custom JumpStart installations when you have to install Solaris software on:

• Many systems.
• Particular groups of systems.

For example, the following scenario would be ideal for performing custom JumpStart installations:

• You need to install the Solaris software on 100 new systems.
• The engineering group owns 70 out of the 100 new systems, and its systems must be installed as standalone systems with the developer software group.
• The marketing group owns 30 out of the 100 new systems, and its systems must be installed as standalone clients with the end user software group.

These installations would be time-consuming and tedious if you chose to perform an interactive installation on each system.

Tasks to Prepare for Custom JumpStart Installations

Table 4-1 shows the tasks that are required to prepare for custom JumpStart installations.

Table 4-1

Task	Description
Creating a JumpStart directory on a diskette or on a server	You must create a JumpStart directory to hold the custom JumpStart files. If you are going to use a diskette for custom JumpStart installations, see "Creating a JumpStart Directory on a Diskette" on page 53. If you are going to use a server for custom JumpStart installations, see "Creating a JumpStart Directory on a Server" on page 62.
Enabling all clients to access the JumpStart directory	When you use a server to provide the JumpStart directory, you can enable all clients to access the JumpStart directory. See "Enabling All Systems to Access the JumpStart Directory" on page 65 for detailed information.
Creating profiles	A profile is a text file used as a template by the custom JumpStart installation software. It defines how to install the Solaris software on a system (for example, initial or upgrade installation option, system type, disk partitioning, software group), and it is named in the rules file. See "Creating a Profile" on page 67 for detailed information.
Creating a rules file	The rules file is a text file used to create the rules.ok file. The rules file is a look-up table consisting of one or more rules that define matches between system attributes and profiles. See "Creating the rules File" on page 82 for detailed information.
Using check to validate the rules file	The rules.ok file is a generated version of the rules file, and it is required by the custom JumpStart installation software to match a system to a profile. You must use the check script to create the rules.ok file. See "Using check to Validate the rules File" on page 93 for detailed information.

What Happens During a Custom JumpStart Installation

Figure 4-1 describes what happens after you boot a system to perform a custom JumpStart installation.

Figure 4-1

Figure 4-2 is an example of how a custom JumpStart installation works on a standalone, non-networked system using the system's diskette drive.

Figure 4-2

Figure 4-3 is an example of how a custom JumpStart installation works for multiple systems on a network where different profiles are accessed from a single server.

Figure 4-3

Creating a JumpStart Directory on a Diskette

You should use a diskette for a custom JumpStart installation if the system:

• Has a diskette drive
• Has a local CD-ROM drive
• Is not connected to a network

When you use a diskette for custom JumpStart installations, the JumpStart directory must be the root directory on the diskette that contains all the essential custom JumpStart installation files (for example, the rules file, rules.ok file, and profiles). The JumpStart directory should be owned by root and have permissions equal to 755.

The diskette requirements for the JumpStart directory are different for x86 and SPARC systems. So, the following pages describe how to create a JumpStart directory on a diskette for an x86 system and for a SPARC system.

· How to Create a JumpStart Directory on a Diskette for x86 Systems

Overview - The procedure to create a JumpStart directory on a diskette for x86 systems involves:

• Making a copy of the Solaris boot diskette (the copied Solaris boot diskette has a PCFS file system)
• Copying sample custom JumpStart installation files into the diskette's root directory

Follow this procedure to create a JumpStart directory on a diskette for x86 systems.

1. Log in as root on an x86 or SPARC system that has a diskette drive and a CD-ROM drive.

2. Insert the Solaris boot diskette into the diskette drive.

3. Choose the appropriate steps, depending on whether or not the system is running Volume Management:

If the System Is ...	Then ...
Running Volume Management	Go to Step 4. Note: Volume Management is running if the /vol directory on the system contains files. Systems running Solaris 2.0 or 2.1 do not have Volume Management.
Not running Volume Management	Go to Step 12.

4. Make sure Volume Management knows about the diskette:

# volcheck

5. Copy the Solaris boot diskette image to the system's hard disk:

# dd if=/vol/dev/aliases/floppy0 of=boot_image

In this command,

boot_image......Is the file name where the Solaris boot diskette image is copied. You can specify an absolute path name.

For example, the following command would copy a Solaris boot diskette to the boot_save file.

dd if=/vol/dev/aliases/floppy0 of=boot_save

6. Eject the Solaris boot diskette:

---

Note - The following command is not required for x86 systems; you must manually eject the diskette on an x86 system.

---

# eject floppy

7. Insert a blank diskette into the diskette drive.

8. Make sure Volume Management knows about the diskette:

# volcheck

9. Format the diskette:

# fdformat -d -U

10. Copy the Solaris boot diskette image from the system's hard disk to the formatted diskette:

# dd if=boot_image of=/vol/dev/aliases/floppy0

The boot_image variable should be the same as in Step 5.

11. Go to Step 17.

    Step 12 through Step 16 are used if the system is not running Volume Management.

12. Copy the Solaris boot diskette image to the system's hard disk:

# dd if=/dev/rdiskette of=boot_image

In this command,

boot_image......Is the file name where the Solaris boot diskette image is copied. You can specify an absolute path name.

For example, the following command would copy a Solaris boot diskette to the boot_save file.

dd if=/dev/rdiskette of=boot_save

13. Eject the Solaris boot diskette:

    Note - The following command is not required for x86 systems; you must manually eject the diskette on an x86 system.

# eject fd

14. Insert a blank diskette into the diskette drive.

15. Format the diskette:

# fdformat -d

16. Copy the Solaris boot diskette image from the system's hard disk to the formatted diskette:

# dd if=boot_image of=/dev/rdiskette

The boot_image variable should be the same as in Step 12.

17. Mount the diskette:

If the System Is ...	Then ...
Running Volume Management	1) Eject the copied Solaris boot diskette. 2) Insert the copied Solaris boot diskette back into the diskette drive. 3) Make sure Volume Management knows about the diskette: volcheck
Not running Volume Management	mount -F pcfs /dev/diskette jump_dir_path Note: jump_dir_path is the absolute directory path where the diskette is mounted.

18. Determine your next step based on where the Solaris CD is located.

If You Want to Use The ...	Then ...
Solaris CD in the local CD-ROM drive	1) Insert the Solaris CD into the CD-ROM drive. 2) Go to Step 19.
Solaris CD image on local disk	1) Change the directory to the Solaris CD image on the local disk. For example: cd /export/install 2) Go to Step 20.

19. Mount the Solaris CD (if needed) and change the directory to the mounted CD:

If the System Is ...	Then ...
Running Volume Management	cd /cdrom/cdrom0/s0 or cd /cdrom/cdrom0/s2
Not running Volume Management	1)mount -F hsfs -o ro /dev/dsk/c0t6d0s0 /cdrom ormount -F hsfs -o ro /dev/dsk/c0t6d0p0 /cdrom 2)cd /cdrom

20. Copy the JumpStart installation files from the auto_install_sample directory on the Solaris CD into the JumpStart directory (root directory) of the diskette:

If the System Is ...	Then ...
Running Volume Management	cp -r auto_install_sample/* /floppy/floppy0/.
Not running Volume Management	cp -r auto_install_sample/* jumpstart_dir_path Note: jump_dir_path is the absolute directory path where the diskette is mounted.

---

Note - The custom JumpStart installation files must be in the root directory of the diskette.

---

You have completed creating a JumpStart directory on the diskette. To continue, see "How to Create a Profile" on page 67.

· How to Create a JumpStart Directory on a Diskette for SPARC Systems

Overview - The procedure to create a JumpStart directory on a diskette for SPARC systems involves:

• Formatting a diskette (if needed).
• Creating a UFS file system on the diskette (if needed).
• Copying sample custom JumpStart installation files into the diskette's root directory.

Follow this procedure to create a JumpStart directory on a diskette for SPARC Systems.

1. Log in as root on a SPARC system that has a diskette drive and a CD-ROM drive.

2. Insert a diskette into the diskette drive.

3. Choose the appropriate steps, depending on whether or not the system is running Volume Management:

If the System Is ...	Then ...
Running Volume Management	Go to Step 4. Note: Volume Management is running if the /vol directory on the system contains files. Systems running Solaris 2.0 or 2.1 do not have Volume Management.
Not running Volume Management	Go to Step 12.

4. Make sure Volume Management knows about the diskette:

# volcheck

5. If the diskette already has a UFS file system on it, go to Step 16.

   To find out if the diskette has a UFS file system on it, check the /etc/mnttab file for an entry similar to this:

/floppy/unnamed_floppy   ufs

6. Format the diskette:

# fdformat -U

7. Create a UFS file system on the diskette:

# newfs /vol/dev/aliases/floppy0

8. Eject the diskette:

# eject floppy

9. Insert the formatted diskette back into the diskette drive.

10. Make sure Volume Management knows about the diskette:

# volcheck

11. Go to Step 16.

    Step 12 through Step 15 are used if the system is not running Volume Management.

12. If the diskette already has a UFS file system on it, go to Step 15.

    If the mount command fails in Step 15, the diskette does not have a UFS file system on it.

13. Format the diskette:

# fdformat /dev/rdiskette

14. Create a file system on the diskette:

# newfs /dev/rdiskette

15. Mount the diskette:

# mount -F ufs /dev/diskette jumpstart_dir_path

In this command,

jumpstart_dir_path Is the absolute directory path where the diskette is mounted.

For example, the following command would mount a SPARC diskette on the /mnt directory:

mount -F ufs /dev/rdiskette /mnt

---

Note - If the mount command fails, go back to Step 13 to format the diskette.

---

16. Determine your next step based on where the Solaris CD is located.

If You Want to Use The ...	Then ...
Solaris CD in the local CD-ROM drive	1) Insert the Solaris CD into the CD-ROM drive. 2) Go to Step 17.
Solaris CD image on the local disk	1) Change the directory to the Solaris CD image on the local disk. For example: cd /export/install 2) Go to Step 18.

17. Mount the Solaris CD (if needed) and change the directory to the mounted CD:

If the System Is ...	Then ...
Running Volume Management	cd /cdrom/cdrom0/s0 or cd /cdrom/cdrom0/s2
Not running Volume Management	1)mount -F hsfs -o ro /dev/dsk/c0t6d0s0 /cdrom ormount -F hsfs -o ro /dev/dsk/c0t6d0p0 /cdrom 2)cd /cdrom

18. Copy the custom JumpStart installation files from the

    auto_install_sample directory on the Solaris CD into the JumpStart directory (root directory) of the diskette:

If the System Is ...	Then ...
Running Volume Management	cp -r auto_install_sample/* /floppy/floppy0/.
Not running Volume Management	cp -r auto_install_sample/* jumpstart_dir_path Note: jump_dir_path is the absolute directory path where the diskette is mounted.

---

Note - The custom JumpStart installation files must be in the root directory of the diskette.

---

You have completed creating a JumpStart directory on the diskette. To continue, see "How to Create a Profile" on page 67.

Creating a JumpStart Directory on a Server

If you want to perform custom JumpStart installations by using a server on the network, you must create a JumpStart directory on the server. When you use a server for custom JumpStart installations, the JumpStart directory is a directory

on the server that contains all the essential custom JumpStart files (for example, the rules file, rules.ok file, and profiles). The JumpStart directory should be owned by root and have permissions equal to 755.

· How to Create a JumpStart Directory on a Server

Overview - The procedure to create a JumpStart directory on a server involves:

• Creating a directory on the server
• Editing the /etc/dfs/dfstab file
• Copying sample custom JumpStart installation files into the directory on the server

Follow this procedure to create a JumpStart directory on a server.

1. Log in as root on the server where you want the JumpStart directory to reside.

2. Create the JumpStart directory anywhere on the server:

# mkdir jumpstart_dir_path

In this command,

jumpstart_dir_path..Is the absolute path of the JumpStart directory.

For example, the following command would create the directory called jumpstart in the root file system:

  mkdir /jumpstart

3. Edit the /etc/dfs/dfstab file. Add the following entry:

share -F nfs -o ro,anon=0 jumpstart_dir_path

For example, the following entry would be correct for the example shown in Step 2:

  share -F nfs -o ro,anon=0 /jumpstart

4. Type unshareall and press Return.

5. Type shareall and press Return.

6. Determine your next step based on where the Solaris CD is located.

If You Want to Use The ...	Then ...
Solaris CD in the local CD-ROM drive	1) Insert the Solaris CD into the CD-ROM drive. 2) Go to Step 7.
Solaris CD image on the local disk	1) Change the directory to the Solaris image on the local disk. For example: cd /export/install 2) Go to Step 8.

7. Mount the Solaris CD (if needed) and change the directory to the mounted CD:

If the System Is ...	Then ...
Running Volume Management	cd /cdrom/cdrom0/s0 orcd /cdrom/cdrom0/s2 Note: Volume Management is running if the /vol directory on the system contains files. Systems running Solaris 2.0 or 2.1 do not have Volume Management.
Not running Volume Management	1)mount -F hsfs -o ro /dev/dsk/c0t6d0s0 /cdrom ormount -F hsfs -o ro /dev/dsk/c0t6d0p0 /cdrom 2)cd /cdrom

8. Copy the contents of the auto_install_sample directory from the Solaris CD-ROM into the JumpStart directory:

# cp -r auto_install_sample/* jumpstart_dir_path

For example, the following command would copy the auto_install_sample directory into the JumpStart directory created in Step 2:

cp -r auto_install_sample/* /jumpstart

You have completed creating a JumpStart directory on the server. To continue, see "How to Create a Profile" on page 67.

Enabling All Systems to Access the JumpStart Directory

When you create a JumpStart directory on a server, you must make sure systems can access it during a custom JumpStart installation. There are two ways to do this:

• Using the -c option of the add_install_client command every time you add a system for network installation.

  or

• Enabling all systems to access the JumpStart directory.

To save you time when adding systems for network installations, use the following procedure to enable all systems to access the JumpStart directory from a server.

---

Note - The following procedure is not necessary if you are using a diskette for the JumpStart directory.

---

· How to Enable All Systems to Access the JumpStart Directory

Overview - The procedure to enable all systems to access the JumpStart directory from a server involves:

• Editing the /etc/bootparams file
• Updating the name service (NIS or NIS+) with the information you've added to the /etc/bootparams file

Follow this procedure to enable all systems to access the JumpStart directory from a server.

1. On the NIS or NIS+ master server, log in as root.

2. Edit the /etc/bootparams file or create the /etc/bootparams file if it does not exist. Add the following entry:

* install_config=server:jumpstart_dir_path

In this entry,

*	Is a wildcard character specifying all systems.
server	Is the host name of the server where the JumpStart directory is located.
jumpstart_dir_path	Is the absolute path of the JumpStart directory.

For example, the following entry would enable all systems to access the /jumpstart directory on the server named sherlock:

    * install_config=sherlock:/jumpstart

---

Caution - Using this procedure may produce the following error message when booting an install client:

WARNING: getfile: RPC failed: error 5: (RPC Timed out). See page 173 for more details on this error message.

---

3. Update the NIS or NIS+ tables (if necessary) with the information you added to the /etc/bootparams files.

If Your Site Uses ...	Then ...
NIS	/var/yp/make
NIS+	/usr/lib/nis/nispopulate -F -p /etc bootparams
No name service	Go to Task Complete on page 67.

All systems can now access the JumpStart directory. You no longer need to use the -c option of the add_install_client command when adding systems for network installations.

Creating a Profile

What Is a Profile

A profile is a text file used as a template by the custom JumpStart installation software. It defines how to install the Solaris software on a system (for example, initial or upgrade installation option, system type, disk partitioning, software group), and it is named in the rules file.

A profile consists of one or more profile keywords and their values. Each profile keyword is a command that controls one aspect of how the Solaris installation program will install the Solaris software on a system. For example, the profile keyword and value

system_type  server

tells the Solaris installation program to install the system as a server.

---

Note - If you created the JumpStart directory by using the procedures on page 53 or page 62, example profiles should already be in the JumpStart directory.

---

Requirements for Profiles

The following are requirements when creating a profile:

• The install_type profile keyword is required.
• Only one profile keyword can be on a line.

· How to Create a Profile

Overview - The procedure to create a profile involves:

• Editing a file

• Selecting profile keywords and profile values to define how to install the Solaris software on a system

Follow this procedure to create as many profiles as you need for your site.

1. Open a file (the profile) and give it a descriptive name.

   You can create a new file or edit one of the sample profiles in the JumpStart directory you created.

   The name of a profile should reflect how it will install the Solaris software on a system (for example, basic_install, eng_profile, or user_profile).

2. Add profile keywords and profile values to the profile.

   Be aware of these things as you edit the profile:

• Profile Examples on page 69 provides some examples of profiles.
• Table 4-2 on page 72 provides the list of valid profile keywords and values.
• You can have as many lines in the profile as necessary to define how to install the Solaris software on a system.
• You can add a comment after the pound sign (#) anywhere on a line. If a line begins with a #, the entire line is a comment line. If a # is specified in the middle of a line, everything after the # is considered a comment. Blank lines are also allowed in a profile.
• The profile keywords and their values are case sensitive.
• Profiles should be owned by root and have permissions equal to 644.

---

Note - See "Using pfinstall to Test Profiles" on page 104 for detailed information about testing profiles.

---

This completes the procedure to create a profile. To continue setting up for a custom JumpStart installation, see How to Create the rules File on page 83.

Profile Examples

The following profile examples describe how you can use different profile keywords and profile values to control how the Solaris software is installed on a system. See Table 4-2 on page 72 for the list of profile keywords and profile values.

# profile keywords profile values # ---------------- ------------------- (1) install_type initial_install (2) system_type standalone (3) partitioning default filesys any 60 swap # specify size of /swap filesys s_ref:/usr/share/man - /usr/share/man ro filesys s_ref:/usr/openwin/share/man - /usr/openwin/share/man ro,quota (4) cluster SUNWCprog (5) package SUNWman delete package SUNWolman delete package SUNWxwman delete package SUNWoldem add package SUNWxwdem add package SUNWoldim add package SUNWxwdim add

(1)

This profile keyword is required in every profile.

(2)This profile keyword defines that the system will be installed as a standalone system.

(3)The file system slices are determined by the software to be installed (default value); however, the size of swap is set to 60 Mbytes and it is installed on any disk (any value). The standard and OpenWindows man pages are mounted from the file server, s_ref, on the network. (4)The developer software group (SUNWCprog) is installed on the system.

(5)Because the man pages are being mounted remotely, those packages are selected not to be installed on the system; however, the packages containing the OpenLook and X Windows demo programs and images are selected to be installed on the system.

# profile keywords profile values # ---------------- ------------------- install_type initial_install system_type standalone (1) partitioning default filesys c0t0d0s0 auto / filesys c0t3d0s1 32 swap (2) cluster SUNWCall

(1)

The file system slices are determined by the software to be installed (default value). However, the size of root is based on the selected software (auto value) and it is installed on c0t0d0s0, and the size of swap is set to 32 Mbytes and it is installed on c0t3d0s1.

(2)The entire distribution software group (SUNWCall) is installed on the system.

# profile keywords profile values # ---------------- ------------------- install_type initial_install system_type standalone (1) fdisk c0t0d0 0x04 delete (2) fdisk c0t0d0 solaris maxfree (3) cluster SUNWCall (4) cluster SUNWCacc delete

(1)

All fdisk partitions of type DOSOS16 (04 hexadecimal) are deleted from the c0t0d0 disk.

(2)A Solaris fdisk partition is created on the largest contiguous free space on the c0t0d0 disk.

(3)The entire distribution software group (SUNWCall) is installed on the system.

(4)

The system accounting utilities (SUNWCacc) are selected not to be installed on the system.

# profile keywords profile values # ---------------- ------------------- (1) install_type upgrade (2) package SUNWbcp delete (3) package SUNWolman add package SUNWxwman add cluster SUNWCumux add (4) locale de

(1)

This profile upgrades a system (SPARC only).

(2)The binary compatibility package (SUNWbcp) is selected to be deleted from the system or prevented from being installed.

(3)This code ensures that the OpenLook and X Windows man pages and the universal multiplexor software are selected to be installed if they are not installed on the system. (All packages already on the system are automatically upgraded.)

(4)

The German localization packages are selected to be installed on the system.

Profile Keyword and Profile Value Descriptions

Table 4-2 shows the profile keywords and profile values that you can use in a profile.

Table 4-2 (1 of 10)

Profile Keyword	Profile Values and Description
client_arch	karch_value client_arch defines that the server will support a different platform group than it uses. If you do not specify client_arch, any diskless client must have the same platform group as the server. You must specify client_arch once for each platform group. Valid values for karch_value are sun4d, sun4c, sun4m, or i86pc. (See Appendix C, "Platform Names and Groups" for a detailed list of the platform names of various systems.) Restriction: client_arch can be used only when system_type is specified as server.
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 will automatically allocate 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. Restriction: client_root can be used only when system_type is specified as server.
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, 24 Mbytes of swap space is allocated. Example: client_swap 32 The example defines that each diskless client will have a swap space of 32 Mbytes. Restriction: client_swap can be used only when system_type is specified as server.
. Profile keywords that can be used for upgrading

Table 4-2 (2 of 10)

Profile Keyword

Profile Values and Description

cluster         group_name

(use for software groups)

cluster designates what software group to add to the system. The cluster names for the software groups are:

Software Group	group_name
Core	SUNWCreq
End user system support	SUNWCuser

Developer system support.....SUNWCprog

Entire distribution... SUNWCall

Entire distribution plus OEM support SUNWCXall

You can specify only one software group in a profile, and it must be specified before other cluster and package entries. If you do not specify a software group with cluster, the end user software group (SUNWCuser) is installed on the system by default.

        . clustercluster_name [add | delete]

(use for clusters)

cluster designates whether a cluster should be added or deleted from the software group that will be installed on the system. add or delete indicates whether the cluster should be added or deleted. If you do not specify add or delete, add is set by default.

cluster_name must be in the form SUNWCname. To view detailed information about clusters and their names, start Admintool on an installed system and select Software from the Browse menu.

For Upgrade:

• All clusters 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.

. Profile keywords that can be used for upgrading

Table 4-2 (3 of 10)

Profile Keyword	Profile Values and Description
dontuse	disk_name dontuse designates a disk that the Solaris installation program should not use when partitioning default is specified. You can specify dontuse once for each disk, and disk_name must be specified in the form cxtydz or cydz, for example, c0t0d0. By default, the Solaris installation program uses all the operational disks on the system. Restriction: You cannot specify the dontuse keyword and the usedisk keyword in the same profile.
fdisk	disk_name type size fdisk defines how the fdisk partitions are set up on an x86 system (only required for x86 systems), and you can specify fdisk more than once. This is what happens by default with fdisk partitions on x86 systems: · All fdisk partitions on the disk are preserved unless you specifically delete them with the fdisk keyword (if size is delete or 0). Also, all existing fdisk partitions are deleted when size is all. · A Solaris fdisk partition that contains a root file system is always designated as the active partition on the disk (an x86 system boots from the active partition by default). · If no fdisk keyword is specified in a profile, the following fdisk keyword is specified during the installation: fdisk all solaris maxfree · fdisk entries are processed in the order they appear in the profile. disk_name - Choose where the fdisk partition will be created or deleted: · cxtydz or cydz - A specific disk, for example, c0t3d0. · rootdisk - The disk where the root file system is placed during an installation, which is determined by the Solaris installation program (described on page 91). · all - All the selected disks. type - Choose what type of fdisk partition will 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 extended or data DOS fdisk partitions). When deleting fdisk partitions (size is delete), dosprimary is an alias for the DOSHUGE, DOSOS12, and DOSOS16 fdisk types (they are all deleted). When creating an fdisk partition, dosprimary is an alias for the DOSHUGE fdisk partition (a DOSHUGE fdisk partition is created).
. Profile keywords that can be used for upgrading

Table 4-2 (4 of 10)

Profile Keyword

Profile Values and Description

fdisk....disk_name type size

continued

type - Choose what type of fdisk partition will be created or deleted on the specified disk:

• DDD - A decimal fdisk partition. DDD is a decimal number (valid values are 1 through 255). Restriction: This value can be specified only if size is delete.
• 0xHH - A hexadecimal fdisk partition. HH is a hexadecimal number (valid values are 01 through FF). Restriction: This value can be specified only if size is delete.

The following table shows the decimal and hexadecimal numbers for some of the fdisk types:

fdisk typeDDDHH DOSOS12101

PCIXOS 202 DOSOS16404 EXTDOS505 DOSHUGE606 DOSDATA8656 OTHEROS9862 UNIXOS9963

size - Choose one of the following:

• DDD - An fdisk partition of size DDD (in Mbytes) is created on the specified disk. DDD must be a decimal number and the Solaris installation program automatically rounds the number up to the nearest cylinder boundary. If 0 is specified, it is the same as specifying delete.
• all - An fdisk partition is created on the entire disk (all existing fdisk partitions will be deleted). Restriction: This 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).

Note: There must be at least one unused fdisk partition on the disk and the disk must have free space, or an error will occur.

Restriction: This 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.

. Profile keywords that can be used for upgrading

Table 4-2 (5 of 10)

Profile Keyword	Profile Values and Description
filesys (use for mounting remote file systems)	server:path server_address mount_pt_name [mount_options] This instance of filesys sets up the installed system to automatically mount remote file systems when it boots. You can specify filesys more than once. For Dataless Clients: Profiles for dataless clients (when system_type dataless is specified) must include a remote filesys entry for both the /usr file system. The following line is an example of the filesys entries that must be used in a profile to install the Solaris software on a dataless client: filesys sherlock:/export/exec/Solaris_2.4_sparc.all/usr - /usr server: - The name of the server where the remote file system resides (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 specified in server:path. If you don't have a name service running on the network, this value can be used to populate the /etc/hosts file with the server's host name and IP address. If you don't want to specify the server's IP address (if you have a name service running on the network), you must specify a minus sign (-). mount_pt_name - The name of the mount point that the remote file system will be mounted on. mount_options - One or more mount options (-o option of the command) that 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. For example: ro,quota
. Profile keywords that can be used for upgrading

Table 4-2 (6 of 10)

Profile Keyword	Profile Values and Description
filesys (use for creating local file systems)	slice size [file_system] [optional_parameters] This instance of filesys creates local file systems during the installation. You can specify filesys more than once. slice - Choose one of the following: · any - The Solaris installation program places the file system on any disk. Restriction: any cannot be specified when size is existing, all, free, start:size, or ignore. · cwtxdysz or cxdysz - The disk slice where the Solaris installation program places the file system, for example, c0t0d0s0. · rootdisk.sn - The logical name of the disk where the installation program places the root file system. The sn suffix indicates a specific slice on the disk. size - Choose one of the following: · 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 using this value, you can change the name of an existing slice by specifying file_system as a different mount_pt_name. · auto - The size the file system is automatically determined depending on the selected software. · all - The specified slice uses the entire disk for the file system. When you specify this value, no other file systems can reside on the specified disk. · free - The remaining unused space on the disk is used for the file system. Restriction: If free is used as the value to filesys, it must by the last filesys 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.
. Profile keywords that can be used for upgrading

Table 4-2 (7 of 10)

Profile Keyword	Profile Values and Description
filesys (use for creating local file systems) continued	slice size [file_system] [optional_parameters] file_system - You can use this optional value when slice is specified as any or cwtxdysz. If file_system is not specified, unnamed is set by default, but then you can't specify the optional_parameters value. Choose one of the following: · 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 (VTOC value is V_BACKUP). By default, slice 2 is an overlap slice that is a representation of the whole disk. Restriction: overlap can be specified only when size is existing, all, or start:size. · unnamed - The specified slice is defined as a raw slice, so slice will not have a mount point name. If file_system is not specified, unnamed is set by default. · ignore - The specified slice is not used or recognized by the Solaris installation program. This could be used to ignore a file system on a disk during an installation, so the Solaris installation program can create a new file system on the same disk with the same name. optional_parameters - Choose one of the following: · preserve - The file system on the specified slice is preserved. Restriction: preserve can be specified only when size is existing and slice is cwtxdysz. · mount_options - One or more mount options (-o option of the mount(1M) command) that 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. For example: ro,quota
. install_type	initial_install | upgrade install_type defines whether to perform the initial installation option or upgrade option on the system. Restriction: install_type must be the first profile keyword in every profile.
. Profile keywords that can be used for upgrading

Table 4-2 (8 of 10)

Profile Keyword

Profile Values and Description

       . locale locale_name

locale designates that the localization packages associated with the selected software should be installed (or added for upgrade) for the specified locale_name. The locale_name values are the same as the values used for the $LANG environment variable. Solaris 2.5 supports the following localizations:

Language	locale_name
Chinese	zh
French	fr
German	de
Italian	it
Japanese	ja
Korean	ko
Latin American	es
Swedish	sv
Taiwanese	zh_TW

The English localization packages are installed by default. You can specify locale once for each localization you need to support.

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 will support. If you do not specify num_clients, five diskless clients are allocated.

Restriction: num_clients can be used only when system_type is specified as server.

. Profile keywords that can be used for upgrading

Table 4-2 (9 of 10)

Profile Keyword	Profile Values and Description
. package	package_name [add | delete] package designates whether a package should be added to or deleted from the software group that will be installed on the system. add or delete indicates whether the package should be added or deleted. If you do not specify add | delete, add is set by default. package_name must be in the form SUNWname. Use the pkginfo -l command or Admintool (select Software from the Browse menu) on an installed system to view detailed information about packages and their names. For Upgrade: · 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 prevented from being installed if it is part of a cluster that is designated to be installed.
. Profile keywords that can be used for upgrading

Table 4-2 (10 of 10)

Profile Keyword	Profile Values and Description
partitioning	default | existing | explicit partitioning defines how the disks are divided into slices for file systems during the installation. If you do not specify partitioning, default is set. default - The Solaris installation program selects the disks and creates the file systems on which to install the specified software, except for any file systems specified by the filesys keyword. rootdisk is selected first; additional disks are used if the specified software does not fit on rootdisk. existing - The Solaris installation program uses the existing file systems on the system's disks. All file systems except /, /usr, /usr/openwin, /opt, and /var are preserved. The installation program uses the last mount point field from the file system superblock to determine which file system mount point the slice represents. Restriction: When specifying the filesys profile keyword with partitioning existing, size must be existing. explicit - The Solaris installation program uses the disks and creates the file systems specified by the filesys keywords. If you specify only the root (/) file system with the filesys keyword, all the Solaris software will be installed in the root file system. Restriction: When you use the explicit profile value, you must use the filesys profile keyword to specify which disks to use and what file systems to create.
system_type	standalone | dataless | server system_type defines the type of system being installed. If you do not specify system_type in a profile, standalone is set by default.
usedisk	disk_name usedisk designates a disk that the Solaris installation program will use when partitioning default is specified. You can specify usedisk once for each disk, and disk_name must be specified in the form cxtydz or cydz, for example, c0t0d0. If you specify the usedisk profile keyword in a profile, the Solaris installation program will only use the disks that you specify with the usedisk profile keyword. Restriction: You cannot specify the usedisk keyword and the dontuse keyword in the same profile.
. Profile keywords that can be used for upgrading

How the Size of Swap Is Determined

If a profile does not explicitly specify the size of swap, the Solaris installation program determines the maximum size that swap can be, based on the system's physical memory. Table 4-3 shows how the maximum size of swap is determined during a custom JumpStart installation.

Table 4-3

Physical Memory (in Mbytes)	Maximum Size of Swap (in Mbytes)
16 - 64	32
64 - 128	64
128 - 512	128
512 >	256

The Solaris installation program will make the size of swap no more than 20% of the disk where it resides, unless there is free space left on the disk after laying out the other file systems. If free space exists, the Solaris installation program will allocate the free space to swap up to the maximum size shown in Table 4-3.

---

Note - Physical memory plus swap space must be a minimum of 32 Mbytes.

---

Creating the rules File

What Is the rules File

The rules file is a text file used to create the rules.ok file. The rules file is a look-up table consisting of one or more rules that define matches between system attributes and profiles. For example, the rule

karch sun4c - basic_prof -

matches a system with a sun4c platform name to the basic_prof profile, which the Solaris installation program would use to install the system.

---

Note - If you set up the JumpStart directory by using the procedures on page 53 or page 62, an example rules file should already be in the JumpStart directory; the example rules file contains documentation and some example rules. If you use the example rules file, make sure you comment out the example rules that you will not use.

---

When Does a System Match a Rule

During a custom JumpStart installation, the Solaris installation program attempts to match the rules in the rules.ok file in order: first rule through the last rule. A rule match occurs when the system being installed matches any of the rule values in the rule (as defined in Table 4-5 on page 88). As soon as a system matches a rule, the Solaris installation program stops reading the rules.ok file and begins to install the system as defined by the matched rule's profile.

· How to Create the rules File

Overview - The procedure to create a rules file involves:

• Editing a file
• Selecting rule keywords and rule values for each group of systems you want to install using custom JumpStart. Any systems that match the rule keyword and rule value will be installed as specified by the corresponding profile.

Follow this procedure to create a rules file.

1. Open a file (the rules file) and name it rules. You can create a new file or edit the sample rules file provided in the JumpStart directory you created.

2. Add a rule in the rules file for each group of systems you want to install using custom JumpStart.

   Be aware of these things as you add rules to the rules file:

• Rule Examples on page 86 provides some examples of rules.
• Table 4-5 on page 88 provides the list of valid rule keywords and values.
• The rules file must have at least one rule

• A rule must have at least a rule keyword, a rule value, and a corresponding profile.

A rule within the rules file must have the following syntax:

[!]rule_keyword rule_value [&& [!]rule_keyword rule_value]... begin profile finish

Table 4-4 describes the fields of a rule.

Table 4-4

Field	Description
!	A symbol used before a rule keyword to indicate negation.
[ ]	A symbol used to indicate an optional expression or field.
...	A symbol used to indicate the preceding expression may be repeated.
rule_keyword	A predefined keyword that describes a general system attribute, such as host name (hostname) or memory size (memsize). It is used with the rule value to match a system with the same attribute to a profile. See Table 4-5 on page 88 for the list of rule keywords.
rule_value	A value that provides the specific system attribute for the corresponding rule keyword. See Table 4-5 on page 88 for the list of rule values.
&&	A symbol that must be used to join (logically AND) rule keyword and rule value pairs together in the same rule. During a custom JumpStart installation, a system must match every pair in the rule before the rule matches.

Table 4-4 (Continued)

Field	Description
begin	A name of an optional Bourne shell script that can be executed before the installation begins. If no begin script exists, you must enter a minus sign (-) in this field. All begin scripts must reside in the JumpStart directory. See "Creating Begin Scripts" on page 98 for detailed information on how to create begin scripts.
profile	A name of a text file used as a template that defines how to install Solaris on a system. The information in a profile consists of profile keywords and their corresponding profile values. All profiles must reside in the JumpStart directory. Note - There are optional ways to use the profile field, which are described in "Using a Site-Specific Installation Program" on page 111 and "Creating Derived Profiles With Begin Scripts" on page 98.
finish	A name of an optional Bourne shell script that can be executed after the installation completes. If no finish script exists, you must enter a minus sign (-) in this field. All finish scripts must reside in the JumpStart directory. See "Creating Finish Scripts" on page 100 for detailed information on how to create finish scripts.

This completes the procedure to create a rules file. To validate the rules file, see How to Use check to Validate the rules File on page 94.

Rule Examples

The following illustration shows several example rules in a rules file. Each line has a rule keyword and a valid value for that keyword. The Solaris installation program scans the rules file from top to bottom. When the Solaris installation program matches a rule keyword and value with a known system, it installs the Solaris software specified by the profile listed in the profile field.

# rule keywords and rule valuesbegin script profile finish script # ----------------------------------------- ------- ------------- (1) hostname eng-1 - basic_prof - (2) network 192.43.34.0 && !model \ 'SUNW,Sun 4_50' - net_prof - (3) model SUNW,SPARCstation-LX - lx_prof complete (4) network 193.144.2.0 && karch i86pcsetup x86_prof done (5) memsize 16-32 && arch sparc - prog_prof - (6) any - - generic_prof -

(1)

This rule matches if the system's host name is eng-1. The basic_prof profile is used to install the Solaris software on the system that matches this rule.

(2)The rule matches if the system is on subnet 192.43.34.0 and it is not a SPARCstation IPX^(TM) (SUNW,Sun 4_50). The net_prof profile is used to install the Solaris software on systems that match this rule.

(3)The rule matches if the system is a SPARCstation LX. The lx_prof profile and the complete finish script are used to install the Solaris software on systems that match this rule. This rule also provides an example of rule wrap, which is defined on page 87.

(4)

This rule matches if the system is on subnet 193.144.2.0 and the system is an x86. The setup begin script, the x86_prof profile, and the done finish script are used to install the Solaris software on systems that match this rule.

(5)This rule matches if the system has 16-32 Mbytes of memory and its processor type is SPARC. The prog_prof profile is used to install the Solaris software on systems that match this rule.

(6)This rule matches any system that did not match the previous rules. The generic_prof profile is used to install the Solaris software on systems that match this rule. If used, any should always be in the last rule.

Important Information About the rules File

The following information is important to know about the rules file:

• Name - The rules file must have the file name, rules.
• rules.ok file - The rules.ok file is a generated version of the rules file, and it is required by the custom JumpStart installation software to match a system to a profile. You must run the check script to create the rules.ok file, and the rules.ok file should be owned by root and have permissions equal to 644.
• Comments - You can add a comment after the pound sign (#) anywhere on a line. If a line begins with a #, the entire line is a comment line. If a # is specified in the middle of a line, everything after the # is considered a comment. Blank lines are also allowed in the rules file.

---

Note - When creating the rules.ok file, the check script removes all the comment lines, comments at the end of a rule, and blank lines.

---

• Rule wrap - When a rule spans multiple lines, you can let a rule to wrap to a new line, or you can continue a rule on a new line by using a backslash (\) before the carriage return.
• Rule fields - The rule_value, begin, and finish fields must have a valid entry or a minus sign (-) to specify that there is no entry.

Rule Keyword and Rule Value Descriptions

Table 4-5 describes the rule keywords and rule values that you can use in the rules file.

Table 4-5 Rule KeywordRule Value (1 of 4)

Rule Keyword	Rule Values	Description
any	minus sign (-)	Match always succeeds.

arch           processor_type

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

platform...processor_type

processor type.

SPARC	sparc
x86	i386

domainname	domain_name	Matches a system's domain name, which controls how a name service determines information. If you have a system already installed, the domainname command reports the system's domain name.
disksize	disk_name size_range	Matches a system's disk (in Mbytes).
	disk_name - A disk name in the form cxtydz, such as	Example: disksize c0t3d0 250-300
	c0t3d0, or the special word rootdisk. rootdisk should be used only when trying to match systems that contain the factory-installed JumpStart software. rootdisk is described on page 91.	The example tries to match a system with a c0t3d0 disk that is between 250 and 300 Mbytes.
	size_range - The size of the disk, which must be specified as a range of Mbytes (xx-xx).	Note: When calculating size_range, remember that a Mbyte equals 1,048,576 bytes. A disk may be advertised as a "207 Mbyte" disk, but it may have only 207 million bytes of disk space. The Solaris installation program will actually view the "207 Mbyte" disk as a 197 Mbyte disk because 207,000,000 / 1,048,576 = 197. So, a "207 Mbyte" disk would not match a size_range equal to 200-210.
hostaddress	IP_address	Matches a system's IP address.

Table 4-5 Rule KeywordRule Value (2 of 4)

Rule Keyword	Rule Values	Description
hostname	host_name	Matches a system's host name. If you have a system already installed, the uname -n command reports the system's host name.
installed	slice version	Matches a disk that has a root file system
	slice - A disk slice name in the form cwtxdysz, such as c0t3d0s5, or the special words any or rootdisk. If any is used, any disk attached to the system attempts to match. rootdisk should be used only when trying to match systems that contain the factory-installed JumpStart software. rootdisk is described on page 91. version - A version name, such as Solaris_2.3, or the special words any or upgrade. If any is used, any Solaris or SunOS release is matched. If upgrade is used, any upgradable Solaris 2.1 or greater release is matched.	corresponding to a particular version of Solaris software.
karch	platform_group	Matches a system's platform name.
	Valid values are sun4d, sun4c, sun4m, or i86pc. (See Appendix C, "Platform Names and Groups" for a detailed list of platform groups and names.)	If you have a system already installed, the arch -k command or the uname -m command reports the system's platform group.
memsize	physical_mem	Matches a system's physical memory size (in
	The value must be a range of Mbytes (xx-xx) or a single Mbyte value.	Mbytes). Example: memsize 16-32 The example tries to match a system with a physical memory size between 16 and 32 Mbytes. If you have a system already installed, the prtconf command (line 2) reports the system's physical memory size.

Table 4-5 Rule KeywordRule Value (3 of 4)

Rule Keyword	Rule Values		Description
model	model_name		Matches a system's model number, which is
	System	model_name	system-dependent and varies by the manufacturer. The list shown may not be

Sun-4/110.......Sun 4_100 Series

complete.

Sun-4/2xx	Sun 4_200 Series
SPARCstation 1 (4/60)	Sun 4_60

If you have a system already installed, the

SPARCstation 1+ (4/65) Sun 4_65

prtconf command (line 5) reports the

SPARCstation SLC^(TM) (4/20) Sun 4_20........system's model number.

SPARCstation IPC (4/40) SUNW,Sun 4_40

SPARCstation ELC^(TM) (4/25) SUNW,SUN 4_25....Note: If the model_name contains spaces, the

SPARCstation IPX (4/50) SUNW,Sun 4_50

model_name must be inside a pair of single

SPARCstation 2 (4/75) SUNW,SUN 4_75

quotes ('). For example: 'SUNW,Sun 4_50'

Sun-4/3xx	Sun SPARCsystem 300
Sun-4/4xx	Sun SPARCsystem 400
SPARCserver(TM) 6xx	SUNW,SPARCsystem-600
SPARCstation 10	SUNW,SPARCstation-10
SPARCclassic(TM) (4/15)	SUNW,SPARCclassic
SPARCstation LX (4/30)	SUNW,SPARCstation-LX
SPARCcenter(TM) 1000	SUNW,SPARCserver-1000
SPARCcenter 2000	SUNW,SPARCcenter-2000
SPARCstation 10 SX	SUNW,SPARCstation-10,SX
SPARCstation 20	SUNW,SPARCstation-20
SPARCstation 5	SUNW,SPARCstation-5
SPARCstation Voyager	SUNW,S240

Sun Ultra^(TM) 1 Model 140 SUNW,Ultra1-140

x86..........i86pc

Table 4-5 Rule KeywordRule Value (4 of 4)

Rule Keyword	Rule Values	Description
network	network_num	Matches a system's network number, which the Solaris installation program determines by performing a logical AND between the system's IP address and the subnet mask. Example: network 193.144.2.0 The example would match a system with a 193.144.2.8 IP address (if the subnet mask were 255.255.255.0).
osname	Solaris_version	Matches a version of Solaris already installed on a system. Solaris_version is the version of Solaris environment installed on the system: for example, Solaris_2.5.
totaldisk	size_range	Matches the total disk space on a system (in
	The value must be specified as a range of Mbytes (xx-xx).	Mbytes). The total disk space includes all the operational disks attached to a system. Example: totaldisk 300-500 The example tries to match a system with a total disk space between 300 and 500 Mbytes. Note: When calculating size_range, remember that a Mbyte equals 1048576 bytes. A disk may be advertised as a "207 Mbyte" disk, but it may have only 207 million bytes of disk space. The Solaris installation program will actually view the "207 Mbyte" disk as a 197 Mbyte disk because 207000000 / 1048576 = 197. So, a "207 Mbyte" disk would not match a size_range equal to 200-210.

How the Installation Program Sets the Value of rootdisk

rootdisk is the logical name of the disk where the root file system is placed during an installation. During a custom JumpStart installation, the Solaris installation program sets the value of rootdisk (that is, the actual disk it represents) depending on various situations; this is described in Table 4-6.

Table 4-6 rootdisk

Situation	What Happens
A system contains the factory-installed JumpStart software. (this applies to some SPARC systems only).	rootdisk is set to the disk that contains the factory-installed JumpStart software before the system tries to match any rules.
rootdisk has not been set and a system tries to match the following rule: disksize rootdisk size_range or installed rootdisk version	rootdisk is set to c0t3d0 or the first available disk attached to the system. After rootdisk is set, the system tries to match the rule.
If rootdisk has been set and the system tries to match the following rule. disksize rootdisk size_range or installed rootdisk version	The system tries to match the rule.
A system tries to match the following rule:	If disk is found on the system with a root file system that matches the specified
installed disk version	version, the rule matches and rootdisk is set to disk.
A system tries to match the following rule:	If any disk is found on the system with a root file system that matches the specified
installed any version	version, the rule matches and rootdisk is set to the found disk. (If there is more than one disk on the system that can match, the system will match the first disk that is found.)

Table 4-6 rootdisk (Continued)

Situation	What Happens
rootdisk has not been set after a system matches a rule and the system is going to be upgraded (which is defined in the profile).	rootdisk is set to the first disk found with a root file system that matches an upgradable version of Solaris software. If no disk is found, the system proceeds with an interactive installation.
rootdisk has not been set after a system matches a rule.	rootdisk is set to c0t3d0 or the first available disk attached to the system.

For the Solaris installation program to use the value of rootdisk, the following conditions must be true in the profile specified for the system:

• Default partitioning is used.
• No slice has been explicitly set for the root file system.

Using check to Validate the rules File

Before the rules file and profiles can be used, you must run the check script to validate that these files are set up correctly. The following table shows what the check script does.

Stage	Description
1	The rules file is checked for syntax. check makes sure that the rule keywords are legitimate, and the begin, class, and finish fields are specified for each rule (the begin and finish fields may be a minus sign [-] instead of a file name).
2	If no errors are found in the rules file, each profile specified in the rules is checked for syntax.
3	If no errors are found, check creates the rules.ok file from the rules file, removing all comments and blank lines, retaining all the rules, and adding the following comment line to the end: # version=2 checksum=num

· How to Use check to Validate the rules File

Overview - The procedure to use check to validate the rules file involves:

• Making sure the check script resides in the JumpStart directory
• Running the check script

Follow this procedure to use check to validate the rules file.

1. Make sure that the check script resides in the JumpStart directory.

---

Note - The check script is provided in the auto_install_sample directory on the Solaris CD.

---

2. Change the directory to the JumpStart directory:

$ cd jumpstart_dir_path

3. Run the check script to validate the rules file:

$ ./check [-p path] [-r file_name]

In this command,

-p path	Is the path to the Solaris 2.5 CD. You can use a Solaris CD image on a local disk or a mounted Solaris CD.This option ensures that you are using the most recent version of the check script. You should use this option if you are using check on a system that is running a previous version of Solaris.
-r file_name	Specifies a rules file other than the one named rules. Using this option, you can test the validity of a rule before integrating it into the rules file.

As the check script runs, it reports that it is checking the validity of the rules file and the validity of each profile. If no errors are encountered, it reports: The auto-install configuration is ok.

The rules files is now validated. To read about the optional features available for custom JumpStart installations, see Chapter 5, "Using Optional Custom JumpStart Features." To perform a custom JumpStart installation on a system, see Chapter 9, "Booting and Installing Solaris: Custom JumpStart."