This chapter provides the step-by-step instructions on how to prepare your site to perform custom JumpStart installations.
Appendix D, Sample Custom JumpStart Setup provides a detailed example of how you would prepare a fictitious site for custom JumpStart installations.
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 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 engineering 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.
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-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.
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 a 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.
Task | Description | For Instructions, Go To | |||||
---|---|---|---|---|---|---|---|
Create a JumpStart Directory |
On a Diskette If you want to perform custom JumpStart installations on systems that are not connected to a network, you must create a profile diskette, which is a diskette that contains the custom JumpStart files. | ||||||
On a Server If you want to perform custom JumpStart installations on systems connected to a network, you should create a profile server, which is a server that contains a JumpStart directory for the custom JumpStart files. | |||||||
| |||||||
Enable All Systems to Access the Profile Server |
Optional. When you use a profile server, you can enable all systems at once to access the profile server. By doing this, you don't have to individually enable every system to access the profiles on the profile server. | ||||||
| |||||||
Add Rules to the rules File |
After you decide how you want each group of systems (or single systems) at your site to be installed, you have to create a rule for each specific group that you want to install. Each rule distinguishes a group based on one or more system attributes, and it links each group to a profile. | ||||||
| |||||||
Create a Profile for Every Rule |
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. | ||||||
| |||||||
Test the Profiles |
Optional. After you create a profile, you should use the pfinstall(1M) command to test the profile before using it to install or upgrade a system (called a "dry run" installation). | ||||||
| |||||||
Validate the rules File |
The rules.ok file is a generated version of the rules file that the Solaris installation program uses to match the system to be installed with a profile. You must use the check script to validate the rules.ok file. | ||||||
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.
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 for detailed information about managing removable media without Volume Management.
Log in as root on the server where you want the JumpStart directory to reside.
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 would create the directory called jumpstart in the root file system:
mkdir /jumpstart |
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 share the /jumpstart directory:
share -F nfs -o ro,anon=0 /jumpstart |
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.
Change directory to the Misc directory on the Solaris CD image.
# cd Solaris_2.6/Misc |
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.
You have completed creating a profile server. To continue, see "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".
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.
On the install server or boot server, log in as root.
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 |
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.
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".
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, as expected, 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.
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.
Log in as root on an x86 or SPARC based system that has a diskette drive.
Insert the Configuration Assistant diskette into the diskette drive.
Make sure Volume Management knows about the diskette.
# volcheck |
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 |
Manually eject the Configuration Assistant diskette.
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.
Make sure Volume Management knows about the diskette.
# volcheck |
This step will overwrite any data on the diskette.
# fdformat -d -U |
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.
Eject the diskette.
# eject floppy |
Insert the copied boot diskette back into the diskette drive.
Make sure Volume Management knows about the diskette.
# volcheck |
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 |
|
|
Change directory to the Solaris CD image on the local disk. For example:
|
Change directory to the Misc directory on the Solaris CD image.
# cd Solaris_2.6/Misc |
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.
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.
When using a profile diskette, all the custom JumpStart installation files must be in the root directory of the diskette.
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".
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).
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 for detailed information about managing removable media without Volume Management.
Log in as root on a SPARC based system that has a diskette drive and a CD-ROM drive.
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.
Make sure Volume Management knows about the diskette.
# volcheck |
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 |
This step will overwrite any data on the disk.
# fdformat -U |
Create a UFS file system on the diskette.
# newfs /vol/dev/aliases/floppy0 |
Eject the diskette.
# eject floppy |
Insert the formatted diskette back into the diskette drive.
Make sure Volume Management knows about the diskette.
# volcheck |
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 |
|
|
Solaris CD image on the local disk |
Change the directory to the Solaris CD image on the local disk. For example:
|
Change directory to the Misc directory on the Solaris CD image.
# cd Solaris_2.6/Misc |
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.
When using a profile diskette, all the custom JumpStart installation files must be in the root directory of the diskette.
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".
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.
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.
At least one rule.
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.
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.
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:
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. |
|
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. |
|
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. |
|
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. |
|
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". |
|
Is 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" for detailed information on how to create finish scripts. |
Save the rules file into the JumpStart directory.
The rules file should be owned by root and have permissions equal to 644.
This completes the procedure to create a rules file. To create profiles, go to "Creating a Profile".
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 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 16-32 Mbytes of memory and its a PowerPC. The prog_prof profile is used to install the Solaris software on systems that match this rule.] memsize 16-32 && arch ppc - 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 - |
Table 8-2 describes the rule keywords and rule values that you can use in the rules file.
Table 8-2 Rule Keyword and Rule Value Descriptions
Rule Keyword |
Rule Values |
Description |
|
---|---|---|---|
minus sign (-) |
Match always succeeds. |
||
processor_type The following table lists the valid values for processor_type. platform processor_type SPARC sparc x86 i386 |
Matches a system's processor type. The uname -p command reports the system's processor type. |
||
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. |
||
disk_name size_range disk_name - A disk name in the form cxtydz, such as c0t3d0, or the special word rootdisk. If rootdisk is used, the disk to be matched is determined in the following order:
size_range - The size of the disk, which must be specified as a range of Mbytes (xx-xx). |
Matches a system's disk (in Mbytes). Example:
The example tries to match a system with a c0t3d0 disk that is between 250 and 300 Mbytes. Note - When calculating size_range, remember that a Mbyte equals 1,048,576 bytes. A disk may be advertised as a "535 Mbyte" disk, but it may have only 510 million bytes of disk space. The Solaris installation program will actually view the "535 Mbyte" disk as a 510 Mbyte disk because 535,000,000 / 1,048,576 = 510. So, a "535 Mbyte" disk would not match a size_range equal to 530-550. |
||
IP_address |
Matches a system's IP address. |
||
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. |
||
slice version slice - A disk slice name in the form cwtxdysz, such as c0t3d0s5, or the special words any or rootdisk. If any is used, all of the system's disks will try to be matched (in kernel probe order). If rootdisk is used, the disk to be matched is determined in the following order:
version - A version name, Solaris_2.x, 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. |
Matches a disk that has a root file system corresponding to a particular version of Solaris software. Example:
The example tries to match a system that has a Solaris 2.5 root files system on c0t3d0s1. |
||
platform_group Valid values are sun4d, sun4c, sun4m, sun4u, i86pc, or prep. (See Appendix C, Platform Names and Groups for a detailed list of systems and their corresponding platform group.) |
Matches a system's platform group. If you have a system already installed, the arch -k command or the uname -m command reports the system's platform group. |
||
physical_mem The value must be a range of Mbytes (xx-xx) or a single Mbyte value. |
Matches a system's physical memory size (in Mbytes). Example:
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 output of the prtconf command (line 2) reports the system's physical memory size. |
||
platform_name |
Matches a system's platform name. See Appendix C, Platform Names and Groups for a list of valid platform names. To find the platform name of an installed system, use the uname -i command or the output of the prtconf command (line 5). Note - If the platform_name contains spaces, you must enclose it in single quotes ('). For example: 'SUNW,Sun 4_50' |
||
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:
The example tries to match a system with a 193.144.2.8 IP address (if the subnet mask were 255.255.255.0). |
||
Solaris_2.x |
Matches a version of Solaris software already installed on a system. Example:
The example tries to match a system with Solaris 2.5 already installed. |
||
size_range The value must be specified as a range of Mbytes (xx-xx). |
Matches the total disk space on a system (in Mbytes). The total disk space includes all the operational disks attached to a system. Example:
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 1,048,576 bytes. A disk may be advertised as a "535 Mbyte" disk, but it may have only 510 million bytes of disk space. The Solaris installation program will actually view the "535 Mbyte" disk as a 510 Mbyte disk because 535,000,000 / 1,048,576 = 510. So, a "535 Mbyte" disk would not match a size_range equal to 530-550. |
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 on "Creating a Profile Diskette " or "Creating a Profile Server", example profiles should already be in the JumpStart directory.
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.
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).
Add profile keywords and profile values to the profile.
Refer to the following information as you edit the profile:
Save the profile into the JumpStart directory.
A profile should be owned by root and have permissions equal to 644.
Test the profile (optional).
See "Testing a Profile" for detailed information.
This completes the procedure to create a profile. After you've created all your profiles, go to "Validating the rules File".
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.
# 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 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.] 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 OpenLook and X Windows 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 |
# 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 it is installed on c0t0d0s0; the size of swap is set to 32 Mbytes and it 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 |
# 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 |
# 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 |
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.
Table 8-3 Profile Keyword Overview
Installation Scenarios |
|||||
---|---|---|---|---|---|
Profile Keywords |
Standalone System (Non-Networked) |
Standalone System (Networked) or Server |
OS Server |
Upgrade |
Upgrade with Disk Space Reallocation |
backup_media |
x |
||||
boot_device |
x |
x |
x | ||
client_arch |
x | ||||
client_root |
x | ||||
client_swap |
x | ||||
cluster (adding software groups) |
x |
x |
x | ||
cluster (adding/deleting clusters) |
x |
x |
x |
x |
x |
dontuse |
x |
x |
x | ||
fdisk |
x |
x |
x | ||
filesys (mounting remote filesystems) |
x |
x | |||
filesys (creating local filesystems) |
x |
x |
x | ||
install_type |
x |
x |
x |
x |
x |
layout_constraint |
x |
||||
locale |
x |
x |
x |
x |
x |
num_clients |
x | ||||
package |
x |
x |
x |
x |
x |
paritioning |
x |
x |
x |
|
|
root_device |
x |
x |
x |
x |
x |
system_type |
x |
x |
x |
|
|
usedisk |
x |
x |
x |
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.
Valid type Values |
Valid path Values |
Description |
---|---|---|
local_tape |
/dev/rmt/n |
Specifies a local tape drive on the system being upgraded. path must be the character (raw) device path for the tape drive, where n is the number of the tape drive. |
local_diskette |
/dev/rdisketten |
Specifies a local diskette drive on the system being upgraded. path must be the character (raw) device path for the diskette drive, where n is the number of the diskette drive. Note - Diskettes used for the backup must be formatted. |
local_filesystem |
/dev/dsk/cwtxdysz /file_system |
Specifies a local file system on the system being upgraded. You cannot specify a local file system that is being changed by the upgrade. path can be a block device path for a disk slice (tx may not be needed) or the absolute path to a file system mounted by the /etc/vfstab file. |
remote_filesystem |
host:/file_system |
Specifies an NFS file system on a remote system. path must include the name or IP address of the remote system (host) and the absolute path to the NFS file system (file_system). The NFS file system must have read/write access. |
remote_system | user@host:/directory |
Specifies a directory on a remote system that can be reached by a remote shell (rsh). The system being upgraded must have access to the remote system through the remote system's .rhosts file. path must include the name of the remote system (host) and the absolute path to the directory (directory). If a user login (user) is not specified, the login will be tried as root. |
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 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 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, or 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 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 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 group_name |
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 (SPARC based systems only) | 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.
cluster cluster_name [add | delete] |
cluster (adding/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. Table A-3 and Table A-4 also provide a list of the clusters included in each software group.
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 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 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 on "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 number (valid values are 1 through 255).
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).
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:
fdisk Type |
DDD |
HH |
---|---|---|
DOSOS12 |
1 |
01 |
PCIXOS |
2 |
02 |
DOSOS16 |
4 |
04 |
EXTDOS |
5 |
05 |
DOSHUGE |
6 |
06 |
DOSDATA |
86 |
56 |
OTHEROS |
98 |
62 |
UNIXOS |
99 |
63 |
size - 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 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).
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).
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 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 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.
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 on "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.
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.
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.
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 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.
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.
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.
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.
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 |
locale can be used with both the initial installation and upgrade options.
locale designates which language or 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, Language and Locale Values for a list of valid language and locale values.
If you've preconfigured a default language or locale, it is automatically installed. The English language packages are installed by default.
You can specify a locale keyword for each language or locale you need to add to a system.
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 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. Table A-3 and Table A-4 also provide a list of the packages included in each software group.
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 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 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 (not required), the root_device and the disk must match. Also, any filesys keywords that specify the root file system must match root_device.
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 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.
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 8-4 shows how the maximum size of swap is determined during a custom JumpStart installation.
Table 8-4 How the Maximum Size of Swap Is Determined
Physical Memory (in Mbytes) |
Maximum Size of Swap (in Mbytes) |
---|---|
16 - 64 |
32 |
64 - 128 |
64 |
128 - 512 |
128 |
Greater than 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 8-4.
Physical memory plus swap space must be a minimum of 32 Mbytes.
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.
Table 8-5 How the Installation Program Determines the System's Root Disk (Initial Installation Only)
Stage |
Action |
---|---|
1 |
If the root_device keyword is specified in the profile, the installation program sets rootdisk to the root device. |
2 |
If rootdisk is not set and the boot_device keyword is specified in the profile, the installation program sets rootdisk to the boot device. |
3 |
If rootdisk is not set and a filesys cwtxdysz size / entry is specified in the profile, the installation program sets rootdisk to the disk specified in the entry. |
4 |
If rootdisk is not set and a rootdisk.sn entry is specified in the profile, the installation program searches the system's disks (in kernel probe order) for an existing root file system on the specified slice. If a disk is found, the installation program sets rootdisk to the found disk. |
5 |
If rootdisk is not set and partitioning existing is specified in the profile, the installation program searches the system's disks (in kernel probe order) for an existing root file system. If a root file system is not found or more than one is found, an error will occur. If a root file system is found, the installation program sets rootdisk to the found disk. |
6 |
If rootdisk is not set, the installation program sets rootdisk to the disk where the root file system will be installed. |
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.
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 2.6, you have to run the pfinstall command on a system running Solaris 2.6.
So, on a system running Solaris 2.6, you can test Solaris 2.6 initial installation profiles. However, if you want to test a Solaris 2.6 upgrade profile on a system running a previous version of Solaris, or if you don't have a Solaris 2.6 system installed yet to test Solaris 2.6 initial installation profiles, you have to boot a system from a Solaris 2.6 CD image and temporarily create a Solaris 2.6 install environment. Then, you can run pfinstall in the Solaris 2.6 install environment to test the profiles you've created.
Creating a temporary Solaris 2.6 install environment involves booting a system from a Solaris 2.6 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.
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.
Determine the next step based on your situation.
If You ... |
Then ... |
---|---|
Need to test an initial installation profile and have a system running Solaris 2.6 |
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 2.6 to test an initial installation profile |
Go to Step 3. |
Boot the system from a Solaris 2.6 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.
If you are testing an upgrade profile, boot the system that you are going to upgrade.
Answer the system identification questions, if prompted.
If you are presented with a choice of installation options, choose the Solaris Interactive Installation program.
Exit from the first screen of the Solaris interactive installation program.
After the Solaris interactive installation program exits, a shell prompt displays.
Create a temporary mount point.
# mkdir /tmp/mnt |
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 a UFS-formatted diskette |
|
|
Mount a PCFS-formatted diskette |
|
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 |
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 |
Test the profile with the pfinstall -d or pfinstall -D command.
Without the -d or -D option, pfinstall will perform an actual installation of the Solaris software on the system by using the specified profile, and the data on the system will be overwritten.
# /usr/sbin/install.d/pfinstall -D | -d disk_config [-c path] profile |
Tells pfinstall to use the current system's disk configuration to test the profile against. |
|
Tells pfinstall to use a disk configuration file, disk_config, to test the profile against. 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). |
|
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. |
You have completed testing the profile. To continue, see "Validating the rules File".
The following example tests the basic_prof profile against the disk configuration on a Solaris 2.6 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 2.6 system.
# SYS_MEMSIZE=64 # export SYS_MEMSIZE # /usr/sbin/install.d/pfinstall -d 535_test -c /export/install basic_prof |
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.
Table 8-6 What Happens When You Use check
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 |
The rules.ok file should be owned by root and have permissions equal to 644.
Make sure that the check script resides in the JumpStart directory.
The check script is provided in the Solaris_2.6/Misc/jumpstart_sample directory on the Solaris CD.
Run the check script to validate the rules file.
$ ./check [-p path] [-r file_name] |
Validates the rules file by using the check script from a specified Solaris 2.6 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. |
|
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.
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.