Chapter 8 Preparing Custom JumpStart Installations

• "Overview"

• "What Happens During a Custom JumpStart Installation"

• "Task Map: Preparing Custom JumpStart Installations"

• "Creating a Profile Server"

• "Enabling All Systems to Access the Profile Server"

• "Creating a Profile Diskette "

• "Creating the rules File"

• "Creating a Profile"

• "Testing a Profile"

• "Validating the rules File"

This chapter provides the step-by-step instructions on how to prepare your site to perform custom JumpStart installations.

The name of this product is Solaris 7 but code and path or package path names may use Solaris 2.7 or SunOS 5.7. Always follow the code or path as it is written.

Appendix D, Sample Custom JumpStart Setup provides a detailed example of how to prepare a site for custom JumpStart installations.

Overview

The custom JumpStart installation method provides a way to automatically and identically install groups of systems. The first step when preparing custom JumpStart installations is deciding how you want the systems at your site to be installed. For example, the following scenario would be ideal to set up and perform custom JumpStart installations:

• You need to install the Solaris software on 100 new systems.

• The engineering group owns 70 out of the 100 new, SPARC-based 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, x86-based systems, and its systems must be installed as standalone systems with the end user software group.

After you decide how you want the systems at your site to be installed, the most important step when preparing custom JumpStart installations is to create the essential files that are used during a custom JumpStart installation: the rules.ok file (a validated rules file) and a profile for each group of systems. The rules file is a text file that should contain a rule for each group of systems (or single systems) that you want to automatically install. Each rule distinguishes a group of systems based on one or more system attributes, and it links each group to a profile, which is a text file that defines how the Solaris software will be installed on each system in the group. Both the rules file and the profiles must be located in a JumpStart directory.

In the previous scenario, you would create a rules file with two different rules, one rule for the engineering group and another rule for the marketing group. For each rule, you could use the system's platform groups to distinguish the groups from one another: the engineering group has SPARC-based systems and the marketing group has x86-based systems. Each rule would also contain a link to an appropriate profile. For example, in the rule for the engineering group, you would add a link to the profile, called eng_profile, that you created for the engineering group. And, in the rule for the marketing group, you would add a link to the profile, called market_profile, that you created for the marketing group.

After creating the rules file and profiles, you have to validate them with the check script. If the check script runs successfully, the rules.ok file is created, which is a generated version of the rules file that the Solaris installation program uses to perform custom JumpStart installations.

What Happens During a Custom JumpStart Installation

During a custom JumpStart installation, the Solaris installation program reads the rules.ok file and tries to find the first rule whose defined system attributes match the system that's installing. If a match occurs, the installation program uses the profile specified in the rule to automatically install the system.

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

Figure 8-1 How a Custom JumpStart Installation Works: Non-Networked Example

Figure 8-2 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 8-2 How a Custom JumpStart Installation Works: Networked Example

As shown in Figure 8-1 and Figure 8-2, the custom JumpStart files that you need to set up can be located on either a diskette or server (called a profile diskette and profile server, respectively). A profile diskette is required when you want to perform custom JumpStart installations on non-networked, standalone systems. A profile server should be used when you want to perform custom JumpStart installations on networked systems that have access to the server.

Figure 8-3 describes what happens on a system during a custom JumpStart installation and shows the search order that the Solaris installation program uses to find the custom JumpStart files.

Figure 8-3 What Happens During a Custom JumpStart Installation

Task Map: Preparing Custom JumpStart Installations

Creating a Profile Server

When setting up custom JumpStart installations for systems on the network, you have to create a directory on a server (called a JumpStart directory). A JumpStart directory contains all the essential custom JumpStart files (for example, the rules file, rules.ok file, and profiles) at its root level.

The server that contains a JumpStart directory is called a profile server. The profile server can be the same system as either the install or boot server, or it can be a completely different server. The JumpStart directory should be owned by root and have permissions equal to 755.

A profile server can provide custom JumpStart files for systems with the same or different platform type as the server. For example, a SPARC server can provide custom JumpStart files for both SPARC and x86-based systems.

How to Create a JumpStart Directory on a Server

This procedure assumes that the system is running Volume Management. If you are not using Volume Management to manage diskettes and CDs, refer to the System Administration Guide, Volume I for detailed information about managing removable media without Volume Management.

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

   jumpstart_dir_path

   Is the absolute path of the JumpStart directory.

   For example, the following command creates a 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 shares the /jumpstart directory:

   ---

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

   ---

4. Type shareall and press Return.

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

   You only need to perform the rest of the steps if you want to copy example custom JumpStart files from the Solaris CD. You are already done creating the profile server.

   If You Want to Use The ...	Then ...
   Solaris CD in the local CD-ROM drive	Insert the Solaris CD into the CD-ROM drive. Mount the Solaris CD (if needed). Note - Volume management automatically mounts the Solaris CD on /cdrom/cdrom0/s0 or /cdrom/cdrom0/s2.
   Solaris CD image on local disk	Change the directory to the Solaris CD image on the local disk. For example:  cd /export/install

6. Change directory to the Misc directory on the Solaris CD image.

   # cd Solaris_2.7/Misc

7. Copy the example custom JumpStart files into the JumpStart directory on the profile server.

   # cp -r jumpstart_sample/* jumpstart_dir_path

   For example, the following command would copy the jumpstart_sample directory into the /jumpstart directory:

   ---

   cp -r jumpstart_sample/* /jumpstart

   ---

   The files you just copied are only example custom JumpStart files. You must update the files for your own site.

Where to Go Next

You have completed creating a profile server. To continue, see "Enabling All Systems to Access the Profile Server".

Enabling All Systems to Access the Profile Server

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

• Every time you add a system for network installation, you have to use the -c option of the add_install_client command or specify the profile server in Host Manager.

  or

• Enable all systems to access the profile server by using a wildcard in the /etc/bootparams file.

To save you time when adding systems for network installations, use the following procedure to enable all systems to access the profile server. Otherwise, see "Creating the rules File".

How to Enable All Systems to Access the Profile Server

This procedure is valid only if you are using the /etc/bootparams file to store network installation information. If you are using the NIS or NIS+ bootparams database for network installation information, you need to update the bootparams database with the entry in Step 2.

This procedure is not necessary if you are using a diskette for the JumpStart directory.

1. On the install server or boot server, log in as root.

2. Edit the /etc/bootparams file. Add the following entry.

   * install_config=server:jumpstart_dir_path

   *	Is a wildcard character specifying all systems.
   server	Is the host name of the profile 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 profile server named sherlock:

   ---

   * install_config=sherlock:/jumpstart

   ---

   ---

   Caution -

   Using this procedure may produce the following error message when an install client is booted: WARNING: getfile: RPC failed: error 5: (RPC Timed out). See "Booting a System Over the Network" for more details on this error message.

   ---

Where to Go Next

All systems can now access the profile server. You no longer need to specify the profile server in Host Manager or use the -c option of the add_install_client command when adding systems for network installations. To continue, go to "Creating the rules File".

Creating a Profile Diskette

You must create a JumpStart directory on a diskette if a system is not connected to a network, because the system won't have access to a profile server. However, the system must have a diskette drive.

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

The diskette requirements for the profile diskette are different for x86 based systems and SPARC-based systems, so there is a different procedure to create a profile diskette for each platform.

x86: How to Create a Profile Diskette

Follow this procedure to create a profile diskette for x86 based systems, which involves:

• Making a copy of the Configuration Assistant diskette (the copied boot diskette has a PCFS file system)

• Copying sample custom JumpStart installation files into the diskette's root directory (JumpStart directory)

This procedure assumes that the system is running Volume Management. For detailed information about managing CDs without Volume Management, see the System Administration Guide, Volume I.

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

2. Insert the Configuration Assistant diskette into the diskette drive.

3. Make sure Volume Management knows about the diskette.

   # volcheck

4. Copy the Configuration Assistant diskette image to the system's hard disk.

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

   boot_image

   Is the file name where the Configuration Assistant diskette image is copied. You can specify an absolute path name.

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

   ---

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

   ---

5. Manually eject the Configuration Assistant diskette.

6. Find a blank diskette (or a diskette that can be overwritten) that you can use for a profile diskette and insert it into the diskette drive.

   Any previous information on the diskette is overwritten when you make it into a profile diskette.

7. Make sure Volume Management knows about the diskette.

   # volcheck

8. Format the diskette.

   ---

   Caution -

   This step will overwrite any data on the diskette.

   ---

   # fdformat -d -U

9. Copy the Configuration Assistant 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 4.

10. Eject the diskette.

    # eject floppy

11. Insert the copied boot diskette back into the diskette drive.

12. Make sure Volume Management knows about the diskette.

    # volcheck

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

    You only need to perform the rest of the steps if you want to copy example custom JumpStart files from the Solaris CD. You are already done creating the profile diskette.

    If You Want to Use The ...	Then ...
    Solaris CD in the local CD-ROM drive	Insert the Solaris CD into the CD-ROM drive. Mount the Solaris CD (if needed). Note - Volume management automatically mounts the Solaris CD on /cdrom/cdrom0/s0 or /cdrom/cdrom0/s2.
    Solaris CD image on local disk	Change directory to the Solaris CD image on the local disk. For example:  cd /export/install

14. Change directory to the Misc directory on the Solaris CD image.

    # cd Solaris_2.7/Misc

15. Copy the example custom JumpStart files into the root directory (JumpStart directory) of the profile diskette.

    # cp -r jumpstart_sample/* /floppy/floppy0/.

    The files you just copied are only example custom JumpStart files. You must update the files for your own site.

    ---

    Caution -

    File names on PCFS file systems can be only 11 characters long (an 8-character file name and a 3-character extension). When copying JumpStart installation files to a diskette for x86 systems, be aware that the file transfer may truncate file names.

    ---

    ---

    Note -

    When using a profile diskette, all the custom JumpStart installation files must be in the root directory of the diskette.

    ---

Where to Go Next

You have completed creating a profile diskette. Now you can update the rules file and create profiles on the profile diskette to perform custom JumpStart installations. To continue, go to "Creating the rules File".

SPARC: How to Create a Profile Diskette

Follow this procedure to create a profile diskette for SPARC-based systems, which 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 (JumpStart directory).

  ---

  Note -

  This procedure assumes that the system is running Volume Management. If you are not using Volume Management to manage diskettes and CDs, refer to the System Administration Guide, Volume I for detailed information about managing removable media without Volume Management.

  ---

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

2. Find a blank diskette (or a diskette that can be overwritten) that you can use for a profile diskette and insert it into the diskette drive.

   Any previous information on the diskette will be overwritten when you make it into a profile diskette.

3. Make sure Volume Management knows about the diskette.

   # volcheck

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

   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

   ---

5. Format the diskette.

   ---

   Caution -

   This step will overwrite any data on the disk.

   ---

   # fdformat -U

6. Create a UFS file system on the diskette.

   # newfs /vol/dev/aliases/floppy0

7. Eject the diskette.

   # eject floppy

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

9. Make sure Volume Management knows about the diskette.

   # volcheck

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

    You only need to perform the rest of the steps if you want to copy example custom JumpStart files from the Solaris CD. You are already done creating the profile diskette.

    If You Want to Use The ...	Then ...
    Solaris CD in the local CD-ROM drive	Insert the Solaris CD into the CD-ROM drive. Mount the Solaris CD (if needed). Note - Volume management automatically mounts the Solaris CD on /cdrom/cdrom0/s0 or /cdrom/cdrom0/s2.
    Solaris CD image on the local disk	Change the directory to the Solaris CD image on the local disk. For example:  cd /export/install

11. Change directory to the Misc directory on the Solaris CD image.

    # cd Solaris_2.7/Misc

12. Copy the example custom JumpStart installation files into the root directory (JumpStart directory) of the profile diskette.

    # cp -r jumpstart_sample/* /floppy/floppy0/.

    The files you just copied are only example custom JumpStart files. You must update the files for your own site.

    ---

    Note -

    When using a profile diskette, all the custom JumpStart installation files must be in the root directory of the diskette.

    ---

Where to Go Next

You have completed creating a profile diskette. Now you can update the rules file and create profiles on the profile diskette to perform custom JumpStart installations. To continue, go to "Creating the rules File".

Creating the rules File

What Is the rules File?

The rules file is a text file that should contain a rule for each group of systems (or single systems) that you want to automatically install. Each rule distinguishes a group of systems based on one or more system attributes, and it links each group to a profile, which is a text file that defines how the Solaris software will be installed on each system in the group. For example, the rule

karch sun4c - basic_prof -

specifies that the Solaris installation program will automatically install any system with the sun4c platform group based on the information in the basic_prof profile. The rules file is used to create the rules.ok file, which is required for custom JumpStart installations.

If you set up the JumpStart directory by using the procedures on "Creating a Profile Diskette " or "Creating a Profile Server", 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 system being installed to 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 all of the system attributes defined in the rule. As soon as a system matches a rule, the Solaris installation program stops reading the rules.ok file and begins to install the system based on the matched rule's profile.

Important Information About the rules File

The rules file must have:

• At least one rule.

• The file name, rules.

• Rules that have at least a rule keyword, a rule value, and a corresponding profile. Rules must also have a minus sign (-) in the begin and finish fields if there is no entry.

The rules file allows:

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

• Rules to span multiple lines. You can let a rule wrap to a new line, or you can continue a rule on a new line by using a backslash (\) before the carriage return.

How to Create the rules File

1. Open a new text file (it must be named rules) using the editor of your choice.

   You can create a new rules 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.

   Refer to the following information as you add rules to the rules file:

   • "Important Information About the rules File"

   • "Rule Examples"

   • Table 8-2

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

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

   !	Is a symbol used before a rule keyword to indicate negation.
   [ ]	Is a symbol used to indicate an optional expression or field.
   ...	Is a symbol used to indicate the preceding expression may be repeated.
   rule_keyword	Is 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 8-2 for the list of rule keywords.
   rule_value	Is a value that provides the specific system attribute for the corresponding rule keyword. See Table 8-2 for the list of rule values.
   &&	Is a symbol that must be used to join rule keyword and rule value pairs together in the same rule (a logical AND). During a custom JumpStart installation, a system must match every pair in the rule before the rule matches.
   begin	Is 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" for detailed information on how to create begin scripts.
   profile	Is a name of a text file that defines how the Solaris software will be installed on the system when a system matches the rule. 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" and "Creating Derived Profiles With Begin Scripts".
   finish	Is the 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" for detailed information on how to create finish scripts.

3. Save the rules file into the JumpStart directory.

   The rules file should be owned by root and have permissions equal to 644.

Where to Go Next

This completes the procedure to create a rules file. To create profiles, go to "Creating a Profile".

Rule Examples

The following code example 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 values      begin script       profile       finish script
	#  -----------------------------      ------------       --------      -------------
 [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.]  hostname eng-1                        -               basic_prof          -
  [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. ]  network 192.43.34.0 && !model \
 'SUNW,Sun 4_50'                        -                net_prof            -
  [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 "Important Information About the rules File".]  model SUNW,SPARCstation-LX            -                 lx_prof	         complete
  [This rule matches if the system is on subnet 193.144.2.0 and the system is an x86 system. 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.]  network 193.144.2.0 && karch i86pc	  setup              x86_prof         done
  [This rule matches if the system has between 16 and 32 Mbytes of memory and is an x86 system. The prog_prof profile is used to install the Solaris software on systems that match this rule.]  memsize 16-32 && arch i386              -                prog_prof          -
  [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.]  any  -                                 -                generic_prof        -

Rule Keyword and Rule Value Descriptions

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

disksize c0t3d0 250-300

installed c0t3d0s1 Solaris_2.5

memsize 16-32

network 193.144.2.0

osname Solaris_2.5

totaldisk 300-500

Creating a Profile

What Is a Profile?

A profile is a text file that defines how to install the Solaris software (for example, which software group to install) on a system. Every rule specifies a profile to define how a system will be installed when the rule is matched. You usually create a different profile for every rule; however, the same profile can be used in more than one rule.

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.

If you created the JumpStart directory by using the procedures in "Creating a Profile Diskette " or "Creating a Profile Server", example profiles should already be in the JumpStart directory.

Important Information about Creating Profiles

A profile must have:

• The install_type profile keyword as the first entry.

• Only one profile keyword on a line.

• The root_device keyword if the systems being upgraded by the profile have more than one root file system that can be upgraded (if you are creating a profile to perform upgrade installations).

A profile allows:

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

How to Create a Profile

1. Open a new text file (with a descriptive name) using the editor of your choice.

   You can create a new profile 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.

   Refer to the following information as you edit the profile:

   • "Important Information about Creating Profiles"

   • "Profile Examples"

   • "Profile Keyword and Profile Value Descriptions"

3. Save the profile into the JumpStart directory.

   A profile should be owned by root and have permissions equal to 644.

4. Test the profile (optional).

   See "Testing a Profile" for detailed information.

Where to Go Next

This completes the procedure to create a profile. After you've created all your profiles, go to "Validating the rules File".

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 "Profile Keyword and Profile Value Descriptions" for the list of profile keywords and profile values.

Mounting Remote File Systems and Adding and Deleting Packages

 
# profile keywords       profile values
# -----------------      -----------------
 [This profile keyword is required in every profile.]  install_type            initial_install
 [This profile keyword defines that the system will be installed as a standalone system.]  system_type             standalone
 [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 is installed on any disk (any value). The standard and OpenWindows man pages are mounted from the file server, s_ref, on the network.]  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
 [The developer software group (SUNWCprog) is installed on the system.]  cluster                 SUNWCprog
 [Because the man pages are being mounted remotely, those packages are selected not to be installed on the system; however, the packages containing the OPEN LOOK and X Window System demo programs and images are selected to be installed on the system.]  package                 SUNWman delete
	package                 SUNWolman delete
	package                 SUNWxwman delete
 package                 SUNWoldem add
 package                 SUNWxwdem add
	package                 SUNWoldim add
	package                 SUNWxwdim add

Specifying Where to Install File Systems

# profile keywords       profile values
# ----------------        -------------------
 install_type	           initial_install
	 system_type              standalone
 
 [The file system slices are determined by the filesys keywords (explicit value). The size of root is based on the selected software (auto value) and is installed on c0t0d0s0; the size of swap is set to 32 Mbytes and is installed on c0t3d0s1; and usr is based on the selected software and the installation program determines where it is installed (any value).] 	partitioning             explicit
	 filesys                  c0t0d0s0 auto /
 filesys                  c0t3d0s1 32 swap
  filesys                  any auto usr
 [The entire distribution software group (SUNWCall) is installed on the system. ]  cluster                  SUNWCall

x86: Using the fdisk Keyword

# profile keywords     profile values
# ----------------      -------------------
	 install_type          initial_install
	 system_type           standalone
 
 [All fdisk partitions of type DOSOS16 (04 hexadecimal) are deleted from the c0t0d0 disk.] 	fdisk                   c0t0d0 0x04 delete
 [A Solaris fdisk partition is created on the largest contiguous free space on the c0t0d0 disk.] 	fdisk	                  c0t0d0 solaris maxfree
 [The entire distribution software group (SUNWCall) is installed on the system.] 	cluster                 SUNWCall
 [The system accounting utilities (SUNWCacc) are selected not to be installed on the system.] 	cluster                 SUNWCacc delete

Reallocating Disk Space for an Upgrade

# profile keywords       profile values
# ----------------       -------------------
 [This profile upgrades a system by reallocating disk space. In this example, disk space must be reallocated because some file systems on the system did not have enough room for the upgrade.] 	install_type             upgrade
 
 [The root file system on c0t3d0s2 is upgraded.] 	root_device              c0t3d0s2
 
 [A remote system named timber will be used to back up data during the disk space reallocation.]  backup_media             remote_filesystem timber:/export/scratch
 [The layout_constraint keywords designate that auto-layout can change slice 2 and 5 (the slices can be moved to another location and their size can be changed) and it can move slice 5 (the slice can be moved to another location but its size stays the same) when it tries to reallocate disk space for the upgrade.]  layout_constraint        c0t3d0s2 changeable 100
  layout_constraint        c0t3d0s4 changeable
  layout_constraint        c0t3d0s5 movable
 
 [The binary compatibility package (SUNWbcp) will not be installed on the system after the upgrade.] 	package                  SUNWbcp delete
 [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.)] 	package                  SUNWolman add
  package                  SUNWxwman add
	  cluster                  SUNWCumux add
 
 [The German localization packages are selected to be installed on the system.] 	locale                   de

Profile Keyword and Profile Value Descriptions

The following sections describe the profile keywords and profile values that you can use in a profile. Profile keywords and their values are case sensitive.

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

backup_media Profile Keyword

backup_media type   path

backup_media must be used only with the upgrade option when disk space reallocation is required.

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

Examples:

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 installation program will install the root file system and consequently what the system's boot device will be. The eeprom value also enables you to update the system's EEPROM if you change the system's current boot device, so the system can automatically boot from the new boot device (SPARC systems only).

If you don't 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 - Choose what the boot device will be.

• cwtxdysz or cxdysz - The disk slice where the installation program places the root file system, for example, c0t0d0s0. (SPARC-based systems only).

• cwtxdy or cxdy - The disk where the installation program places the root file system, for example, c0t0d0. (x86 based systems only).

• existing - The installation program places the root file system on the system's existing boot device.

• any - The installation program chooses where to place the root file system. It will try to use the system's existing boot device; however, it can choose a different boot device if it needs to.

eeprom - Choose if you want to update the system's EEPROM to the specified boot device (SPARC-based systems only). For x86 based systems, you must always specify the preserve value.

• update - The installation program updates the system's EEPROM to the specified boot device, so the installed system will automatically boot 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 will have to manually change the system's EEPROM, so it can automatically boot from the new boot device.

Example:

boot_device c0t0d0s2 update

boot_device must match any filesys keywords that specify the root file system and the root_device keyword (if specified).

client_arch Profile Keyword

client_arch karch_value[karch_value...]

client_arch defines that the OS server will support a different platform group than it uses. If you do not specify client_arch, any diskless client or Solstice AutoClient system that uses the OS server must have the same platform group as the server. You must specify each platform group that you want the OS server to support.

Valid values for karch_value are: sun4d, sun4c, sun4m, sun4u, i86pc. (See Appendix C, Platform Names and Groups for a detailed list of the platform names of various systems.)

client_arch can be used 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 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.

client_root can be used 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, 32 Mbytes of swap space is allocated.

Example:

client_swap 64

The example defines that each diskless client will have a swap space of 64 Mbytes.

client_swap can be used only when system_type is specified as server.

cluster Profile Keyword (Adding Software Groups)

cluster group_name

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

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.

cluster Profile Keyword (Adding or Deleting Clusters)

cluster cluster_name [add | delete]

cluster (adding or deleting clusters) can be used with both the initial installation and upgrade options.

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

dontuse Profile Keyword

dontuse disk_name [disk_name...]

dontuse designates one or more disks that you don't want the Solaris installation program to use when partitioning default is specified (by default, the installation program uses all the operational disks on the system). disk_name must be specified in the form cxtydz or cydz, for example, c0t0d0.

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

fdisk Profile Keyword

fdisk disk_name  type  size

fdisk defines how the fdisk partitions are set up on an x86-based system, and you can specify fdisk more than once. This is what happens by default with fdisk partitions on x86 --based 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-based 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 are listed 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 variable that contains the value for the system's root disk, which is determined by the Solaris installation program (described in "How the System's Root Disk Is Determined").

• 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).

• DDD - An integer fdisk partition. DDD is an integer (valid values are 1 through 255).

  ---

  Note -

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

  ---

  Note -

  This value can be specified only if size is delete.

  ---

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

size - Choose one of the following:

• DDD - An fdisk partition of size DDD (in Mbytes) is created on the specified disk. DDD must be an integer, 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).

  ---

  Note -

  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 the installation will fail. 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.

filesys Profile Keyword (Mounting Remote File Systems)

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

Example:

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

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 mount(1M) command) that are added to the /etc/vfstab entry for the specified mount_pt_name.

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

filesys Profile Keyword (Creating Local File Systems)

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

  ---

  Note -

  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 variable that contains the value for the system's root disk, which is determined by the Solaris installation program (described in "How the System's Root Disk Is Determined"). 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 of the file system is automatically determined and depends 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.

  ---

  Note -

  If free is used as the value to filesys, it must be 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.

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.

  ---

  Note -

  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 does 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 can 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. ignore can be used only when partitioning existing is specified.

optional_parameters - Choose one of the following:

• 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 (-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 Profile Keyword

install_type initial_install | upgrade

install_type defines whether to perform the initial installation option or upgrade option on the system.

install_type must be the first profile keyword in every profile.

Some profile keywords can only be used with the initial_install option, and this also applies to the upgrade option.

isa_bits Profile Keyword

isa_bits 64 | 32

isa_bits determines whether 64-bit or 32-bit Solaris packages are installed. Valid values are 64 and 32. If you do not set this keyword, the installation program installs the default packages. The default for UltraSPARC systems is 64-bit packages. For all other systems, the default is 32-bit packages.

isa_bits is a new keyword. If you use it, you must also use the latest check script in the Solaris_2.7/Misc/jumpstart_sample directory on the Solaris CD.

layout_constraint Profile Keyword

layout_constraint slice constraint [minimum_size]

layout constraint can be used only for the upgrade option when disk space reallocation is required.

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

If you don't specify the layout_constraint keyword, the:

• File systems requiring more space for the upgrade are marked changeable

• File systems on the same disk as the file system requiring more space (mounted by the /etc/vfstab file) are marked changeable

• Remaining file systems are marked fixed (auto-layout can't change them)

If you specify one or more layout_constraint keywords, the

• File systems requiring more space for the upgrade are marked changeable

• File systems for which you specified a layout_constraint keyword are marked with the specified constraint

• Remaining file systems are marked fixed

Even though you can't change the constraint on file systems requiring more space for the upgrade (they must be marked changeable), you can use layout_constraint on those file systems to change their minimum_size values.

To help auto-layout reallocate space, select more file systems to be changeable or moveable, especially those that reside on the same disks as the file systems that require more space for the upgrade.

slice - This is the file system's disk slice on which to specify the constraint. It must be specified in the form cwtxdysz or cxdysz.

constraint - Choose one the following constraints for the specified file system.

• changeable - Auto-layout can move the file system to another location and it can change its size. This 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 will be set to 10% greater than the minimum size required. For example, if the minimum size for a file system is 100 Mbytes, the changed size would be 110 Mbytes. If minimum_size is specified, any free space left (original size minus minimum size) will be used for other file systems.

• movable - Auto-layout can move the file system to another slice (on the same disk or different disk) and its size stays the same.

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

• collapse - Auto-layout will move (collapse) the specified file system into its parent file system. This can be used to reduce the number of file systems on a system as part of the upgrade. For example, if the system has the /usr and /usr/openwin file systems, collapsing the /usr/openwin file system would move it into /usr (its parent). This constraint can only be specified on file systems that are mounted by the /etc/vfstab file.

• minimum_size - This value specifies the size that you want the file system to be when auto-layout reallocates space (it basically lets you change the size of a file system). The size of the file system may end up being more if unallocated space is added to it, but the size will never be less than the value you specify. You can use this optional 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 its existing contents.

Examples:

layout_constraint c0t3d0s1 changeable 200

layout_constraint c0d0s4 movable

layout_constraint c0t3d1s3 availiable

layout_constraint c0t2d0s1 collapse

locale locale_name Profile Keyword

locale locale_name

locale can be used with both the initial installation and upgrade options.

locale designates which locale packages should be installed (or added for upgrade) for the specified locale_name. The locale_name values are the same used for the $LANG environment variable. See Appendix E, Locale Values for a list of valid locale values.

If you have preconfigured a default locale, it 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.

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

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

package Profile Keyword

package package_name [add | delete]

package can be used with both the initial installation and upgrade options.

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 (choose 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.

partitioning Profile Keyword

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.

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.

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.

root_device Profile Keyword

root_device slice

root_device can be used with both the initial installation and upgrade options.

root_device designates the system's root disk. See "How the System's Root Disk Is Determined" for more information.

For Upgrade:

root_device designates the root file system (and the file systems 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. slice must be specified in the form cwtxdysz or cxdysz.

Example:

root_device c0t0d0s2

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.

system_type Profile Keyword

system_type standalone | 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 Profile Keyword

usedisk disk_name [disk_name...]

usedisk designates one or more disks that you want the Solaris installation program to use when partitioning default is specified (by default, the installation program uses all the operational disks on the system). 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.

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

How the Size of Swap Is Determined

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

The Solaris installation program makes 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 allocates the free space to swap, and if possible allocates the amount shown in Table 8-4.

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

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 Solaris installation program sets to the system's root disk. Table 8-5 describes how the installation program determines the system's root disk for the installation. This only applies during an initial installation; a system's root disk cannot change during an upgrade.

Testing a Profile

After you create a profile, you can use the pfinstall(1M) command to test the profile and see if it does what you want before using it to install or upgrade a system (called a "dry run" installation). This is especially useful when you are creating upgrade profiles that reallocate disk space.

By looking at the installation output generated by pfinstall, you can quickly find out if a profile is going to do what you expect and if the installation is going to be successful. For example, you can see if a system will have enough disk space to upgrade to a new release of Solaris before you actually perform the upgrade on the system.

Ways to Test a Profile

pfinstall enables you to test a profile against:

• The system's disk configuration where pfinstall is being run.

• Other disk configurations by using a disk configuration file that represents a structure of a disk (for example, a disk's bytes/sector, flags, slices). See "SPARC: Creating Disk Configuration Files" for detailed information. You cannot use disk configuration files to test an upgrade profile; must test the profile against the system that you're going to upgrade, because you need to test the profile against the system's disk configuration and its currently installed software.

To successfully and accurately test a profile for a particular Solaris release, you must test a profile within the Solaris environment of the same release. For example, if you want to test a profile for Solaris 7, you have to run the pfinstall command on a system running Solaris 7.

So, on a system running Solaris 7, you can test Solaris 7 initial installation profiles. However, if you want to test a Solaris 7 upgrade profile on a system running a previous version of Solaris, or if you don't have a Solaris 7 system installed yet to test Solaris 7 initial installation profiles, you have to boot a system from a Solaris 7 CD image and temporarily create a Solaris 7 install environment. Then, you can run pfinstall in the Solaris 7 install environment to test the profiles you've created.

Creating a temporary Solaris 7 install environment involves booting a system from a Solaris 7 CD image (just as you would to install), answering any system identification questions, choosing the Solaris interactive installation program, and exiting out of the first screen that's presented. Then, from the shell, you can execute the pfinstall command.

How to Test a Profile

1. Locate a system to test the profile that has the same platform type (x86 or SPARC) for which the profile was created.

   If you are testing an upgrade profile, you must use the system that you are going to upgrade.

2. Determine the next step based on your situation.

   If You ...	Then ...
   Need to test an initial installation profile and have a system running Solaris 7	Become superuser on the system and go to Step 9.
   Need to test an upgrade profile, or you don't have a system running Solaris 7 to test an initial installation profile	Go to Step 3.

3. Boot the system from a Solaris 7 image (just as you would to install), which can be located in the system's local CD-ROM or on an install server.

   See Chapter 2, Performing an Interactive Installation for details on booting.

   ---

   Note -

   If you are testing an upgrade profile, boot the system that you are going to upgrade.

   ---

4. Answer the system identification questions, if prompted.

5. If you are presented with a choice of installation options, choose the Solaris Interactive Installation program.

6. Exit from the first screen of the Solaris Interactive Installation program.

   After the Solaris Interactive Installation program exits, a shell prompt is displayed.

7. Create a temporary mount point.

   # mkdir /tmp/mnt

8. Mount the directory that contains the profile(s) you want to test.

   If You Want To ...	Then Type ...
   Mount a remote NFS file system (for systems on the network)	mount -F nfs server_name:path /tmp/mnt
   Mount a UFS-formatted diskette	mount -F ufs /dev/diskette /tmp/mnt
   Mount a PCFS-formatted diskette	mount -F pcfs /dev/diskette /tmp/mnt

9. To test the profile with a specific system memory size, set SYS_MEMSIZE to the specific memory size in Mbytes.

   # SYS_MEMSIZE=memory_size # export SYS_MEMSIZE

10. Change directory to where the profile resides, which is usually the JumpStart directory.

    If you mounted a directory in Step 8, change directory to /tmp/mnt.

    # cd jumpstart_dir_path

11. Test the profile with the pfinstall -d or pfinstall -D command.

    ---

    Caution -

    Without the -d or -D option, pfinstall performs an actual installation of the Solaris software on the system by using the specified profile, and the data on the system is overwritten.

    ---

    # /usr/sbin/install.d/pfinstall -D | -d disk_config [-c path] profile

    -D	Tells pfinstall to use the current system's disk configuration to test the profile.
    -d disk_config	Tells pfinstall to use a disk configuration file, disk_config, to test the profile. If disk_config file is not in the directory where pfinstall is run, you must specify the path. This option cannot be used with an upgrade profile (install-type upgrade). You must always test an upgrade profile against a system's disk configuration (-D option).
    -c path	Is the path to the Solaris CD image. This is required if the Solaris CD is not mounted on /cdrom. For example, use this option if the system is using Volume Management to mount the Solaris CD. Note - This option is not required if you have booted from a Solaris CD image, because the Solaris CD image is mounted on /cdrom as part of the booting process.
    profile	Is the name of the profile to test. If profile is not in the directory where pfinstall is being run, you must specify the path.

Where to Go Next

You have completed testing the profile. To continue, see "Validating the rules File".

Example-Testing a Profile

The following example tests the basic_prof profile against the disk configuration on a Solaris 7 system where pfinstall is being run. The basic_prof profile is located in the /jumpstart directory and the path to the Solaris CD image is specified because Volume Management is being used.

# cd /jumpstart
# /usr/sbin/install.d/pfinstall -D -c /cdrom/cdrom0/s0 basic_prof

The following example tests the basic_prof profile against the 535_test disk configuration file and 64 Mbytes of system memory. This example uses a Solaris CD image located in the /export/install directory, and pfinstall is being run on a Solaris 7 system.

# SYS_MEMSIZE=64
# export SYS_MEMSIZE
# /usr/sbin/install.d/pfinstall -d 535_test -c /export/install basic_prof

Validating 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. If all the rules and profiles are valid, the rules.ok file is created, which is required by the custom JumpStart installation software to match a system to a profile. Table 8-6 shows what the check script does.

The rules.ok file should be owned by root and have permissions equal to 644.

How 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 Solaris_2.7/Misc/jumpstart_sample directory on the Solaris CD.

   ---

2. Change the directory to the JumpStart directory.

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

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

   -p path	Validates the rules file by using the check script from a specified Solaris CD image, instead of the check script from the system you are using. path is a Solaris installation image on a local disk or a mounted Solaris CD. Use this option to run the most recent version of check if your system 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 custom JumpStart configuration is ok.

Where to Go Next

The rules files is now validated. To read about the optional features available for custom JumpStart installations, see Chapter 9, Using Optional Custom JumpStart Features. To perform a custom JumpStart installation on a system, see Chapter 3, Performing a Custom JumpStart Installation.