Part I Using Custom JumpStart

This part provides instructions for creating, preparing, and performing custom JumpStart installations.

Chapter 1 Where to Find Solaris Installation Planning Information

This book provides information on how to use the automated JumpStart installation program to install the Solaris operating system. This book provides all you need to know about installing with the JumpStart program, but a planning book in our collection of installation documentation might be useful to read before you begin preparing for a JumpStart installation. The following references provide useful information before you install your system.

Where to Find Planning and System Requirement Information

The Solaris 10 8/07 Installation Guide: Planning For Installation and Upgrade provides system requirements and high-level planning information, such as planning guidelines for file systems, and upgrade planning and much more. This section provides an overview of the chapters for this book.

Chapter 2 Custom JumpStart (Overview)

This chapter provides an introduction and overview to the custom JumpStart installation process.

• Custom JumpStart Introduction

• How the JumpStart Program Installs Solaris Software

Custom JumpStart Introduction

The custom JumpStart installation method is a command–line interface that enables you to automatically install or upgrade several systems, based on profiles that you create. The profiles define specific software installation requirements. You can also incorporate shell scripts to include preinstallation and postinstallation tasks. You choose which profile and scripts to use for installation or upgrade. The custom JumpStart installation method installs or upgrades the system, based on the profile and scripts that you select. Also, you can use a sysidcfg file to specify configuration information so that the custom JumpStart installation is completely hands-off.

Custom JumpStart Example Scenario

The custom JumpStart process can be described by using an example scenario. In this example scenario, the systems need to be set up with the following parameters:

• Install Solaris on 100 new systems.

• Seventy of the systems are SPARC based systems that are owned by the engineering group and need to be installed as standalone systems with the Solaris OS software group for developers.

• The remaining 30 systems are x86 based, owned by the marketing group and need to be installed as standalone systems with the Solaris OS software group for end users.

First, the system administrator must create a rules file and a profile for each group of systems. The rules file is a text file that contains a rule for each group of systems or single systems on which you want to install the Solaris software. Each rule distinguishes a group of systems that are based on one or more system attributes. Each rule also links each group to a profile.

A profile is a text file that defines how the Solaris software is to be installed on each system in the group. Both the rules file and profile must be located in a JumpStart directory.

For the example scenario, the system administrator creates a rules file that contains two different rules, one for the engineering group and another for the marketing group. For each rule, the system's network number is used to distinguish the engineering group from the marketing group.

Each rule also contains a link to an appropriate profile. For example, in the rule for the engineering group, a link is added to the profile, eng_profile, which was created for the engineering group. In the rule for the marketing group, a link is added to the profile, market_profile, which was created for the marketing group.

You can save the rules file and the profiles on a diskette or on a server.

• A profile diskette is required when you want to perform custom JumpStart installations on nonnetworked, standalone systems.

• A profile server is used when you want to perform custom JumpStart installations on networked systems that have access to a server.

After creating the rules file and profiles, validate the files with the check script. If the check script runs successfully, the rules.ok file is created. The rules.ok is a generated version of the rules file that the JumpStart program uses to install the Solaris software.

How the JumpStart Program Installs Solaris Software

After you validate the rules file and the profiles, you can begin a custom JumpStart installation. The JumpStart program reads the rules.ok file. Then, the JumpStart program searches for the first rule with defined system attributes that match the system on which the JumpStart program is attempting to install the Solaris software. If a match occurs, the JumpStart program uses the profile that is specified in the rule to install the Solaris software on the system.

Figure 2–1 illustrates how a custom JumpStart installation works on a standalone, nonnetworked system. The system administrator initiates the custom JumpStart installation on Pete's system. The JumpStart program accesses the rules files on the diskette in the system's diskette drive. The JumpStart program matches rule 2 to the system. rule 2 specifies that the JumpStart program use Pete's profile to install the Solaris software. The JumpStart program reads Pete's profile and installs the Solaris software, based on the instructions that the system administrator specified in Pete's profile.

Figure 2–1 How a Custom JumpStart Installation Works: nonnetworked Example

Figure 2–2 illustrates how a custom JumpStart installation works with more than one system on a network. Previously, the system administrator set up different profiles and saved the profiles on a single server. The system administrator initiates the custom JumpStart installation on one of the engineering systems. The JumpStart program accesses the rules files in the JumpStart/ directory on the server. The JumpStart program matches the engineering system to rule 1. rule 1 specifies that the JumpStart program use Engineering Group's Profile to install the Solaris software. The JumpStart program reads Engineering Group's Profile and installs the Solaris software, based on the instructions that the system administrator specified in Engineering Group's Profile.

Figure 2–2 How a Custom JumpStart Installation Works: Networked Example

Figure 2–3 describes the order in which the JumpStart program searches for custom JumpStart files.

Figure 2–3 What Happens During a Custom JumpStart Installation

Chapter 3 Preparing Custom JumpStart Installations (Tasks)

This chapter provides step-by-step instructions about how to prepare the systems at your site from which and on which you intend to install the Solaris software by using the custom JumpStart installation method.

• Task Map: Preparing Custom JumpStart Installations

• Creating a Profile Server for Networked Systems

• Creating a Profile Diskette for Standalone Systems

• Creating the rules File

• Creating a Profile

• Testing a Profile

• Validating the rules File

Task Map: Preparing Custom JumpStart Installations

Creating a Profile Server for Networked Systems

When setting up custom JumpStart installations for systems on the network, you need to create a directory on a server that is called a JumpStart directory. The JumpStart directory contains all of the essential custom JumpStart files, for example, the rules file, rules.ok file, and profiles. You must save the JumpStart directory in the root (/) directory of the profile server.

The server that contains a JumpStart directory is called a profile server. A profile server can be the same system as an install server or a boot server, or the server can be a completely different server. A profile server can provide custom JumpStart files for different platforms. For example, an x86 server can provide custom JumpStart files for both SPARC based systems and x86 based systems.

After you create a profile server, you must allow systems to access the server. For detailed instructions, see To Allow All Systems Access to the Profile Server.

To Create a JumpStart Directory on a Server

This procedure assumes that the system is running Volume Manager. If you are not using Volume Manager to manage discs, refer to System Administration Guide: Devices and File Systems for detailed information about managing removable media without Volume Manager.

1. Locate the server on which you want to create the JumpStart directory.

2. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

3. Create the JumpStart directory anywhere on the server.

   # mkdir -m 755 jumpstart_dir_path

   In the command, jumpstart_dir_path is the absolute path of the JumpStart directory.

   For example, the following command creates a directory that is called jumpstart in the root (/) directory and sets the permissions to 755:

   # mkdir -m 755 /jumpstart

4. Edit the /etc/dfs/dfstab file by adding 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

5. Type shareall and press Enter.

6. Determine if you want to copy examples of custom JumpStart files to your JumpStart directory.

   • If no, go to Step 9.

   • If yes, use the following decision table to determine what to do next.

   Example Locations	Instructions
   The Solaris Operating System DVD or the Solaris Software - 1 CD for your platform	Insert the Solaris Operating System DVD or the Solaris Software - 1 CD into the server's CD-ROM drive.  Volume Manager automatically mounts the CD or DVD.
   An image of the Solaris Operating System DVD or the Solaris Software - 1 CD for your platform on a local disk	Change directory to the location of the Solaris Operating System DVD or the Solaris Software - 1 image. For example, type the following command:  cd /export/install

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

   # cp -r media_path/Solaris_10/Misc/jumpstart_sample/* jumpstart_dir_path

   media_path

   The path to the CD, DVD, or image on the local disk

   jumpstart_dir_path

   The path on the profile server where you are placing the example custom JumpStart files

   For example, the following command copies the jumpstart_sample directory into the /jumpstart directory on the profile server:

   • For SPARC based systems:

     cp -r /cdrom/cdrom0/s0/Solaris_10/Misc/jumpstart_sample/* /jumpstart

   • For x86 based systems:

     cp -r /cdrom/cdrom0/Solaris_10/Misc/jumpstart_sample/* /jumpstart

8. Update the example JumpStart files so that the files work in your environment.

9. Ensure that root owns the JumpStart directory and that the permissions are set to 755.

10. Allow systems on the network to access the profile server.

    For detailed instructions, see To Allow All Systems Access to the Profile Server.

Allowing All Systems Access to the Profile Server

When you create a profile server, you must ensure that systems can access the JumpStart directory on the profile server during a custom JumpStart installation. Use one of the following ways to ensure access.

To Allow All Systems Access to the Profile Server

Use the following procedure only if you store network installation information in the following places:

• In the /etc/bootparams file.

• In the naming service bootparams database. To update the bootparams database, add the entry that is shown in Step 3.

If you use the following procedure, the systems must be of the same type, such as all SPARC systems.

Do not use this procedure under the following conditions:

• If you save the JumpStart directory on a diskette.

• If you specify the location of the profile server when you boot the system. If you have systems of different architectures, you must specify the location of the profile server when you boot the system

If you have the above conditions, use the SPARC boot command or use the x86 GRUB menu.

You also can store network installation information on a DHCP server.

• For SPARC based systems, you use the add_install_client command and the -d option to specify that the custom JumpStart program use the DHCP server. Or you use the boot command with the dhcp option to specify that the custom JumpStart program use the DHCP server. For instructions about using this option, see SPARC: Command Reference for the boot Command.

• For x86 based systems, you use dhcp in one of the following ways:

  • If you use an install server, use the add_install_client command and the -d option to specify that the custom JumpStart program use the DHCP server with PXE.

  • You can edit the GRUB entry on the GRUB menu and add the dhcp option. For instructions about editing the GRUB entry, see x86: Performing a Custom JumpStart Installation by Editing the GRUB Boot Command

1. On the installation or boot server, log in as superuser.

2. Use a text editor to open /etc/bootparams.

3. Add this entry.

   * install_config=server:jumpstart_dir_path

   *

   A wildcard character that specifies that all systems have access

   server

   The host name of the profile server where the JumpStart directory is located

   jumpstart_dir_path

   The absolute path of the JumpStart directory

   For example, the following entry enables all systems to access the /jumpstart directory on the profile server that is named sherlock:

   * install_config=sherlock:/jumpstart

   ---

   Caution –

   Use of this procedure might produce the following error message when an installation client is booted:

   WARNING: getfile: RPC failed: error 5: (RPC Timed out).

   Booting From the Network, Error Messages contains details about this error message.

   ---

   All systems can now access the profile server.

Creating a Profile Diskette for Standalone Systems

A diskette that contains a JumpStart directory is called a profile diskette. A system that is not connected to the network does not have access to a profile server. As a result, you must create a JumpStart directory on a diskette if a system is not connected to a network. The system on which you create a profile diskette must have a diskette drive.

The JumpStart directory contains all of the essential custom JumpStart files, for example, the rules file, rules.ok file, and profiles. You must save the JumpStart directory in the root (/) directory of the profile diskette.

See one of the following procedures:

• SPARC: To Create a Profile Diskette

• x86: To Create a Profile Diskette With GRUB

SPARC: To Create a Profile Diskette

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

1. Locate a SPARC based system to which a diskette drive is attached.

2. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

3. Insert a blank diskette or a diskette that can be overwritten in the diskette drive.

4. Mount the diskette.

   # volcheck

5. Determine if the diskette contains a UNIX file system (UFS).

   Examine the contents of the file /etc/mnttab on the system for an entry such as the following:

   /vol/dev/diskette0/scrap /floppy/scrap ufs suid,rw,largefiles,dev=1740008 927147040

   • If the entry exists, go to Step 7.

   • If the entry does not exist, go to the next step.

6. Create a UFS on the diskette.

   # newfs /vol/dev/aliases/floppy0

7. Determine if you want to copy examples of custom JumpStart files to your JumpStart directory.

   • If no, go to Step 10.

   • If yes, use the following decision table to determine what to do next.

   Example Locations	Instructions
   The Solaris Operating System for SPARC Platforms DVD or the Solaris Software for SPARC Platforms - 1 CD	Insert the Solaris Operating System for SPARC Platforms DVD or the Solaris Software for SPARC Platforms - 1 CD into the server's CD-ROM drive.  Volume Manager automatically mounts the CD or DVD.
   An image of the Solaris Operating System for SPARC Platforms DVD or the Solaris Software for SPARC Platforms - 1 CD on a local disk	Change the directory to the location of the Solaris Operating System for SPARC Platforms DVD or the Solaris Software for SPARC Platforms - 1 CD image. For example, type the following command:  cd /export/install

8. Copy the example custom JumpStart files into the JumpStart directory on the profile diskette.

   # cp -r media_path/Solaris_10/Misc/jumpstart_sample/* jumpstart_dir_path

   media_path

   The path to the CD, DVD, or image on the local disk

   jumpstart_dir_path

   The path to the profile diskette where you want to place the example custom JumpStart files

   ---

   Note –

   You must place all custom JumpStart installation files in the root (/) directory on the diskette.

   ---

   For example, the following command copies the contents of jumpstart_sample on the Solaris Software for SPARC Platforms - 1 CD to the root (/) directory on a profile diskette that is named scrap:

   cp -r /cdrom/cdrom0/s0/Solaris_10/Misc/jumpstart_sample/* /floppy/scrap

9. Update the example JumpStart files on the profile diskette so that the files work in your environment.

10. Ensure that root owns the JumpStart directory and that permissions are set to 755.

11. Eject the diskette.

    # eject floppy

    You have completed the creation of a profile diskette. You can now update the rules file and create profiles on the profile diskette to perform custom JumpStart installations. To continue, go to Creating the rules File.

x86: To Create a Profile Diskette With GRUB

Use this procedure to create a profile diskette with GRUB. A GRUB menu is provided during the installation procedure that enables the boot process. The GRUB menu replaces the Solaris Device Configuration Assistant that might have been needed to boot a system in past releases.

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

1. Locate an x86 based system to which a diskette drive is attached.

2. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

3. Insert a blank diskette or a diskette that can be overwritten into the diskette drive.

4. Mount the diskette.

   # volcheck

5. Determine if you want to copy examples of custom JumpStart files to your JumpStart directory.

   • If no, go to Step 8.

   • If yes, use the following decision table to determine what to do next.

   Example Locations	Instructions
   The Solaris Operating System for x86 Platforms DVD or the Solaris Software for x86 Platforms - 1 CD	Insert the Solaris Operating System for x86 Platforms DVD or the Solaris Software for x86 Platforms - 1 CD into the server's CD-ROM drive.  Volume Manager automatically mounts the DVD or CD.
   An image of the Solaris Operating System for x86 Platforms DVD or the Solaris Software for x86 Platforms - 1 CD on a local disk	Change directory to the location of the Solaris Operating System for x86 Platforms DVD or the Solaris Software for x86 Platforms - 1 CD image. For example, type the following:  cd /export/install

6. Copy the example custom JumpStart files into the JumpStart directory on the profile diskette.

   # cp -r media_path/Solaris_10/Misc/jumpstart_sample/* jumpstart_dir_path

   media_path

   The path to the CD, DVD, or image on the local disk

   jumpstart_dir_path

   The path to the profile diskette where you want to place the example custom JumpStart files

   ---

   Note –

   You must place all custom JumpStart installation files in the root (/) directory on the profile diskette.

   ---

   For example, the following command copies the contents of jumpstart_sample on the Solaris Software for x86 Platforms - 1 CD to the root (/) directory on a profile diskette that is named scrap:

   cp -r /cdrom/cdrom0/Solaris_10/Misc/jumpstart_sample/* /floppy/scrap

7. Update the example JumpStart files on the profile diskette so that the files work in your environment.

8. Ensure that root owns the JumpStart directory and that permissions are set to 755.

9. Eject the diskette by clicking Eject Disk in the File Manager window or by typing eject floppy on the command line.

10. In the Removable Media Manager dialog box, click OK.

11. Manually eject the diskette.

See Also

You have completed the creation of 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

The rules file is a text file that contains a rule for each group of systems on which you want to install the Solaris OS. Each rule distinguishes a group of systems that are based on one or more system attributes. Each rule also links each group to a profile. A profile is a text file that defines how the Solaris software is to be installed on each system in the group. For example, the following rule specifies that the JumpStart program use the information in the basic_prof profile to install any system with the sun4u platform group.

karch sun4u - basic_prof -

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 in Creating a Profile Diskette for Standalone Systems or Creating a Profile Server for Networked Systems, an example rules file is already located in the JumpStart directory. The sample rules file contains documentation and some example rules. If you use the sample rules file, ensure that you comment out the example rules you do not intend to use.

Syntax of the rules File

The rules file must have the following attributes:

• The file must be assigned the name rules.

• The file must contain at least one rule.

The rules file can contain any of the following:

• Commented text

  Any text that is included after the # symbol on a line is treated by JumpStart as commented text. If a line begins with the # symbol, the entire line is treated as a comment.

• One or more blank lines

• One or more multiline rules

  To continue a single rule onto a new line, include a backslash character (\) just before pressing Return.

To Create a rules File

1. Use a text editor to create a text file that is named rules. Or, open the sample rules file in the JumpStart directory that you created.

2. Add a rule in the rules file for each group of systems on which you want to install the Solaris software.

   For a list of rules file keywords and values, see Rule Keywords and Values.

   A rule within a rules file must adhere to the following syntax:

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

   !

   A symbol that is used before a keyword to indicate negation.

   rule_keyword

   A predefined lexical unit or word that describes a general system attribute, such as host name, hostname, or memory size, memsize. rule_keyword is used with the rule value to match a system with the same attribute to a profile. For the list of rule keywords, see Rule Keywords and Values.

   rule_value

   A value that provides the specific system attribute for the corresponding rule keyword. Rule values are described in Rule Keywords and Values.

   &&

   A symbol you must use to join rule keyword and rule value pairs 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

   The name of an optional Bourne shell script that can be executed before the installation begins. If no begin script exists, you must type a minus sign (-) in this field. All begin scripts must be located in the JumpStart directory.

   Information about how to create begin scripts is presented in Creating Begin Scripts.

   profile

   The name of a text file that defines how the Solaris software is to 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 be located in the JumpStart directory.

   ---

   Note –

   Optional ways to use the profile field are described in Using a Site-Specific Installation Program and Creating Derived Profiles With a Begin Script.

   ---

   finish

   The name of an optional Bourne shell script that can be executed after the installation is completed. If no finish script exists, you must type a minus sign (-) in this field. All finish scripts must be located in the JumpStart directory.

   Information about how to create finish scripts is presented in Creating Finish Scripts.

   At the minimum, each rule must contain the following:

   • A keyword, a value, and a corresponding profile

   • A minus sign (-) in the begin and finish fields if no begin or finish scripts are specified

3. Save the rules file in the JumpStart directory.

4. Ensure that root owns the rules file and that the permissions are set to 644.

rules File Example

The following example shows several example rules in a rules file. Each line has a rule keyword and a valid value for that keyword. The JumpStart program scans the rules file from top to bottom.

When the JumpStart program matches a rule keyword and value with a known system, the JumpStart program installs the Solaris software that is specified by the profile that is listed in the profile field.

For a complete list of rules file limitations, see Syntax of the rules File.

Example 3–1 rule File

 # rule keywords and rule values       begin script       profile       finish script
 # -----------------------------       ------------       --------      -------------
  hostname eng-1                       -                  basic_prof    -
  network 192.168.255.255 && !model \
 'SUNW,Sun-Blade-100'                  -                  net_prof      -
  model SUNW,SPARCstation-LX           -                  lx_prof       complete
  network 192.168.2.0 && karch i86pc  setup               x86_prof      done
  memsize 64-128 && arch i386          -                  prog_prof     -
  any   -                              -                  generic_prof  -

The following list describes some of the keywords and values from this example.

hostname

The 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 the rule.

network

The rule matches if the system is on subnet 192.168.255.255 and if the system is not a Sun Blade ^TM 100 (SUNW,Sun-Blade-100). The net_prof profile is used to install the Solaris software on systems that match this rule. This rule also provides an example of continuing a single rule onto a new line by using the backslash character (\).

model

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.

network

The rule matches if the system is on subnet 192.168.2.0 and is an x86 based sun4u system. The setup begin script, the x864u_prof profile, and the done finish script are used to install the Solaris software on systems that match the rule.

memsize

The rule matches if the system has between 64 and 128 Mbytes of memory and is an x86 based system. The prog_prof profile is used to install the Solaris software on systems that match the rule.

any

The 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 the rule. If any is used, it should always be the last rule in the rules file.

Creating a Profile

A profile is a text file that defines how to install the Solaris software on a system. A profile defines elements of the installation, for example, the software group to install. Every rule specifies a profile that defines how a system is to be installed. You can create different profiles for every rule or 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 JumpStart program is to install the Solaris software on a system. For example, the following profile keyword and value specify that the JumpStart program install the system as a server:

system_type  server

Sample profiles are already located in the JumpStart directory if you created the JumpStart directory by using either of these procedures:

• Creating a Profile Server for Networked Systems

• Creating a Profile Diskette for Standalone Systems

Syntax of Profiles

A profile must contain the following:

• The install_type profile keyword as the first entry

• One keyword per line

• The root_device keyword if the systems that are being upgraded by the profile contain more than one root (/) file system that can be upgraded

A profile can contain the following:

• Commented text

  Any text that is included after the # symbol on a line is treated by the JumpStart program as commented text. If a line begins with the # symbol, the entire line is treated as a comment.

• One or more blank lines

To Create a Profile

1. Use a text editor to create a text file. Name the file descriptively. Or, open a sample profile in the JumpStart directory that you created.

   ---

   Note –

   Ensure that the name of the profile reflects how you intend to use the profile to install the Solaris software on a system. For example, you might name the profiles basic_install, eng_profile, or user_profile.

   ---

2. Add profile keywords and values to the profile.

   For a list of profile keywords and values, see Profile Keywords and Values.

   ---

   Note –

   Profile keywords and their values are case sensitive.

   ---

3. Save the profile in the JumpStart directory.

4. Ensure that root owns the profile and that the permissions are set to 644.

5. Test the profile (optional).

   Testing a Profile contains information about testing profiles.

Profile Examples

The following examples of profiles show how to use different profile keywords and profile values to control how the Solaris software is installed on a system. Profile Keywords and Values contains a description of profile keywords and values.

Example 3–2 Mounting Remote File Systems and Adding and Deleting Packages

 
# profile keywords        profile values
# -----------------       -----------------
  install_type            initial_install
  system_type             standalone
  partitioning            default
  filesys                 any 512 swap   # specify size of /swap
  cluster                 SUNWCprog
  package                 SUNWman delete
  cluster                 SUNWCacc

The following list describes some of the keywords and values from this example.

install_type

The install_type keyword is required in every profile.

system_type

The system_type keyword defines that the system is to be installed as a standalone system.

partitioning

The file system slices are determined by the software to be installed with the value default. The size of swap is set to 512 Mbytes and is installed on any disk, value any.

cluster

The Developer Solaris Software Group, SUNWCprog, is installed on the system.

package

If the standard man pages are mounted from the file server, s_ref, on the network, the man page packages are not to be installed on the system. The packages that contain the System Accounting utilities are selected to be installed on the system.

Example 3–3 Mounting Remote File Systems and Adding a Third-Party Package

 
# profile keywords        profile values
# -----------------       -----------------
  install_type            initial_install
  system_type             standalone
  partitioning            default
  filesys                 any 512 swap   # specify size of /swap
  cluster                 SUNWCprog
  cluster                 SUNWCacc
  package                 apache_server  \
                           http://package.central/packages/apache timeout 5

The following list describes some of the keywords and values from this example.

install_type

The install_type keyword is required in every profile.

system_type

The system_type keyword defines that the system is to be installed as a standalone system.

partitioning

The file system slices are determined by the software to be installed with the value default. The size of swap is set to 512 Mbytes and is installed on any disk, value any.

cluster

The Developer Solaris Software Group, SUNWCprog, is installed on the system.

package

A third-party package is installed on the system located on an HTTP server.

Example 3–4 Specifying Where to Install File Systems

# profile keywords        profile values
# ----------------        -------------------
  install_type            initial_install
  system_type             standalone 
  partitioning            explicit
  filesys                 c0t0d0s0 auto /
  filesys                 c0t3d0s1 auto swap
  filesys                 any auto usr
  cluster                 SUNWCall

The following list describes some of the keywords and values from this example.

partitioning

The file system slices are determined by the filesys keywords, value explicit. The size of root (/) is based on the selected software, value auto, and is installed on c0t0d0s0. The size of swap is set to the necessary size and is installed on c0t3d0s1. usr is based on the selected software and the installation program determines where usr is installed, based on the value any.

cluster

The Entire Solaris Software Group, SUNWCall, is installed on the system.

Example 3–5 Upgrading and Installing Patches

# profile keywords         profile values
# ----------------         -------------------
  install_type             upgrade 
  root_device              c0t3d0s2 
  backup_media             remote_filesystem timber:/export/scratch
  package                  SUNWbcp delete
  package                  SUNWxwman add
  cluster                  SUNWCacc add   
  patch                    patch_list nfs://patch_master/Solaris_10/patches \
                           retry 5
  locale                   de

The following list describes some of the keywords and values from this example.

install_type

The 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 space for the upgrade.

root_device

The root file system on c0t3d0s2 is upgraded.

backup_media

A remote system that is named timber is to be used to back up data during the disk space reallocation. For more backup-media keyword values, see backup_media Profile Keyword.

package

The binary compatibility package, SUNWbcp, is not installed on the system after the upgrade.

package

The code ensures that the X Window System man pages and the System Accounting Utilities are to be installed if they are not already installed on the system. All packages already on the system are automatically upgraded.

patch

A list of patches that are installed with the upgrade. The patch list is located on an NFS server named patch_master under the directories Solaris_10/patches. In case of a mount failure, the NFS mount is tried five times.

locale

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

Example 3–6 Reallocating Disk Space for an Upgrade

# profile keywords         profile values
# ----------------         -------------------
  install_type             upgrade 
  root_device              c0t3d0s2 
  backup_media             remote_filesystem timber:/export/scratch
  layout_constraint        c0t3d0s2 changeable 100
  layout_constraint        c0t3d0s4 changeable
  layout_constraint        c0t3d0s5 movable 
  package                  SUNWbcp delete
  package                  SUNWxwman add
  cluster                  SUNWCacc add   
  locale                   de

The following list describes some of the keywords and values from this example.

install_type

The 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 space for the upgrade.

root_device

The root file system on c0t3d0s2 is upgraded.

backup_media

A remote system that is named timber is to be used to back up data during the disk space reallocation. For more backup-media keyword values, see backup_media Profile Keyword.

layout_constraint

The layout_constraint keywords designate that auto-layout can perform the following when auto-layout attempts to reallocate disk space for the upgrade.

• Change slices 2 and 4. The slices can be moved to another location and the size can be changed.

• Move slice 5. The slice can be moved to another location but its size cannot change.

package

The binary compatibility package, SUNWbcp, is not installed on the system after the upgrade.

package

The code ensures that the X Window System man pages and the System Accounting Utilities are to be installed if they are not already installed on the system. All packages already on the system are automatically upgraded.

locale

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

Example 3–7 Retrieving a Solaris Flash Archive From an HTTP Server

In the following example, the profile indicates that the custom JumpStart program retrieves the Solaris Flash archive from an HTTP server.

# profile keywords         profile values
# ----------------         -------------------
install_type               flash_install
archive_location           http://192.168.255.255/flasharchive/solarisarchive
partitioning               explicit
filesys                    c0t1d0s0 4000 /
filesys                    c0t1d0s1 512 swap
filesys                    c0t1d0s7 free /export/home

The following list describes some of the keywords and values from this example.

install_type

The profile installs a Solaris Flash archive on the clone system. All files are overwritten as in an initial installation.

archive_location

The Solaris Flash archive is retrieved from an HTTP server.

partitioning

The file system slices are determined by the filesys keywords, value explicit. The size of root (/) is based on the size of the Solaris Flash archive. The root file system is installed on c0t1d0s0. The size of swap is set to the necessary size and is installed on c0t1d0s1. /export/home is based on the remaining disk space. /export/home is installed on c0t1d0s7.

Example 3–8 Retrieving a Solaris Flash Archive From a Secure HTTP Server

In the following example, the profile indicates that the custom JumpStart program retrieves the Solaris Flash archive from a secure HTTP server.

# profile keywords         profile values
# ----------------         -------------------
install_type               flash_install
archive_location           https://192.168.255.255/solarisupdate.flar
partitioning               explicit
filesys                    c0t1d0s0 4000 /
filesys                    c0t1d0s1 512 swap
filesys                    c0t1d0s7 free /export/home

The following list describes some of the keywords and values from this example.

install_type

The profile installs a Solaris Flash archive on the clone system. All files are overwritten as in an initial installation.

archive_location

The compressed Solaris Flash archive is retrieved from a secure HTTP server.

partitioning

The file system slices are determined by the filesys keywords, value explicit. The size of root (/) is based on the size of the Solaris Flash archive. The size of swap is set to the necessary size and is installed on c0t1d0s1. /export/home is based on the remaining disk space. /export/home is installed on c0t1d0s7.

Example 3–9 Retrieving a Solaris Flash Archive and Installing a Third-Party Package

In the following example, the profile indicates that the custom JumpStart program retrieves the Solaris Flash archive from an HTTP server.

# profile keywords         profile values
# ----------------         -------------------
install_type               flash_install
archive_location           http://192.168.255.255/flasharchive/solarisarchive
partitioning               explicit
filesys                    c0t1d0s0 4000 /
filesys                    c0t1d0s1 512 swap
filesys                    c0t1d0s7 free /export/home
package                    SUNWnew http://192.168.254.255/Solaris_10 timeout 5

The following list describes some of the keywords and values from this example.

install_type

The profile installs a Solaris Flash archive on the clone system. All files are overwritten as in an initial installation.

archive_location

The Solaris Flash archive is retrieved from an HTTP server.

partitioning

The file system slices are determined by the filesys keywords, value explicit. The size of root (/) is based on the size of the Solaris Flash archive. The root file system is installed on c0t1d0s0. The size of swap is set to the necessary size and is installed on c0t1d0s1. /export/home is based on the remaining disk space. /export/home is installed on c0t1d0s7.

package

The SUNWnew package is added from the Solaris_10 directory from the HTTP server 192.168.254.255.

Example 3–10 Retrieving a Solaris Flash Differential Archive From an NFS Server

In the following example, the profile indicates that the custom JumpStart program retrieves the Solaris Flash archive from an NFS server. The flash_update keyword indicates that this is a differential archive. A differential archive installs only the differences between two system images.

# profile keywords         profile values
# ----------------         -------------------
install_type               flash_update
archive_location           nfs installserver:/export/solaris/flasharchive \
                           /solarisdiffarchive
no_master_check

The following list describes some of the keywords and values from this example.

install_type

The profile installs a Solaris Flash differential archive on the clone system. Only files that are specified by the archive are installed.

archive_location

The Solaris Flash archive is retrieved from an NFS server.

no_master_check

The clone system is not checked for a valid system image. A valid system image would have been built from the original master system.

Example 3–11 Creating an Empty Boot Environment

In the following example, the profile indicates that the custom JumpStart program creates an empty boot environment. An empty boot environment contains no file systems and no copy from the current boot environment occurs. The boot environment can be populated later with a Solaris Flash archive and then activated.

# profile keywords        profile values
# ----------------        -------------------
  install_type            initial_install
  system_type             standalone 
  partitioning            explicit
  filesys                 c0t0d0s0 auto /
  filesys                 c0t3d0s1 auto swap
  filesys                 any auto usr
  cluster                 SUNWCall
  bootenv createbe bename second_BE \
  filesystem /:/dev/dsk/c0t1d0s0:ufs \
  filesystem -:/dev/dsk/c0t1d0s0:swap \
  filesystem /export:shared:ufs

The following list describes some of the keywords and values from this example.

partitioning

The file system slices are determined by the filesys keywords, value explicit. The size of root (/) is based on the selected software, value auto, and is installed on c0t0d0s0. The size of swap is set to the necessary size and is installed on c0t3d0s1. usr is based on the selected software and the installation program determines where usr is installed, based on the value any.

cluster

The Entire Solaris Software Group, SUNWCall, is installed on the system.

bootenv createbe

An empty, inactive boot environment is set up on disk c0t1d0. File systems for root (/), swap, and /export are created, but left empty. This second boot environment can be installed with a Solaris Flash archive at a later time. The new boot environment can then be activated to become the current boot environment.

For keyword values and background about using this keyword, see the following references:

• For descriptions of keyword values, see Profile Keywords and Values.

• For background about using Solaris Live Upgrade that creates, upgrades, and activates inactive boot environments, see Chapter 2, Solaris Live Upgrade (Overview), in Solaris 10 8/07 Installation Guide: Solaris Live Upgrade and Upgrade Planning.

• For background about using a Solaris Flash archive, see Chapter 1, Solaris Flash (Overview), in Solaris 10 8/07 Installation Guide: Solaris Flash Archives (Creation and Installation).

Example 3–12 Creating RAID-1 Volumes When Installing a Solaris Flash Archive

In the following example, the profile indicates that the custom JumpStart program uses Solaris Volume Manager technology to create RAID-1 volumes (mirrors) for the root (/), swap, /usr and /export/home file systems. A Solaris Flash archive is installed on the boot environment.

# profile keywords        profile values
# ----------------        -------------------
  install_type            flash_install
  arhcive_location        nfs server:/export/home/export/flash.s10.SUNWCall
  partitioning            explicit
  filesys                 mirror:d10 c0t0d0s0 c0t1d0s0 4096 /
  filesys                 mirror c0t0d0s1 2048 swap
  filesys                 mirror:d30 c0t0d0s3 c0t1d0s3 4096 /usr
  filesys                 mirror:d40 c0t0d0s4 c0t1d0s4 4096 /usr
  filesys                 mirror:d50 c0t0d0s5 c0t1d0s5 free /export/home
  metadb                  c0t1d0s7 size 8192 count 3

The following list describes some of the keywords and values from this example.

install_type

The profile installs a Solaris Flash archive on the clone system. All files are overwritten as in an initial installation.

archive_location

The Solaris Flash archive is retrieved from an NFS server.

partitioning

The file system slices are determined by the filesys keywords, value explicit.

filesys

The root (/) file system is created and mirrored on the slices c0t0d0s0 and c0t1d0s0. The size of the root (/) file system is set to 4096 Mbytes. The RAID-1 volume that mirrors c0t0d0s0 and c0t1d0s0 is named d10.

filesys

The swap file system is created and mirrored on the slice c0t0d0s1, and is sized at 2048 Mbytes. The custom JumpStart program assigns a name to the mirror.

filesys

The /usr file system is created and mirrored on the slices c0t1d0s3 and c0t0d0s3. The size of the /usr file system is set to 4096 Mbytes. The RAID-1 volume is named d30.

filesys

The /usr file system is created and mirrored on the slices c0t1d0s4 and c0t0d0s4. The size of the /usr file system is set to 4096 Mbytes. The RAID-1 volume is named d40.

metadb

Three state database replicas (metadbs) are installed on slice c0t1d0s7, and are sized at 8192 blocks (4 Mbytes).

• For overview information about how to create mirrored file systems during your installation, see Chapter 8, Creating RAID-1 Volumes (Mirrors) During Installation (Overview), in Solaris 10 8/07 Installation Guide: Planning for Installation and Upgrade.

• For guidelines and requirements of creating mirrored file systems, see Chapter 9, Creating RAID-1 Volumes (Mirrors) During Installation (Planning), in Solaris 10 8/07 Installation Guide: Planning for Installation and Upgrade.

• For descriptions of keyword values, see filesys Profile Keyword (Creating RAID-1 Volumes) and metadb Profile Keyword (Creating State Database Replicas).

Example 3–13 Creating a RAID-1 Volume to Mirror the Root File System

In the following example, the profile indicates that the custom JumpStart program uses Solaris Volume Manager technology to create a RAID-1 volume (mirror) for the root (/) file system.

# profile keywords        profile values
# ----------------        -------------------
  install_type            initial_install
  cluster                 SUNWCXall
  filesys                 mirror:d30 c0t1d0s0 c0t0d0s0  /
  filesys                 c0t0d0s3 512 swap
  metadb                  c0t0d0s4 size 8192 count 4
  metadb                  c0t1d0s4 size 8192 count 4
  

The following list describes some of the keywords and values from this example.

cluster

The Entire Solaris Software Plus OEM Support software group, SUNWCXall, is installed on the system.

filesys

The root (/) file system is created and mirrored on the slices c0t1d0s0 and c0t0d0s0. The RAID-1 volume that mirrors c0t1d0s0 and c0t0d0s0 is named d30. The custom JumpStart program assigns names to the two submirrors.

filesys

The swap file system is created and mirrored on the slice c0t0d0s3, and is sized at 512 Mbytes.

metadb

Four state database replicas (metadbs) are installed on slice c0t0d0s4, and are sized at 8192 blocks (4 Mbytes).

metadb

Four state database replicas (metadbs) are installed on slice c0t1d0s4, and are sized at 8192 blocks (4 Mbytes).

• For overview information about how to create RAID-1 volumes during your installation, see Chapter 8, Creating RAID-1 Volumes (Mirrors) During Installation (Overview), in Solaris 10 8/07 Installation Guide: Planning for Installation and Upgrade.

• For guidelines and requirements about creating RAID-1 volumes, see Chapter 9, Creating RAID-1 Volumes (Mirrors) During Installation (Planning), in Solaris 10 8/07 Installation Guide: Planning for Installation and Upgrade.

• For descriptions of keyword values, see filesys Profile Keyword (Creating RAID-1 Volumes) and metadb Profile Keyword (Creating State Database Replicas).

Example 3–14 Creating RAID-1 Volumes to Mirror Multiple File Systems

In the following example, the profile indicates that the custom JumpStart program uses Solaris Volume Manager technology to create RAID-1 volumes (mirrors) for the root (/), swap, and /usr file systems.

# profile keywords        profile values
# ----------------        -------------------
  install_type            initial_install
  cluster                 SUNWCXall
  filesys                 mirror:d100 c0t1d0s0 c0t0d0s0 200 /
  filesys                 c0t1d0s5 500 /var
  filesys                 c0t0d0s5 500
  filesys                 mirror c0t0d0s1 512 swap
  metadb                  c0t0d0s3 size 8192 count 5
  filesys                 mirror c0t1d0s4 c0t0d0s4 2000 /usr
  filesys                 c0t1d0s7 free /export/home
  filesys                 c0t0d0s7 free

The following list describes some of the keywords and values from this example.

cluster

The Entire Solaris Software Plus OEM Support software group, SUNWCXall, is installed on the system.

filesys

The root (/) file system is created and mirrored on the slices c0t1d0s0 and c0t0d0s0. The size of the root (/) file system is set to 200 Mbytes. The RAID-1 volume that mirrors c0t1d0s0 and c0t0d0s0 is named d100.

filesys

The /var file system is installed on the slice c0t1d0s5 and is sized at 500 Mbytes. The root (/) file system is created and mirrored on the slices c0t1d0s0 and c0t0d0s0. The size of the root (/) file system is set to 200 Mbytes. The RAID-1 volume that mirrors c0t1d0s0 and c0t0d0s0 is named d100.

filesys

The swap file system is created and mirrored on the slice c0t0d0s1, and is sized at 512 Mbytes. The custom JumpStart program assigns a name to the mirror.

metadb

Five state database replicas (metadbs) are installed on slice c0t0d0s3, and are sized at 8192 blocks (4 Mbytes).

filesys

The /usr file system is created and mirrored on the slices c0t1d0s4 and c0t0d0s4. The size of the /usr file system is set to 2000 Mbytes. The custom JumpStart program assigns a name to the mirror.

• For overview information about how to create mirrored file systems during your installation, see Chapter 8, Creating RAID-1 Volumes (Mirrors) During Installation (Overview), in Solaris 10 8/07 Installation Guide: Planning for Installation and Upgrade.

• For guidelines and requirements of creating mirrored file systems, see Chapter 9, Creating RAID-1 Volumes (Mirrors) During Installation (Planning), in Solaris 10 8/07 Installation Guide: Planning for Installation and Upgrade.

• For descriptions of keyword values, see filesys Profile Keyword (Creating RAID-1 Volumes) and metadb Profile Keyword (Creating State Database Replicas).

Example 3–15 x86: Using the fdisk Keyword

# profile keywords      profile values
# ----------------      -------------------
  install_type          initial_install
  system_type           standalone

  fdisk                 c0t0d0 0x04 delete
  fdisk                 c0t0d0 solaris maxfree
  cluster               SUNWCall
  cluster               SUNWCacc delete

The following list describes some of the keywords and values from this example.

fdisk

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

fdisk

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

cluster

The Entire Distribution software group, SUNWCall, is installed on the system.

cluster

The system accounting utilities, SUNWCacc, are not to be installed on the system.

Testing a Profile

After you create a profile, use the pfinstall(1M) command to test the profile. Test the profile before you use the profile to install or upgrade a system. Testing a profile is especially useful when you are creating upgrade profiles that reallocate disk space.

By looking at the installation output that is generated by pfinstall, you can quickly determine if a profile works as you intended. For example, use the profile to determine if a system has enough disk space to upgrade to a new release of the Solaris software before you perform the upgrade on that system.

pfinstall enables you to test a profile against the following:

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

• Other disk configurations. You use a disk configuration file that represents a structure of a disk, for example, a disk's bytes/sector, flags, and slices. Creating disk configuration files is described in Creating Disk Configuration Files and x86: To Create a Disk Configuration File.

  ---

  Note –

  You cannot use a disk configuration file to test a profile you intend to use to upgrade a system. Instead, you must test the profile against the system's actual disk configuration and the software that is currently installed on that system.

  ---

To Create a Temporary Solaris Environment to Test a Profile

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

You need to create a temporary installation environment if you are testing a profile under one of the following conditions:

• You want to test a Solaris 10 8/07 upgrade profile on a system that is running a previous version of the Solaris software.

• You do not have a Solaris 10 8/07 system installed yet to test Solaris 10 8/07 initial installation profiles.

1. Boot a system from an image of one of the following:

   For SPARC based systems:

   • Solaris Operating System for SPARC Platforms DVD

   • Solaris Software for SPARC Platforms - 1 CD

   For x86 based systems:

   • Solaris Operating System for x86 Platforms DVD

   • Solaris Software for x86 Platforms - 1 CD

   ---

   Note –

   If you want to test an upgrade profile, boot the system that you are upgrading.

   ---

2. Respond to the system identification questions.

3. To exit from the installation program, type ! at the following prompt.

   The Solaris installation program will assist you in installing software for Solaris. <Press ENTER to continue> {"!" exits}

4. Execute the pfinstall command from the shell. For details about using the pfinstall command, see Step 7 in To Test a Profile.

To Test a Profile

If you are using the locale keyword, the pfinstall -D command fails to test the profile. For a workaround, see the error message “could not select locale,” in the section, Upgrading the Solaris OS.

1. Locate a system on which to test the profile that is the same type of platform, SPARC or x86, for which the profile was created.

   If you are testing an upgrade profile, you must test the profile on the actual system that you intend to upgrade.

2. Use the following decision table to determine what to do next.

   Test Scenario	Instructions
   Test an initial installation profile and have a system that is running the Solaris 10 8/07 software.	Become superuser on the system and go to Step 5.
   Test an upgrade profile, or you do not have a system that is running Solaris 10 8/07 to test an initial installation profile.	Create a temporary Solaris 10 8/07 environment to test the profile. For details, see To Create a Temporary Solaris Environment to Test a Profile. Then, go to Step 3.

3. Create a temporary mount point.

   # mkdir /tmp/mnt

4. Mount the directory that contains the profile or profiles that you want to test.

   Mount Scenario	Typing Instructions
   Mount a remote NFS file system for systems on the network.	mount -F nfs server_name:path /tmp/mnt
   SPARC: Mount a UFS-formatted diskette.	mount -F ufs /dev/diskette /tmp/mnt
   Mount a PCFS-formatted diskette.	mount -F pcfs /dev/diskette /tmp/mnt

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

6. Did you mount a directory in Step 4?

   • If yes, change the directory to /tmp/mnt.

     # cd /tmp/mnt

   • If no, change the directory to where the profile is located, which is usually the JumpStart directory.

     # cd jumpstart_dir_path

7. Test the profile with the pfinstall(1M) command.

   # /usr/sbin/install.d/pfinstall -D:-d disk_config_file -c path profile

   ---

   Caution –

   You must include the -d or -D option. If you do not include one of these options, pfinstall uses the profile you specify to install the Solaris software. All of the data on the system is overwritten.

   ---

   -D

   pfinstall uses the current system's disk configuration to test the profile. You must use the -D option to test an upgrade profile.

   -d disk_config_file

   pfinstall uses the disk configuration file, disk_config_file, to test the profile. If disk_config_file is not located in the directory where pfinstall is run, you must specify the path.

   For instructions about how to create a disk configuration file, see Creating Disk Configuration Files.

   ---

   Note –

   You cannot use the -d disk_config_file option with an upgrade profile, install_type upgrade. You must always test an upgrade profile against a system's disk configuration, that is, you must use the -D option.

   ---

   -c path

   The path to the Solaris software image. You use this option, for example, if the system is using Volume Manager to mount the Solaris Software - 1 CD for your platform.

   ---

   Note –

   The -c option is not required if you booted from a Solaris Operating System DVD or a Solaris Software - 1 CD image for your platform. The DVD or CD image is mounted on /cdrom as part of the booting process.

   ---

   profile

   The name of the profile to test. If profile is not in the directory where pfinstall is being run, you must specify the path.

Profile Test Examples

The following example shows how to use pfinstall to test a profile that is named basic_prof. The profile is tested against the disk configuration on a system on which the Solaris 10 8/07 software is installed. The basic_prof profile is located in the /jumpstart directory, and the path to the Solaris Operating System DVD image is specified because Volume Manager is being used.

Example 3–16 Profile Test Using a Solaris 10 8/07 System

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

The following example shows how to use pfinstall to test the profile that is named basic_prof on a Solaris 10 8/07 system. The test is performed against the 535_test disk configuration file. The test checks for 64 Mbytes of system memory. This example uses a Solaris Software for SPARC Platforms - 1 CD or Solaris Software for x86 Platforms - 1 CD image that is located in the /export/install directory.

Example 3–17 Profile Test Using a Disk Configuration File

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

Validating the rules File

Before you can use a profile and rules file, you must run the check script to validate that the files are set up correctly. If all rules and profiles are correctly set up, the rules.ok file is created, which is required by the custom JumpStart installation software to match a system to a profile.

Table 3–2 describes what the check script does.

To Validate the rules File

1. Ensure that the check script is located in the JumpStart directory.

   ---

   Note –

   The check script is in the Solaris_10/Misc/jumpstart_sample directory on the Solaris Operating System DVD or on the Solaris Software - 1 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 by using the check script from the Solaris software image instead of the check script from the system you are using. path is the image on a local disk or a mounted Solaris Operating System DVD or a Solaris Software - 1 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 that is named rules. Using this option, you can test the validity of a rule before you integrate the rule into the rules file.

   As the check script runs, the script reports the checking of the validity of the rules file and each profile. If no errors are encountered, the script reports the following information.

   The custom JumpStart configuration is ok

4. Ensure that root owns the rules.ok file and that the permissions are set to 644.

See Also

After you validate the rules file, you can learn more about optional custom JumpStart features in Chapter 4, Using Optional Custom JumpStart Features (Tasks). You can learn about performing custom JumpStart installations in Chapter 6, Performing a Custom JumpStart Installation (Tasks).

Chapter 4 Using Optional Custom JumpStart Features (Tasks)

This chapter describes the optional features that are available to create additional custom JumpStart installation tools.

• Creating Begin Scripts

• Creating Finish Scripts

• Creating a Compressed Configuration File

• Creating Disk Configuration Files

• Using a Site-Specific Installation Program

Instructions in this chapter are valid for either a SPARC server or an x86 server that is being used to provide custom JumpStart files, called a profile server. A profile server can provide custom JumpStart files for different platform types. For example, a SPARC server can provide custom JumpStart files for both SPARC based systems and x86 based systems.

Creating Begin Scripts

A begin script is a user-defined Bourne shell script that you specify in the rules file. A begin script performs tasks before the Solaris software is installed on a system. You can use begin scripts only when using custom JumpStart to install the Solaris software.

Use a begin script to perform one of the following tasks:

• Creating derived profiles

• Backing up files before upgrading

Important Information About Begin Scripts

• Do not specify something in the script that would prevent the mounting of file systems onto /a during an initial or upgrade installation. If the JumpStart program cannot mount the file systems onto /a, an error occurs and installation fails.

• During the installation, output from the begin script is deposited in /tmp/begin.log. After the installation is completed, the log file is redirected to /var/sadm/system/logs/begin.log.

• Ensure that root owns the begin script and that the permissions are set to 644.

• You can use custom JumpStart environment variables in your begin scripts. For a list of environment variables, see Custom JumpStart Environment Variables.

• Save begin scripts in the JumpStart directory.

For the Solaris 10 release, a sample JumpStart script, set_nfs4_domain, was provided on media to prevent being prompted during a JumpStart installation. This script suppressed the NFSv4 prompt during installation. This script is no longer required. Starting with the Solaris 10 8/07release, use the sysidcfg keyword, nfs4_domain that suppresses being prompted. The set_nfs4_domain script no longer works to suppress a prompt.

If you have non-global zones installed and the new nfs4_domain keyword exists in the sysidcfg file, the first boot of a non-global zone sets the domain. Otherwise, the Solaris interactive installation program comes up and you are prompted to provide a domain name before the boot process completes.

See nfs4_domain Keyword in Solaris 10 8/07 Installation Guide: Network-Based Installations

Creating Derived Profiles With a Begin Script

A derived profile is a profile that is dynamically created by a begin script during a custom JumpStart installation. Derived profiles are needed when you cannot set up the rules file to match specific systems to a profile. For example, you might need to use derived profiles for identical system models that have different hardware components, such as systems that contain different frame buffers.

To set up a rule to use a derived profile, you must perform the following tasks:

• Set the profile field to an equal sign (=) instead of a profile.

• Set the begin field to a begin script that creates a derived profile that depends on the system on which you intend to install Solaris.

When a system matches a rule with the profile field equal to an equal sign (=), the begin script creates the derived profile that is used to install the Solaris software on the system.

The following is an example of a begin script that creates the same derived profile every time. You can write a begin script to create different derived profiles that depend on the evaluation of rules.

Example 4–1 Begin Script That Creates a Derived Profile

#!/bin/sh
echo "install_type        initial_install"    > ${SI_PROFILE}
echo "system_type         standalone"        >> ${SI_PROFILE}
echo "partitioning        default"           >> ${SI_PROFILE}
echo "cluster             SUNWCprog"         >> ${SI_PROFILE}
echo "package       SUNWman     delete"      >> ${SI_PROFILE}
echo "package       SUNWolman   delete"      >> ${SI_PROFILE}
echo "package       SUNWxwman   delete"      >> ${SI_PROFILE}

In the example, the begin script must use the SI_PROFILE environment variable for the name of the derived profile, which is set to /tmp/install.input by default.

If a begin script is used to create a derived profile, ensure the script does not have any errors. A derived profile is not verified by the check script because derived profiles are not created until the execution of the begin script.

Creating Finish Scripts

A finish script is a user-defined Bourne shell script that you specify in the rules file. A finish script performs tasks after the Solaris software is installed on a system, but before the system reboots. You can use finish scripts only when using custom JumpStart to install Solaris.

Tasks that you can perform with a finish script include the following:

• Adding files

• Adding individual packages or patches in addition to the ones that are installed in a particular software group

• Customizing the root environment

• Setting the system's root password

• Installing additional software

Important Information About Finish Scripts

• The Solaris installation program mounts the system's file systems on /a. The file systems remain mounted on /a until the system reboots. You can use the finish script to add, change, or remove files from the newly installed file system hierarchy by modifying the file systems that are respective to /a.

• During the installation, output from the finish script is deposited in /tmp/finish.log. After the installation is completed, the log file is redirected to /var/sadm/system/logs/finish.log.

• Ensure that root owns the finish script and that the permissions are set to 644.

• You can use custom JumpStart environment variables in your finish scripts. For a list of environment variables, see Custom JumpStart Environment Variables.

• Save finish scripts in the JumpStart directory.

To Add Files With a Finish Script

Through a finish script, you can add files from the JumpStart directory to an already installed system. You can add the files because the JumpStart directory is mounted on the directory that is specified by the SI_CONFIG_DIR variable. The directory is set to /tmp/install_config by default.

You can also replace files by copying files from the JumpStart directory to already existing files on the installed system.

1. Copy all of the files that you are adding to the installed system to the JumpStart directory.

2. Insert the following line in the finish script for each file that you want to be copied to the newly installed file system hierarchy:

   cp ${SI_CONFIG_DIR}/file_name /a/path_name

Example 4–2 Adding a File With a Finish Script

For example, assume you have a special application, site_prog, developed for all users at your site. If you place a copy of site_prog into the JumpStart directory, the following line in a finish script copies site_prog from the JumpStart directory into a system's /usr/bin directory:

cp ${SI_CONFIG_DIR}/site_prog  /a/usr/bin

Adding Packages or Patches With a Finish Script

You can create a finish script to automatically add packages or patches after the Solaris software is installed on a system. By adding packages with a finish script, you reduce time and ensure consistency in which packages and patches are installed on different systems at your site.

When you use the pkgadd(1M) or patchadd(1M) commands in finish scripts, use the -R option to specify /a as the root path.

• Example 4–3 shows an example of a finish script that adds packages.

• Example 4–4 shows an example of a finish script that adds patches.

Example 4–3 Adding Packages With a Finish Script

  #!/bin/sh
 
  BASE=/a
  MNT=/a/mnt
  ADMIN_FILE=/a/tmp/admin
 
  mkdir ${MNT}
  mount -f nfs sherlock:/export/package ${MNT}
  cat >${ADMIN_FILE} <<DONT_ASK
  mail=root
  instance=overwrite
  partial=nocheck
  runlevel=nocheck
  idepend=nocheck
  rdepend=nocheck
  space=ask
  setuid=nocheck
  conflict=nocheck
  action=nocheck
  basedir=default
  DONT_ASK
 
  /usr/sbin/pkgadd -a ${ADMIN_FILE} -d ${MNT} -R ${BASE} SUNWxyz 
  umount ${MNT}
  rmdir ${MNT}

The following describes some commands for this example.

• The following command mounts a directory on a server that contains the package to install.

  mount -f nfs sherlock:/export/package ${MNT}

• The following command creates a temporary package administration file, admin, to force the pkgadd(1M) command not to perform checks or prompt for questions when installing a package. Use the temporary package administration file to maintain a hands-off installation when you are adding packages.

  cat >${ADMIN_FILE} <<DONT_ASK

• The following pkgadd command adds the package by using the -a option, specifying the package administration file, and the -R option, specifying the root path.

  /usr/sbin/pkgadd -a ${ADMIN_FILE} -d ${MNT} -R ${BASE} SUNWxyz

Example 4–4 Adding Patches With a Finish Script

 #!/bin/sh 

########
#
# USER-CONFIGURABLE OPTIONS
#
########

# The location of the patches to add to the system after it's installed.
# The OS rev (5.x) and the architecture (`mach`) will be added to the
# root.  For example, /foo on a 8 SPARC would turn into /foo/5.8/sparc
LUPATCHHOST=ins3525-svr
LUPATCHPATHROOT=/export/solaris/patchdb
#########
#
# NO USER-SERVICEABLE PARTS PAST THIS POINT
#
#########

BASEDIR=/a

# Figure out the source and target OS versions
echo Determining OS revisions...
SRCREV=`uname -r`
echo Source $SRCREV

LUPATCHPATH=$LUPATCHPATHROOT/$SRCREV/`mach`

#
# Add the patches needed
#
echo Adding OS patches
mount $LUPATCHHOST:$LUPATCHPATH /mnt >/dev/null 2>&1
if [ $? = 0 ] ; then
	for patch in `cat /mnt/*Recommended/patch_order` ; do
		(cd /mnt/*Recommended/$patch ; echo yes | patchadd -u -d -R $BASEDIR .)
	done
	cd /tmp
	umount /mnt
else
	echo "No patches found"
if

In the past, the chroot(1M) command was used with the pkgadd and patchadd commands in the finish script environment. In rare instances, some packages or patches do not work with the -R option. You must create a dummy /etc/mnttab file in the /a root path before issuing the chroot command.

To create a dummy /etc/mnttab file, add the following line to your finish script:

cp /etc/mnttab /a/etc/mnttab

Customizing the Root Environment With a Finish Script

You can also use finish scripts to customize files that are already installed on a system. For example, the finish script in Example 4–5 customizes the root environment by appending information to the .cshrc file in the root (/) directory.

Example 4–5 Customizing the Root Environment With a Finish Script

#!/bin/sh
#
# Customize root's environment
#
echo "***adding customizations in /.cshrc"
test -f a/.cshrc || {
cat >> a/.cshrc <<EOF
set history=100 savehist=200 filec ignoreeof prompt="\$user@`uname -n`> "
alias cp cp -i
alias mv mv -i
alias rm rm -i
alias ls ls -FC
alias h history
alias c clear
unset autologout
EOF
}

Setting a System's Root Password With a Finish Script

After the Solaris software is installed on a system, the system reboots. Before the boot process is completed, the system prompts for the root password. Until someone types a password, the system cannot finish booting.

A finish script that is named set_root_pw is saved in the auto_install_sample directory. The finish script shows how to set the root password automatically, without prompting. set_root_pw is shown in Example 4–6.

If you set the system's root password with a finish script, users might attempt to discover the root password from the encrypted password in your finish script. Ensure that you safeguard against users who might try to determine the root password.

Example 4–6 Setting the System's Root Password With a Finish Script

	 #!/bin/sh
	 #
	 #       @(#)set_root_pw 1.4 93/12/23 SMI
	 #
	 # This is an example Bourne shell script to be run after installation.
	 # It sets the system's root password to the entry defined in PASSWD.
	 # The encrypted password is obtained from an existing root password entry
	 # in /etc/shadow from an installed machine.
 
	 echo "setting password for root"
 
	 # set the root password
 PASSWD=dKO5IBkSF42lw
	 #create a temporary input file
 cp /a/etc/shadow /a/etc/shadow.orig
 
	 mv /a/etc/shadow /a/etc/shadow.orig
 	nawk -F: '{
         if ( $1 == "root" )
           printf"%s:%s:%s:%s:%s:%s:%s:%s:%s\n",$1,passwd,$3,$4,$5,$6,$7,$8,$9
      else
		        printf"%s:%s:%s:%s:%s:%s:%s:%s:%s\n",$1,$2,$3,$4,$5,$6,$7,$8,$9
      }' passwd="$PASSWD" /a/etc/shadow.orig > /a/etc/shadow
 #remove the temporary file
 rm -f /a/etc/shadow.orig
 # set the flag so sysidroot won't prompt for the root password
 sed -e 's/0 # root/1 # root/' ${SI_SYS_STATE} > /tmp/state.$$
  mv /tmp/state.$$ ${SI_SYS_STATE}

The following describes some of the commands in this example.

• The following command sets the variable PASSWD to an encrypted root password that is obtained from an existing entry in a system's /etc/shadow file.

  #create a temporary input file

• The following command creates a temporary input file of /a/etc/shadow.

  cp /a/etc/shadow /a/etc/shadow.orig

• The following command changes the root entry in the /etc/shadow file for the newly installed system by using $PASSWD as the password field.

  if ( $1 == "root" )

• The following command removes the temporary /a/etc/shadow file.

  rm -f /a/etc/shadow.orig

• The following command changes the entry from 0 to a 1 in the state file so that the user is not prompted for the root password. The state file is accessed by using the variable SI_SYS_STATE, which has a value currently of /a/etc/.sysIDtool.state. To avoid problems with your scripts if this value changes, always reference this file by using $SI_SYS_STATE. The sed command that is shown here contains a tab character after the 0 and after the 1.

  sed -e 's/0 # root/1 # root/' ${SI_SYS_STATE} > /tmp/state.$$

Non-Interactive Installations With Finish Scripts

You can use finish scripts to install additional software after the Solaris OS is installed. The Solaris installation program prompts you to enter information during the installation. To maintain a hands-off installation, you can run the Solaris installation program with the -nodisplay or -noconsole options.

For more information, see the man page installer(1M).

Creating a Compressed Configuration File

Instead of using the add_install_client command to specify the location of the custom JumpStart configuration files, you can specify the location of the files when you boot the system. However, you can only specify the name of one file. As a result, you must compress all of the custom JumpStart configuration files into one file.

• For SPARC based systems, you specify the location of the file in the boot command

• For x86 based systems, you specify the location of the files by editing the GRUB entry in the GRUB menu

The compressed configuration file can be one of the following types:

• tar

• Compressed tar

• zip

• bzip tar

To Create a Compressed Configuration File

1. Change the directory to the JumpStart directory on the profile server.

   # cd jumpstart_dir_path

2. Use a compression tool to compress the custom JumpStart configuration files into one file.

   ---

   Note –

   The compressed configuration file cannot contain relative paths. The custom JumpStart configuration files must be in the same directory as the compressed file.

   ---

   The compressed configuration file must contain the following files:

   • Profile

   • rules

   • rules.ok

   You can also include the sysidcfg file in the compressed configuration file.

3. Save the compressed configuration file on an NFS server, an HTTP server, or on a local hard disk.

Compressed Configuration File Example

The following example shows how to use the tar command to create a compressed configuration file that is named config.tar. The custom JumpStart configuration files are located in the /jumpstart directory.

Example 4–7 Creating a Compressed Configuration File

# cd /jumpstart
# tar -cvf config.tar *
a profile 1K
a rules 1K
a rules.ok 1K
a sysidcfg 1K

Creating Disk Configuration Files

This section describes how to create single-disk and multiple-disk configuration files. Disk configuration files enable you to use pfinstall(1M) from a single system to test profiles against different disk configurations.

SPARC: To Create a Disk Configuration File

1. Locate a SPARC based system with a disk you want to test.

2. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

3. Create a single–disk configuration file by redirecting the output of the prtvtoc(1M) command to a file.

   # prtvtoc /dev/rdsk/device_name >disk_config_file

   /dev/rdsk/device_name

   The device name of the system's disk. device_name must be in the form cwtxdys2 or cxdys2.

   disk_config_file

   The name of the disk configuration file.

4. Determine if you are testing the installation of Solaris software on multiple disks.

   • If no, stop. You are finished.

   • If yes, concatenate the single–disk configuration files and save the output in a new file.

     # cat disk_file1 disk_file2 >multi_disk_config

     The new file becomes the multiple-disk configuration file, as in the following example.

     # cat 104_disk2 104_disk3 104_disk5 >multi_disk_test

5. Determine if the target numbers in the disk device names are unique in the multiple-disk configuration file that you created in the previous step.

   • If yes, stop. You are finished.

   • If no, open the file with a text editor and make the target numbers unique in the disk device names.

     For example, assume that the file contains the same target number, t0, for different disk device names, as shown here.

     * /dev/rdsk/c0t0d0s2 partition map ... * /dev/rdsk/c0t0d0s2 partition map

     Change the second target number to t2, as shown here:

     * /dev/rdsk/c0t0d0s2 partition map ... * /dev/rdsk/c0t2d0s2 partition map

SPARC: Disk Configuration File Example

The following example shows how to create a single–disk configuration file, 104_test, on a SPARC based system with a 104-Mbyte disk.

Example 4–8 SPARC: Creating a Disk Configuration File

You redirect the output of the prtvtoc command to a single–disk configuration file that is named 104_test:

# prtvtoc /dev/rdsk/c0t3d0s2 >104_test

The contents of the 104_test file resemble the following:

* /dev/rdsk/c0t3d0s2 partition map
*
* Dimensions:
*     512 bytes/sector
*      72 sectors/track
*      14 tracks/cylinder
*    1008 sectors/cylinder
*    2038 cylinders*    2036 accessible cylinders
* Flags:
*   1: unmountable
*  10: read-only
*
*                          First     Sector    Last
* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
       1      2    00          0     164304   164303   /
       2      5    00          0    2052288  2052287  
       3      0    00     164304     823536   987839   /disk2/b298
       5      0    00     987840     614880  1602719   /install/298/sparc/work
       7      0    00    1602720     449568  2052287   /space

You have created disk configuration files for a SPARC based system. Testing a Profile contains information about using disk configuration files to test profiles.

x86: To Create a Disk Configuration File

1. Locate an x86 based system that contains a disk that you are testing.

2. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

3. Create part of the single-disk configuration file by saving the output of the fdisk(1M) command in a file.

   # fdisk -R -W disk_config_file -h /dev/rdsk/device_name

   disk_config_file

   The name of a disk configuration file.

   /dev/rdsk/device_name

   The device name of the fdisk layout of the entire disk. device_name must be in the form cwtxdys0 or cxdys0.

4. Append the output of the prtvtoc(1M) command to the disk configuration file:

   # prtvtoc /dev/rdsk/device_name >>disk_config

   /dev/rdsk/device_name

   The device name of the system's disk. device_name must be in the form cwtxdys2 or cxdys2.

   disk_config

   The name of the disk configuration file.

5. Determine if you are testing the installation of Solaris software on multiple disks.

   • If no, stop. You are finished.

   • If yes, concatenate the single-disk configuration files and save the output in a new file.

     # cat disk_file1 disk_file2 >multi_disk_config

     The new file becomes the multiple-disk configuration file, as in the following example.

     # cat 104_disk2 104_disk3 104_disk5 >multi_disk_test

6. Determine if the target numbers in the disk device names are unique in the multiple-disk configuration file that you created in the previous step.

   • If yes, stop. You are finished.

   • If no, open the file with a text editor and make the target numbers unique.

     For example, the file might contain the same target number, t0, for different disk device names as shown here:

     * /dev/rdsk/c0t0d0s2 partition map ... * /dev/rdsk/c0t0d0s2 partition map

     Change the second target number to t2, as shown here:

     * /dev/rdsk/c0t0d0s2 partition map ... * /dev/rdsk/c0t2d0s2 partition map

x86: Disk Configuration File Example

The following example shows how to create a single-disk configuration file, 500_test, on an x86 based system that contains a 500-Mbyte disk.

Example 4–9 x86: Creating a Disk Configuration File

First, you save the output of the fdisk command to a file that is named 500_test:

# fdisk -R -W 500_test -h /dev/rdsk/c0t0d0p0

The 500_test file looks like the following:

 * /dev/rdsk/c0t0d0p0 default fdisk table
* Dimensions:
*     512 bytes/sector
*      94 sectors/track
*      15 tracks/cylinder
*    1455 cylinders
*
*  HBA Dimensions:
*     512 bytes/sector
*      94 sectors/track
*      15 tracks/cylinder
*    1455 cylinders
*
* systid:
*  1:    DOSOS12
*  2:    PCIXOS
*  4:    DOSOS16
*  5:    EXTDOS
*  6:    DOSBIG
*  86:   DOSDATA
*  98:   OTHEROS
*  99:   UNIXOS
* 130:   SUNIXOS
*
* Id  Act Bhead Bsect   Bcyl  Ehead  Esect  Ecyl Rsect  Numsect
 130  128 44    3       0     46    30     1001 1410   2050140

Second, you append the output of the prtvtoc command to the 500_test file:

# prtvtoc /dev/rdsk/c0t0d0s2 >>500_test

The 500_test file is now a complete disk configuration file:

* /dev/rdsk/c0t0d0p0 default fdisk table	
* Dimensions:
*     512 bytes/sector
*      94 sectors/track
*      15 tracks/cylinder
*    1455 cylinders
*
*  HBA Dimensions:
*     512 bytes/sector
*      94 sectors/track
*      15 tracks/cylinder
*    1455 cylinders
*
* systid:
*  1:    DOSOS12
*  2:    PCIXOS
*  4:    DOSOS16
*  5:    EXTDOS
*  6:    DOSBIG
*  86:   DOSDATA
*  98:   OTHEROS
*  99:   UNIXOS
*  130:  SUNIXOS
*
* Id  Act Bhead Bsect Bcyl  Ehead  Esec  Ecyl Rsect  Numsect
 130  128 44    3     0     46    30    1001 1410   2050140
* /dev/rdsk/c0t0d0s2 partition map
*
* Dimensions:
*      512 bytes/sector
*       94 sectors/track
*       15 tracks/cylinder
*     1110 sectors/cylinder
*     1454 cylinders
*     1452 accessible cylinders
*
* Flags:
*   1: unmountable
*  10: read-only
*                          First    Sector    Last
* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
       2      5    01       1410   2045910   2047319
       7      6    00       4230   2043090   2047319  /space
       8      1    01          0      1410     1409
       9      9    01       1410      2820     422987

You have created disk configuration files for an x86 based system. Testing a Profile contains information about using disk configuration files to test profiles.

Using a Site-Specific Installation Program

You can also use begin and finish scripts to create your own installation program to install Solaris software.

When you specify a minus sign (-) in the profile field, begin and finish scripts control how Solaris software is installed on a system instead of the profile and the Solaris installation program.

For example, if the following rule matches a system, the x_install.beg begin script and the x_install.fin finish script install Solaris software on the system that is named clover:

hostname clover x_install.beg - x_install.fin

Chapter 5 Creating Custom Rule and Probe Keywords (Tasks)

This chapter provides information and procedures for creating your own custom rule and probe keywords.

• Probe Keywords

• Creating a custom_probes File

• Validating the custom_probes File

Probe Keywords

To understand what a probe keyword is, you first need to recall what a rule keyword is. A rule keyword is a predefined lexical unit or word that describes a general system attribute, such as host name, hostname, or memory size, memsize. Rule keywords and the values that are associated with them enable you to match a system that has the same attribute to a profile. This match of a system's attributes defines how the Solaris software is to be installed on each system in the group.

Custom JumpStart environment variables, which you use in begin and finish scripts, are set on demand. For example, information about which operating system is already installed on a system is only available in SI_INSTALLED after the installed rule keyword is used.

In some situations, you might need to extract the same information in a begin or finish script for a purpose other than to match a system and run a profile. Probe keywords provide the solution. Probe keywords extract attribute information and remove the need for you to set up a matching condition and run a profile.

For a list of probe keywords and values, see Probe Keywords and Values.

Creating a custom_probes File

The rule and probe keywords that are described in Rule Keywords and Values and Probe Keywords and Values might not be precise enough for your needs. You can define your own custom rule or probe keywords by creating a custom_probes file.

The custom_probes file is a Bourne shell script that contains two types of functions. You must save the custom_probes file in the same JumpStart directory where you saved the rules file. The two types of functions that you can define in a custom_probes file are as follows:

• Probe – Gathers the information you want or does the actual work and sets a corresponding SI_ environment variable that you define. Probe functions become probe keywords.

• Comparison – Calls a corresponding probe function, compares the output of the probe function, and returns 0 if the keyword matches or 1 if the keyword does not match. Comparison functions become rule keywords.

Syntax of the custom_probes File

The custom_probes file can contain any valid Bourne shell command, variable, or algorithm.

You can define probe and comparison functions that require a single argument in the custom_probes file. When you use the corresponding custom probe keyword in the rules file, the argument after the keyword is interpreted (as $1).

When you use the corresponding custom rule keyword in the rules file, the arguments are interpreted in sequence. The sequence starts after the keyword and ends before the next && or begin script, whichever comes first.

The custom_probes file must meet the following requirements:

• Have the name custom_probes

• Have root as its owner

• Be executable and have permissions set to 755

• Contain at least one probe function and one corresponding comparison function

To improve clarity and organization, define all probe functions first, at the top of the file, followed by all comparison functions.

Syntax of Function Names in custom_probes

The name of a probe function must begin with probe_. The name of a comparison function must begin with cmp_.

Functions that begin with probe_ define new probe keywords. For example, the function probe_tcx defines the new probe keyword tcx. Functions that begin with cmp_ define new rule keywords. For example, cmp_tcx defines the new rule keyword tcx.

To Create a custom_probes File

1. Use a text editor to create a Bourne shell script text file. Name the file custom_probes.

2. In the custom_probes text file, define your probe and comparison functions.

   ---

   Note –

   You can define probe and comparison functions that require arguments in the custom_probes file. When you use the corresponding custom probe keyword in the rules file, the arguments after the keyword are interpreted in sequence (as $1, $2, and so on).

   When you use the corresponding custom rule keyword in the rules file, the arguments are interpreted in sequence. The sequence starts after the keyword and ends before the next && or begin script, whichever comes first.

   ---

3. Save the custom_probes file in the JumpStart directory next to the rules file.

4. Ensure that root owns the rules file and that the permissions are set to 644.

Examples of a custom_probes File and Keyword

You can find additional examples of probe and comparison functions in the following directories:

• /usr/sbin/install.d/chkprobe on a system that has the Solaris software installed

• /Solaris_10/Tools/Boot/usr/sbin/install.d/chkprobe on the Solaris Operating System DVD or on the Solaris Software - 1 CD

The following custom_probes file contains a probe and comparison function that tests for the presence of a TCX graphics card.

Example 5–1 custom_probes File

#!/bin/sh
# 
# custom_probe script to test for the presence of a TCX graphics card.
# 

# 
# PROBE FUNCTIONS
# 
probe_tcx() {
  SI_TCX=`modinfo | grep tcx | nawk '{print $6}'`
  export SI_TCX
}

# 
# COMPARISON FUNCTIONS
# 
cmp_tcx() {
  probe_tcx

  if [ "X${SI_TCX}" = "X${1}" ]; then
     return 0
  else
     return 1
  if
}

The following example rules file shows the use of the probe keyword that is defined in the preceding example, tcx. If a TCX graphics card is installed and found in a system, profile_tcx is run. Otherwise, profile is run.

Always place probe keywords at or near the beginning of the rules file. This placement ensures that the keywords are read and run before other rule keywords that might rely on the probe keywords.

Example 5–2 Custom Probe Keyword Used in a rules File

probe tcx
tcx     tcx     -     profile_tcx     -
any     any     -     profile         -

Validating the custom_probes File

Before you can use a profile, rules, and custom_probes file, you must run the check script to validate that the files are set up correctly. If all profiles, rules, and probe and comparison functions are correctly set up, the rules.ok and custom_probes.ok files are created. Table 5–1 describes what the check script does.

To Validate the custom_probes File

1. Verify that the check script is located in the JumpStart directory.

   ---

   Note –

   The check script is in the Solaris_10/Misc/jumpstart_sample directory on the Solaris Operating System DVD or on the Solaris Software - 1 CD.

   ---

2. Change to the JumpStart directory.

3. Run the check script to validate the rules and custom_probes files.

   $ ./check -p path -r file_name

   -p path

   Validates the custom_probes file by using the check script from the Solaris software image for your platform instead of the check script from the system you are using. path is the image on a local disk or a mounted Solaris Operating System DVD or Solaris Software - 1 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 file name other than the one that is named custom_probes. By using the -r option, you can test the validity of a set of functions before integrating the functions into the custom_probes file.

   As the check script runs, the script reports the validity of the rules and custom_probes files and each profile. If no errors are encountered, the script reports: “The custom JumpStart configuration is ok” and creates the rules.ok and custom_probes.ok files in the JumpStart directory.

4. Determine if the custom_probes.ok file is executable.

   • If yes, go to Step 5.

   • If no, type the following command.

     # chmod +x custom_probes

5. Ensure that root owns the custom_probes.ok file and that the permissions are set to 755.

Chapter 6 Performing a Custom JumpStart Installation (Tasks)

This chapter describes how to perform a custom JumpStart installation on a SPARC based or an x86 based system. You need to follow these procedures on the system on which you intend to install the Solaris software.

• SPARC: To Perform an Installation or Upgrade With the Custom JumpStart Program

• x86: To Perform an Installation or Upgrade With the Custom JumpStart Program and With GRUB

Limitations for a JumpStart Installation

A number of issues might cause problems during a JumpStart installation. Review the table below for specific information.

SPARC: Task Map: Setting Up a System for a Custom JumpStart Installation

SPARC: Performing a Custom JumpStart Installation

During a custom JumpStart installation, the JumpStart program attempts to match the system that is being installed to the rules in the rules.ok file. The JumpStart program reads the rules from the first rule through the last. A match occurs when the system that is being installed matches all the system attributes that are defined in the rule. When a system matches a rule, the JumpStart program stops reading the rules.ok file and begins to install the system, based on the matched rule's profile.

To Prepare to Install a Solaris Flash Archive With a Custom JumpStart Installation

You can install a full archive for an initial installation or if you have already installed an archive, a differential archive for an update. You can use the custom JumpStart installation method or use Solaris Live Upgrade to install an archive on an inactive boot environment. This procedure provides the instructions to install an archive with custom JumpStart.

• For an overview of a full or differential archive, see Chapter 1, Solaris Flash (Overview), in Solaris 10 8/07 Installation Guide: Solaris Flash Archives (Creation and Installation).

• For procedures about installing an archive on an inactive boot environment by using Solaris Live Upgrade, see To Install a Solaris Flash Archive With a Profile in Solaris 10 8/07 Installation Guide: Solaris Live Upgrade and Upgrade Planning.

1. Review the following limitations.

   Description	Example
   Caution: When using the archive_location keyword to install a Solaris Flash archive, the archive and the installation media must contain identical operating system versions.	For example, if the archive is a Solaris 10 8/07 operating system and you are using DVD media, then you must use Solaris 10 8/07 DVD media to install the archive. If the operating systems versions do not match, the installation on the clone system fails.
   Caution – A Solaris Flash archive cannot be properly created when a non-global zone is installed. The Solaris Flash feature is not compatible with the Solaris Zones partitioning technology. If you create a Solaris Flash archive, the resulting archive is not installed properly when the archive is deployed under these conditions: The archive is created in a non-global zone The archive is created in a global zone that has non-global zones installed

2. On the install server, create the custom JumpStart rules file.

   For detailed instructions about creating custom JumpStart files, refer to Chapter 3, Preparing Custom JumpStart Installations (Tasks).

3. On the install server, create the custom JumpStart profile file.

   For examples of Solaris Flash archive profiles, see Profile Examples.

   From the existing list of custom JumpStart keywords in Table 8–2, the only keywords valid when you install a Solaris Flash archive are the following:

   Keyword	Initial Installation	Differential Archive
   (required)archive_location	X	X
   fdisk (x86 only)	X	X
   filesys Note – You cannot set the filesys keyword to the value auto.	X
   forced_deployment		X
   (required) install_type	X	X
   local_customization	X	X
   no_content_check		X
   no_master_check		X
   package	X
   root_device	X	X

   1. Set the value of the keyword install_type to one of the following types.

      • For a full archive installation, set the value to flash_install.

      • For a differential archive installation, set the value to flash_update.

   2. Add the path to the Solaris Flash archive by using the archive_location keyword.

      For details about the archive_location keyword, refer to archive_location Keyword.

   3. Specify the file system configuration.

      The Solaris Flash archive extraction process does not support auto-layout of partitions.

   4. (Optional) If you want to install additional packages at the same time you install an archive, use the package keyword. For more information, see package Profile Keyword.

   5. (Optional) If you want to install an additional Solaris Flash archive on the clone system, add one archive_location line for each archive that you want to install.

4. On the install server, add the clients that you are installing with the Solaris Flash archive.

   For detailed instructions, refer to the following:

   • Adding Systems to Be Installed From the Network With a DVD Image in Solaris 10 8/07 Installation Guide: Network-Based Installations

   • Adding Systems to Be Installed From the Network With a CD Image in Solaris 10 8/07 Installation Guide: Network-Based Installations

5. Perform the custom JumpStart installation on the clone systems.

   For detailed instructions, refer to SPARC: To Perform an Installation or Upgrade With the Custom JumpStart Program.

SPARC: To Perform an Installation or Upgrade With the Custom JumpStart Program

1. If the system is part of a network, ensure that an Ethernet connector or similar network adapter is attached to your system.

2. If you are installing a system that is connected through a tip(1) line, ensure that your window display is at least 80 columns wide and 24 rows long.

   To determine the current dimensions of your tip window, use the stty(1) command.

3. If you are using the system's DVD-ROM or CD-ROM drive to install the Solaris software, insert the Solaris Operating System for SPARC Platforms DVD or the Solaris Software for SPARC Platforms - 1 CD in the drive.

4. If you are using a profile diskette, insert the profile diskette in the system's diskette drive.

5. Boot the system.

   • If the system is new, out–of–the–box, turn on the system.

   • If you want to install or upgrade an existing system, shut down the system. At the ok prompt, type the appropriate options for the boot command. The syntax of the boot command is the following.

     ok boot [cd–dvd|net] - install [url|ask] options

     For example, if you type the following command, the OS is installed over the network by using a JumpStart profile.

     ok boot net - install http://131.141.2.32/jumpstart/config.tar

     For a description of the boot command options, see the following table.

   ---

   SPARC only –

   The system checks hardware and system components and your SPARC based system boots. Booting lasts several minutes.

   ---

6. If you did not preconfigure system information in the sysidcfg file, when prompted, answer the questions about system configuration.

7. Follow the instructions on the screen to install the software.

   When the JumpStart program finishes installing the Solaris software, the system reboots automatically.

   After the installation is finished, installation logs are saved in a file. You can find the installation logs in the following directories:

   • /var/sadm/system/logs

   • /var/sadm/install/logs

SPARC: Command Reference for the boot Command

The syntax of the boot command is the following.

ok boot [cd–dvd|net] - install [url|ask] options

The following table describes the command-line options for the boot command that are appropriate for a JumpStart installation.

x86: Task Map: Setting Up a System for a Custom JumpStart Installation

x86: Performing a Custom JumpStart Installation

During a custom JumpStart installation, the JumpStart program attempts to match the system that is being installed to the rules in the rules.ok file. The JumpStart program reads the rules from the first rule through the last rule. A match occurs when the system that is being installed matches all of the system attributes that are defined in the rule. As soon as a system matches a rule, the JumpStart program stops reading the rules.ok file and begins to install the system, based on the matched rule's profile.

You can install a Solaris Flash archive with custom JumpStart. For instructions, see To Prepare to Install a Solaris Flash Archive With a Custom JumpStart Installation.

Choose one of the following procedures:

• For a standard custom JumpStart procedure, see x86: To Perform an Installation or Upgrade With the Custom JumpStart Program and With GRUB.

• To perform a custom JumpStart by editing the GRUB command, see x86: Performing a Custom JumpStart Installation by Editing the GRUB Boot Command.

x86: To Perform an Installation or Upgrade With the Custom JumpStart Program and With GRUB

Use this procedure to install the Solaris OS for an x86 based system with the GRUB menu.

1. If the system is part of a network, ensure that an Ethernet connector or similar network adapter is attached to your system.

2. If you want to install a system that is connected through a tip(1) line, ensure that your window display is at least 80 columns wide and 24 rows long.

   To determine the current dimensions of your tip window, use the stty(1) command.

3. Decide if you want to use a profile diskette.

   A profile diskette is no longer used to boot the system but, a diskette can be prepared that includes only the JumpStart directory. The diskette can then be used situations such as performing a JumpStart installation and booting off the CD-ROM.

   • If you are using a profile diskette, insert the profile diskette into the system's diskette drive.

   • If you are not using a profile diskette, continue with step Step 4.

4. Decide how to boot the system.

   • If you boot from the Solaris Operating System DVD or the Solaris Software - 1 CD, insert the disc. Your system's BIOS must support booting from a DVD or CD.

   • If you boot from the network, use Preboot Execution Environment (PXE) network boot. The system must support PXE. Enable the system to use PXE by using the system's BIOS setup tool or the network adapter's configuration setup tool.

5. (Optional) If you are booting from a DVD or CD, change the boot setting in your system's BIOS and set to boot from DVD or CD media. See your hardware documentation for instructions.

6. If the system is off, turn the system on. If the system is on, reboot the system.

   The GRUB menu is displayed. This menu provides a list of boot entries.

   GNU GRUB version 0.95 (631K lower / 2095488K upper memory) +-------------------------------------------------------------------+ |Solaris 10 8/07 image_directory | |Solaris Serial Console ttya | |Solaris Serial Console ttyb (for lx50, v60x and v65x | +-------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press enter to boot the selected OS, 'e' to edit the commands before booting, or 'c' for a command-line.

   The image_directory is the name of the directory where the installation image is located. The path to the JumpStart files was defined with the add_install_client command and the -c option.

   ---

   Note –

   Instead of booting from the GRUB entry now, you can edit the boot entry. After editing the GRUB entry, you then perform the JumpStart installation. For instructions about how to edit the GRUB entry and a list of installation options, see x86: Performing a Custom JumpStart Installation by Editing the GRUB Boot Command.

   ---

7. At the prompt, perform one of the following instructions:

   Select the type of installation you want to perform: 1 Solaris Interactive 2 Custom JumpStart 3 Solaris Interactive Text (Desktop session) 4 Solaris Interactive Text (Console session) 5. Apply driver updates 6. Single User Shell Enter the number of your choice. Please make a selection (1-6).

   To select the custom JumpStart method, type 2 and press Enter.

   The JumpStart installation begins.

   ---

   Note –

   • If you do not make a selection within 30 seconds, the Solaris interactive installation program begins. You can stop the timer by typing any key at the command line.

   • If you select items 1, 3, or 4, you install with an interactive installation. For information about interactive installations, see Solaris 10 8/07 Installation Guide: Basic Installations.

   • If you select item 5, you install driver updates.

   • If you select item 6, you can perform maintenance tasks.

   ---

8. If you did not preconfigure system information in the sysidcfg file, when prompted, answer the questions about system configuration.

9. Follow the instructions on the screen to install the software.

   When the JumpStart program finishes installing the Solaris software, the system reboots automatically. Also, the GRUB menu.lst file is automatically updated. Then the instance of Solaris that you have installed appears in the next use of the GRUB menu.

   After the installation is finished, installation logs are saved in a file. You can find the installation logs in the following directories:

   • /var/sadm/system/logs

   • /var/sadm/install/logs

x86: Performing a Custom JumpStart Installation by Editing the GRUB Boot Command

In some circumstances such as for debugging purposes, you might want to modify the GRUB boot command. The following procedure describes the steps to edit the GRUB boot command before performing the custom JumpStart installation.

x86: To Modify the GRUB Boot Command

1. To begin the installation, proceed with Step 1 through Step 5 in the preceding procedure, x86: To Perform an Installation or Upgrade With the Custom JumpStart Program and With GRUB.

2. If the system is off, turn the system on. If the system is on, reboot the system.

   The GRUB menu is displayed. This menu provides a list of boot entries. The entry that is provided is the Solaris instance to be installed.

   GNU GRUB version 0.95 (631K lower / 2095488K upper memory) +-------------------------------------------------------------------+ |Solaris 10 8/07 image_directory | |Solaris Serial Console ttya | |Solaris Serial Console ttyb (lx50, v60x and v68) | +-------------------------------------------------------------------+ Use the ^ and v keys to select which entry is highlighted. Press enter to boot the selected OS, 'e' to edit the commands before booting, or 'c' for a command-line.

   The image_directory is the name of the directory where the installation image is located.

   ---

   Note –

   • If you used the NFS to set the path to the JumpStart directory with the add_install_client command and the -c option, then you do not need to include the path in the boot entry.

   • If you are not using NFS, then you must note the path to the compressed configuration file that contains the JumpStart directory.

   ---

3. To stop the booting process and use the menu entry editor, type e.

   The GRUB edit menu is displayed.

   kernel /I86PC.Solaris_11-8/multiboot kernel/unix -B console=ttyb,\ install_media=131.141.2.32:/export/mary/v11 \ module /I86PC.Solaris_11-8/x86.new

4. Use the arrow keys to select the boot entry.

5. To edit the selected command, type e.

   A command that is similar to the following example displays.

   grub edit>kernel /I86PC.Solaris_11-8/multiboot kernel/unix -B \ console=ttyb,install_media=131.141.2.32:/export/mary/_\ module /I86PC.Solaris_11-8/x86.new

6. Edit the command by typing the options that you need.

   The syntax for a JumpStart installation is the following.

   grub edit>kernel /I86PC.Solaris_11-image_directory/multiboot kernel/unix/ \ - install [url|ask] options -B install_media=media_type

   For a description of JumpStart options, see x86: Command Reference for Booting the System.

   In the following example, the OS is installed over the network with a custom JumpStart profile.

   kernel /I86PC.Solaris_11-8/multiboot kernel/unix/ - install \ -B install_media=131.141.2.32:/export/mary/v11 \ module /I86PC.Solaris_11-8/x86.new

7. To accept the edits, press Enter.

   Your changes are saved and the GRUB main menu is displayed.

   ---

   Note –

   Pressing the Escape key returns you to the GRUB main menu without saving your changes.

   ---

8. To begin the installation, type b.

x86: Command Reference for Booting the System

The following table describes the command-line options for the GRUB menu boot command. The options listed are appropriate for a JumpStart installation.

The syntax of the boot command is the following.

kernel /I86PC.Solaris_11-image_directory/multiboot kernel/unix/ - install \
[url|ask] options -B install_media=media_type

kernel /I86pc.Solaris_11.8/multiboot - install file://jumpstart/config.tar \
 -B install_media=dvdrom module /I86Solaris_11.8/x86.new

Chapter 7 Installing With Custom JumpStart (Examples)

This chapter provides an example of setting up and installing Solaris software on both SPARC based and x86 based systems by using a custom JumpStart installation.

• Sample Site Setup

• Create an Install Server

• x86: Create a Boot Server for Marketing Systems

• Create a JumpStart Directory

• Share the JumpStart Directory

• SPARC: Create the Engineering Group's Profile

• x86: Create the Marketing Group's Profile

• Update the rules File

• Validate the rules File

• SPARC: Set Up Engineering Systems to Install From the Network

• x86: Set Up Marketing Systems to Install From the Network

• SPARC: Boot the Engineering Systems and Install Solaris Software

• x86: Boot the Marketing Systems and Install Solaris Software

Sample Site Setup

Figure 7–1 shows the site setup for this example.

Figure 7–1 Sample Site Setup

At this sample site, the conditions are as follows:

• SPARC: The engineering group is located on its own subnet. This group uses SPARCstation^TM systems for software development.

• x86: The marketing group is located on its own subnet. This group uses x86 based systems for running word processors, spreadsheets, and other office productivity tools.

• The site uses NIS. The Ethernet addresses, IP addresses, and host names of the systems are preconfigured in the NIS maps. The subnet mask, date and time, and geographic region for the site are also preconfigured in the NIS maps.

  ---

  Note –

  The peripheral devices for the marketing systems are preconfigured in the sysidcfg file.

  ---

• Both the engineering and marketing systems are to be installed with Solaris 10 8/07 software from the network.

Create an Install Server

Because the groups need to install Solaris 10 8/07 software from the network, you make server-1 an install server for both groups. You use the setup_install_server(1M) command to copy the images to the server-1 local disk (in the /export/install directory). Copy the images from the either of the following media.

• Solaris Software CDs and the Solaris Languages CD

• Solaris Operating System DVD

You must copy the image from the disc to an empty directory, in these examples the sparc_10 directory and the x86_10 directory.

Example 7–1 SPARC: Copying the Solaris 10 8/07 CDs

Insert the Solaris Software for SPARC Platforms - 1 CD in the CD-ROM drive that is attached to server-1 and type the following commands:

server-1# mkdir -p /export/install/sparc_10
server-1# cd /CD_mount_point/Solaris_10/Tools
server-1# ./setup_install_server /export/install/sparc_10

Insert the Solaris Software for SPARC Platforms - 2 CD in the CD-ROM drive that is attached to server-1 and type the following commands:

server-1# cd /CD_mount_point/Solaris_10/Tools
server-1# ./add_to_install_server /export/install/sparc_10

Repeat the previous command for each Solaris Software you want to install.

Insert the SPARC: Solaris Languages for SPARC Platforms CD in the CD-ROM drive that is attached to server-1 and type the following commands:

server-1# cd /CD_mount_point/Solaris_10/Tools
server-1# ./add_to_install_server /export/install/sparc_10

Example 7–2 x86: Copying the Solaris 10 8/07 CDs

Insert the Solaris Software for x86 Platforms - 1 CD in the CD-ROM drive that is attached to server-1 and type the following commands:

server-1# mkdir -p /export/install/x86_10
server-1# cd /CD_mount_point/Solaris_10/Tools
server-1# ./setup_install_server /export/install/x86_10

Insert the Solaris Software for x86 Platforms - 2 CD in the CD-ROM drive that is attached to server-1 and type the following commands:

server-1# cd /CD_mount_point/Solaris_10/Tools
server-1# ./add_to_install_server /export/install/x86_10

Repeat the previous command for each Solaris Software you want to install.

Insert the Solaris Languages for x86 Platforms CD in the CD-ROM drive that is attached to server-1 and type the following commands:

server-1# cd /CD_mount_point/Solaris_10/Tools
server-1# ./add_to_install_server /export/install/x86_10

Example 7–3 SPARC: Copying the Solaris 10 8/07 DVD

Insert the Solaris Operating System for SPARC Platforms DVD in the DVD-ROM drive that is attached to server-1 and type the following commands:

server-1# mkdir -p /export/install/sparc_10
server-1# cd /DVD_mount_point/Solaris_10/Tools
server-1# ./setup_install_server /export/install/sparc_10

Example 7–4 x86: Copying the Solaris Operating System for x86 Platforms DVD

Insert the Solaris Operating System for x86 Platforms DVD in the DVD-ROM drive that is attached to server-1 and type the following commands:

server-1# mkdir -p /export/install/x86_10
server-1# cd /DVD_mount_point/Solaris_10/Tools
server-1# ./setup_install_server /export/install/x86_10

x86: Create a Boot Server for Marketing Systems

Systems cannot boot from an install server on a different subnet, so you make server-2 a boot server on the marketing group's subnet. You use the setup_install_server(1M) command to copy the boot software from the Solaris Operating System for x86 Platforms DVD or the Solaris Software for x86 Platforms - 1 CD. The boot software is copied to the server-2 local disk in the /export/boot directory.

Choose the media and install the boot software to local disk.

• If you insert the Solaris Software for x86 Platforms - 1 CD in the CD-ROM drive that is attached to server-2, type the following command:

  server-2# cd /CD_mount_point/Solaris_10/Tools server-2# ./setup_install_server -b /export/boot

• If you insert the Solaris Operating System for x86 Platforms DVD in the DVD-ROM drive that is attached to server-2, type the following command:

  server-2# cd /DVD_mount_point/Solaris_10/Tools server-2# ./setup_install_server -b /export/boot

In the setup_install_server command, -b specifies that setup_install_server is to copy the boot information to the directory that is named /export/boot.

Create a JumpStart Directory

Now that you have the install server and boot server set up, you create a JumpStart directory on server-1. You can use any system on the network. This directory holds files that are required for a custom JumpStart installation of Solaris software. You set up this directory by copying the sample directory from the Solaris Operating System DVD image or from the Solaris Software - 1 CD image that has been copied to /export/install:

server-1# mkdir /jumpstart
server-1# cp -r /export/install/sparc_10/Solaris_10/Misc/jumpstart_sample /jumpstart

Share the JumpStart Directory

To make the rules file and profiles accessible to systems on the network, you share the /jumpstart directory. To enable the sharing of a directory, you add the following line to the /etc/dfs/dfstab file:

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

Then, at the command line, you type the shareall command:

server-1# shareall

SPARC: Create the Engineering Group's Profile

For the engineering systems, you create a file that is named eng_prof in the /jumpstart directory. The eng_prof file contains the following entries, which define the Solaris 10 8/07 software to be installed on systems in the engineering group:

install_type  initial_install
system_type   standalone
partitioning  default
cluster       SUNWCprog
filesys       any 512 swap

The previous example profile specifies the following installation information.

install_type

The installation is to be treated as an initial installation, as opposed to an upgrade.

system_type

The engineering systems are standalone systems.

partitioning

The JumpStart software uses default disk partitioning for installing Solaris software on the engineering systems.

cluster

The Developer System Support software group is to be installed.

filesys

Each system in the engineering group is to have 512 Mbytes of swap space.

x86: Create the Marketing Group's Profile

For the marketing systems, you create a file that is named marketing_prof in the /jumpstart directory. The marketing_prof file contains the following entries, which define the Solaris 10 8/07 software to be installed on systems in the marketing group:

install_type  initial_install
system_type   standalone
partitioning  default
cluster       SUNWCuser
package       SUNWaudio

The previous example profile specifies the following installation information.

install_type

The installation is to be treated as an initial installation, as opposed to an upgrade.

system_type

The marketing systems are standalone systems.

partitioning

The JumpStart software is to use default disk partitioning for installing Solaris on the marketing systems.

cluster

The End User Solaris Software Group is to be installed.

package

The audio demo software package is to be added to each system.

Update the rules File

Now you must add rules to the rules file. The Solaris installation program uses the rules to select the correct installation (profile) for each system during a custom JumpStart installation.

At this site, each department is located on its own subnet and has its own network address. The engineering department is located on subnet 255.222.43.0. The marketing department is located on 255.222.44.0. You can use this information to control how the engineering and marketing systems are installed with the Solaris 10 8/07 software. In the /jumpstart directory, you edit the rules file, delete all of the example rules, and add the following lines to the file:

network 255.222.43.0 - eng_prof -
network 255.222.44.0 - marketing_prof -

Basically, these rules state that systems on the 255.222.43.0 network are to be installed with the Solaris 10 8/07 software by using the eng_prof profile. The systems on the 255.222.44.0 network are to be installed with the Solaris 10 8/07 software by using the marketing_prof profile.

You can use the sample rules to use a network address to identify the systems to be installed with the Solaris 10 8/07 software by using eng_prof and marketing_prof, respectively. You can also use host names, memory size, or model type as the rule keyword. Table 8–1 contains a complete list of keywords you can use in a rules file.

Validate the rules File

After the rules and profiles are set up, you run the check script to verify that the files are correct:

server-1# cd /jumpstart
server-1# ./check

If the check script does not find any errors, the script creates the rules.ok file.

SPARC: Set Up Engineering Systems to Install From the Network

After setting up the /jumpstart directory and files, you use the add_install_client command on the install server, server-1, to set up the engineering systems to install the Solaris software from the install server. server-1 is also the boot server for the engineering group's subnet.

server-1# cd /export/install/sparc_10/Solaris_10/Tools
server-1# ./add_install_client -c server-1:/jumpstart host-eng1 sun4u
server-1# ./add_install_client -c server-1:/jumpstart host-eng2 sun4u

In the add_install_client command, the options that are used have the following meanings:

-c

Specifies the server (server-1) and path (/jumpstart) to the JumpStart directory. Use this option if you are using NFS.

---

Note –

If you are not using NFS, you specify the path to the JumpStart directory by using the following commands:

• For SPARC based systems, specify the path in the boot command

• For x86 based systems, specify the path by editing the GRUB menu entry

---

host-eng1

The name of a system in the engineering group.

host-eng2

The name of another system in the engineering group.

sun4u

Specifies the platform group of the systems that use server-1 as an install server. The platform group is for Ultra 5 systems.

x86: Set Up Marketing Systems to Install From the Network

Next, you use the add_install_client command on the boot server (server-2). This command sets up the marketing systems to boot from the boot server and install the Solaris software from the install server (server-1):

server-2# cd /marketing/boot-dir/Solaris_10/Tools
server-2# ./add_install_client -s server-1:/export/install/x86_10 \
-c server-1:/jumpstart host-mkt1 i86pc
server-2# ./add_install_client -s server-1:/export/install/x86_10 \
-c server-1:/jumpstart host-mkt2 i86pc
server-2# ./add_install_client -d -s server-1:/export/install/x86_10 \
-c server-1:/jumpstart SUNW.i86pc i86pc
server-2# ./add_install_client -c server-1:/jumpstart host-mkt1 sun4u
server-2# ./add_install_client -c server-1:/jumpstart host-mkt2 sun4u

In the add_install_client command, the options that are used have the following meanings:

-d

Specifies that the client is to use DHCP to obtain the network install parameters. This option is required for clients to use PXE network boot to boot from the network. -d is optional for network boot clients that do not use PXE network boot.

-s

Specifies the install server (server-1) and the path to the Solaris software (/export/install/x86_10).

-c

Specifies the server (server-1) and path (/jumpstart) to the JumpStart directory. Use this option if you are using NFS.

---

Note –

If you are not using NFS, you specify the path to the JumpStart directory by using the following commands:

• For SPARC based systems, specify the path in the boot command

• For x86 based systems, specify the path by editing the GRUB menu entry

---

host-mkt1

The name of a system in the marketing group.

host-mkt2

The name of another system in the marketing group.

sun4u

Specifies the platform group of the systems that use server-1 as an install server. The platform group is for Ultra 5 systems.

SUNW.i86pc

The DHCP class name for all Solaris x86 clients. If you want to configure all Solaris x86 DHCP clients with a single command, use this class name.

i86pc

Specifies the platform group of the systems that use this boot server. The platform name represents x86 based systems.

SPARC: Boot the Engineering Systems and Install Solaris Software

After setting up the servers and files, you can boot the engineering systems by using the following boot command at the ok (PROM) prompt of each system:

ok boot net - install

The Solaris OS is automatically installed on the engineering group's systems.

x86: Boot the Marketing Systems and Install Solaris Software

You can boot the system from one of the following:

• Solaris Software for x86 Platforms - 1 CD

• Solaris Operating System for x86 Platforms DVD

• The network by using PXE network boot

Solaris software is automatically installed on the marketing group's systems.

Chapter 8 Custom JumpStart (Reference)

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

• Rule Keywords and Values

• Profile Keywords and Values

• Custom JumpStart Environment Variables

• Probe Keywords and Values

Rule Keywords and Values

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

disksize c0t3d0 250-300

disksize rootdisk 750-1000

installed c0t3d0s1 Solaris 10

memsize 64-128

network 192.168.2.0

osname Solaris 10

probe disks

totaldisk 300-500

Profile Keywords and Values

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

Profile Keywords Quick Reference

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

Profile Keyword Descriptions and Examples

archive_location Keyword

archive_location retrieval_type location

retrieval_type

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

• Archive Stored on an NFS Server

• Archive Stored on an HTTP or HTTPS Server

• Archive Stored on an FTP Server

• Archive Stored on a Local Tape

• Archive Stored on a Local Device

• Archive Stored on a Local File

location

Specifics for locations are noted in the following sections.

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

• The archive is created in a non-global zone

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

Archive Stored on an NFS Server

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

archive_location nfs server_name:/path/filename retry n

server_name

The name of the server where you stored the archive.

path

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

filename

The name of the Solaris Flash archive file.

retry n

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

Example 8–1 Archive Stored on an NFS Server

archive_location nfs golden:/archives/usrarchive

archive_location nfs://golden/archives/usrarchive

Archive Stored on an HTTP or HTTPS Server

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

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

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

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

server_name

The name of the server where you stored the archive.

port

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

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

path

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

filename

The name of the Solaris Flash archive file.

optional_keywords

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

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

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

Example of the auth basic user_name password keyword:

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

Archive Stored on an FTP Server

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

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

user_name:password

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

server_name

The name of the server where you stored the archive.

port

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

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

path

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

filename

The name of the Solaris Flash archive file.

optional_keywords

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

Example 8–3 Archive Stored on an FTP Server

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

Archive Stored on a Local Tape

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

archive_location local_tape device position

device

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

position

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

Example 8–4 Archive Stored on a Local Tape

archive_location local_tape /dev/rmt/0n 5

archive_location local_tape 0n 5

Archive Stored on a Local Device

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

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

archive_location local_device device path/filename file_system_type

device

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

path

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

filename

The name of the Solaris Flash archive file.

file_system_type

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

Example 8–5 Archive Stored on a Local Device

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

archive_location local_device c0t0d0s0 /archives/$HOST

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

archive_location local_device c0t0d0s0 /archives/usrarchive

Archive Stored on a Local File

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

archive_location local_file path/filename 

path

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

filename

The name of the Solaris Flash archive file.

Example 8–6 Archive Stored on a Local File

archive_location local_file /archives/usrarchive

backup_media Profile Keyword

backup_media type path

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

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

Example 8–7 backup_media Profile Keyword

backup_media local_tape /dev/rmt/0

backup_media local_diskette /dev/rdiskette1

backup_media local_filesystem /dev/dsk/c0t3d0s4

backup_media local_filesystem /export

backup_media remote_filesystem system1:/export/temp

backup_media remote_system user1@system1:/export/temp

boot_device Profile Keyword

boot_device device eeprom

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

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

boot_device any update

device

Use one of the following values.

SPARC: cwtxdysz or cxdysz

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

x86: cwtxdy or cxdy

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

existing

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

any

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

eeprom

Choose to update or preserve the system's EEPROM.

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

---

Note –

x86: You must specify the preserve value.

---

update

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

preserve

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

Example 8–8 boot_device Profile Keyword

boot_device c0t0d0s2 update

bootenv createbe Profile Keyword

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

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

bename new_BE_name

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

filesystem mountpoint:device:fs_options

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

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

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

• fs_options can be one of the following:

  • ufs, which indicates a UFS file system.

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

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

client_arch Profile Keyword

client_arch karch_value ...

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

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

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

client_root Profile Keyword

client_root root_size

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

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

client_swap Profile Keyword

client_swap swap_size

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

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

Example 8–9 client_swap Profile Keyword

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

client_swap 64

How the Size of swap Is Determined

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

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

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

cluster Profile Keyword (Adding Software Groups)

cluster group_name

cluster designates the software group to add to the system.

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

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

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

The following limitations apply:

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

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

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

For more information about software groups, see Disk Space Recommendations for Software Groups in Solaris 10 8/07 Installation Guide: Planning for Installation and Upgrade.

cluster Profile Keyword (Adding or Deleting Clusters)

cluster cluster_name add_delete_switch

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

cluster_name

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

add_delete_switch

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

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

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

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

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

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

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

dontuse Profile Keyword

dontuse disk_name ...

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

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

x86: fdisk Profile Keyword

fdisk disk_name type size

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

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

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

  ---

  Note –

  The system boots from the active partition by default.

  ---

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

  fdisk all solaris maxfree

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

disk_name

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

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

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

• all – All the selected disks.

type

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

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

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

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

  ---

  Note –

  You can specify this value only if size is delete.

  ---

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

  ---

  Note –

  You can specify this value only if size is delete.

  ---

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

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

size

Use one of the following values:

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

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

  ---

  x86 only –

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

  ---

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

  ---

  x86 only –

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

  ---

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

filesys Profile Keyword (Mounting Remote File Systems)

filesys server:path server_address mount_pt_name mount_options

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

server

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

path

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

server_address

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

mount_pt_name

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

mount_options

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

---

Note –

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

---

Example 8–10 filsys Profile Keyword

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

filesys Profile Keyword (Creating Local File Systems)

filesys slice size file_system optional_parameters

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

slice

Use one of the following values:

any

The JumpStart program places the file system on any disk.

---

Note –

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

---

cwtxdysz or cxdysz

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

rootdisk.sn

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

---

Note –

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

---

size

Use one of the following values:

num

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

existing

The current size of the existing file system is used.

---

Note –

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

---

auto

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

all

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

free

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

---

Note –

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

---

start:size

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

file_system

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

mount_pt_name

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

swap

The specified slice is used as swap.

overlap

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

---

Note –

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

---

unnamed

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

ignore

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

optional_parameters

Use one of the following values:

preserve

The file system on the specified slice is preserved.

---

Note –

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

---

mount_options

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

---

Note –

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

---