Solaris 10 8/07 Installation Guide: Custom JumpStart and Advanced Installations

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 Descriptions From the Planning Guide 

Reference 

This chapter describes new features in the Solaris installation programs. 

Chapter 2, What’s New in Solaris Installation, in Solaris 10 8/07 Installation Guide: Planning for Installation and Upgrade

This chapter provides you with information about decisions you need to make before you install or upgrade the Solaris OS. Examples are deciding when to use a network installation image or DVD media and descriptions of all the Solaris installation programs. 

Chapter 3, Solaris Installation and Upgrade (Roadmap), in Solaris 10 8/07 Installation Guide: Planning for Installation and Upgrade

This chapter describes system requirements to install or upgrade to the Solaris OS. General guidelines for planning the disk space and default swap space allocation are also provided. Upgrade limitations are also described. 

Chapter 4, System Requirements, Guidelines, and Upgrade (Planning), in Solaris 10 8/07 Installation Guide: Planning for Installation and Upgrade

This chapter contains checklists to help you gather all of the information that you need to install or upgrade your system. This information is useful, for example, if you are performing an interactive installation. You'll have all the information in the checklist that you'll need to do an interactive installation. 

Chapter 5, Gathering Information Before Installation or Upgrade (Planning), in Solaris 10 8/07 Installation Guide: Planning for Installation and Upgrade

These chapters provide overviews of several technologies that relate to a Solaris OS installation or upgrade. Guidelines and requirements related to these technologies are also included. These chapters include information about GRUB based booting, Solaris Zones partitioning technology, and RAID-1 volumes that can be created at installation. 

Part II, Understanding Installations That Relate to GRUB, Solaris Zones, and RAID-1 Volumes, in Solaris 10 8/07 Installation Guide: Planning for Installation and Upgrade

Chapter 2 Custom JumpStart (Overview)

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

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:

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.

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

The context describes the illustration.

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

The context describes the illustration.

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

The flow diagram shows the order in which the custom
JumpStart program searches for files.

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

Table 3–1 Task Map: Preparing Custom JumpStart Installations

Task 

Description 

For Instructions 

Decide how to upgrade the system if a previous version of the Solaris software is installed on the system. 

If a previous release of Solaris is installed on the system, you need to determine how to upgrade the system. Ensure that you know what to do before and after you upgrade a system. Planning helps you to create your profiles, begin scripts, and finish scripts. 

Upgrade Planning in Solaris 10 8/07 Installation Guide: Planning for Installation and Upgrade

Create a JumpStart directory. 

On a server

If you want to perform custom JumpStart installations on systems that are connected to a network, you must create a profile server. The profile server contains a JumpStart directory for the custom JumpStart files.  

Creating a Profile Server for Networked Systems

On a diskette

If you want to perform custom JumpStart installations on systems that are not connected to a network, you must create a profile diskette. A profile diskette contains the custom JumpStart files. 

Creating a Profile Diskette for Standalone Systems

Add rules to the rules file.

After you decide how you want each group of systems or single systems to be installed, create a rule for each group that you want to install. Each rule distinguishes a group, based on one or more system attributes. The rule links each group to a profile.  

Creating the rules File

Create a profile for every rule. 

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

Creating a Profile

(Optional) Test the profiles. 

After you create a profile, use the pfinstall(1M) command to test the profile before you use the profile to install or upgrade a system.

Testing a Profile

Validate the rules file.

The rules.ok file is a generated version of the rules file that the JumpStart program uses to match the system to be installed with a profile. You must use the check script to validate the rules file.

Validating the rules File

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.


Note –

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.


ProcedureTo Create a JumpStart Directory on a Server


Note –

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.

Command or File 

Providing Access 

Instructions 

add_install_client command

Each time that you add a system for network installation, use the -c option with the add_install_client command to specify the profile server.


Note –

If you are not using NFS, then you must use another means to provide access.

  • For SPARC based systems, use the boot command

  • For x86 based systems, edit the GRUB menu


Specify the location of the JumpStart directory when you boot the system 

  • For SPARC based systems, use the boot command to boot the system. Specify the location of the JumpStart directory on the profile server when you boot the system. You must compress the custom JumpStart configuration files into one file. Then, save the compressed configuration file on an HTTP or HTTPS server.

  • For x86 based systems, specify the location of the JumpStart directory on the profile server when you boot the system by editing the boot entry on the GRUB menu. You must compress the custom JumpStart configuration files into one file. Then, save the compressed configuration file on an HTTP or HTTPS server.

    When you edit the GRUB menu entry, specify the location of the compressed file.

/etc/bootparams file

Add a wildcard in the /etc/bootparams file.

To Allow All Systems Access to the Profile Server

ProcedureTo Allow All Systems Access to the Profile Server

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

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 have the above conditions, use the SPARC boot command or use the x86 GRUB menu.


Note –

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


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

ProcedureSPARC: To Create a Profile Diskette


Note –

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.

Procedurex86: 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.


Note –

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.


Note –

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 rules file can contain any of the following:

ProcedureTo 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

Note –

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


Syntax of Profiles

A profile must contain the following:

A profile can contain the following:

ProcedureTo 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:



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



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



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.



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:

ProcedureTo 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:

  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.

ProcedureTo Test a Profile


x86 only –

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

Table 3–2 What Happens When You Use the check Script

Stage 

Description 

The rules file is checked for syntax.

 

check verifies that the rule keywords are legitimate and that the begin, class, and finish fields are specified for each rule. The begin and finish fields can consist of a minus sign (-) instead of a file name.

If no errors are found in the rules file, each profile that is specified in the rules is checked for syntax.

If no errors are found, check creates the rules.ok file from the rules file, removes all comments and blank lines, retains all rules, and adds the following comment line at the end:

# version=2 checksum=num

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


Note –

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:

Important Information About Begin Scripts


Note –

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:

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.



Note –

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:

Important Information About Finish Scripts

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


Note –

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



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


Note –

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.


Note –

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.


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.

Table 4–1 Solaris Installation Options

Option 

Description 

-nodisplay

Runs the installer without a graphic user interface. Use the default product installation unless the installation was modified by the -locales option.

-noconsole

Runs the installation without any interactive text console device. Useful when paired with -nodisplay for UNIX script use.

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.

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

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

ProcedureSPARC: 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.


Procedurex86: 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

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:

Syntax of the custom_probes File

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


Note –

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:

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.

ProcedureTo 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:

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.


Note –

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.

Table 5–1 What Happens When You Use the check Script

Stage 

Description 

check searches for a custom_probes file.

If the file exists, check creates the custom_probes.ok file from the custom_probes file, removes all comments and blank lines, and retains all Bourne shell commands, variables, and algorithms. Then, check adds the following comment line at the end:

# version=2 checksum=num

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

Limitations for a JumpStart Installation

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

Table 6–1 JumpStart Installation Limitations

Issue 

Description 

For More Information 

The sample JumpStart script is no longer required to suppress the NFSv4 prompt 

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/07 release, 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 is displayed and you are prompted to provide a domain name before the boot process completes.

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

Selecting a keyboard language in the sysidcfg file prevents a prompt

If your keyboard is not self-identifying and you want to prevent being prompted during your JumpStart installation, select the keyboard language in your sysidcfg file. For JumpStart installations, the default is for the U.S. English language. To select another language and its corresponding keyboard layout, set the keyboard keyword in your sysidcfg file.

If you have non-global zones, use Solaris Live Upgrade to upgrade 

You can upgrade a system that has non-global zones installed with JumpStart, but Solaris Live Upgrade is the recommended program to upgrade. JumpStart might require extensive upgrade time, because the time required to complete the upgrade increases linearly with the number of installed non-global zones. 

Solaris 10 8/07 Installation Guide: Solaris Live Upgrade and Upgrade Planning

An archive cannot contain non-global zones 

If you use a Solaris Flash archive to install, an archive that contains non-global zones is not properly installed on your system.  

For general information about creating non-global zones, see System Administration Guide: Solaris Containers-Resource Management and Solaris Zones.

SPARC: Additional hardware requirements 

Refer to your hardware documentation for any additional requirements for your platform that might be required to complete a JumpStart installation. 

 

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

Table 6–2 Task Map: Setting Up a System for a Custom JumpStart Installation

Task 

Description 

For Instructions 

Check if the system is supported. 

Check the hardware documentation for system support in the Solaris environment. 

Solaris Sun Hardware Platform Guide at http://docs.sun.com

Check if the system has enough disk space for the Solaris software. 

Verify that you have planned enough space to install the Solaris software on your system. 

Chapter 4, System Requirements, Guidelines, and Upgrade (Planning), in Solaris 10 8/07 Installation Guide: Planning for Installation and Upgrade

(Optional) Set system parameters. 

You can preconfigure system information to avoid being prompted for the information during the installation or upgrade. 

Chapter 2, Preconfiguring System Configuration Information (Tasks), in Solaris 10 8/07 Installation Guide: Network-Based Installations

Prepare the system for custom JumpStart installation. 

Create and validate a rules file and profile files.

Chapter 3, Preparing Custom JumpStart Installations (Tasks)

(Optional) Prepare optional custom JumpStart features. 

If you are using begin scripts, finish scripts, or other optional features, prepare the scripts or files. 

Chapter 4, Using Optional Custom JumpStart Features (Tasks) and Chapter 5, Creating Custom Rule and Probe Keywords (Tasks)

(Optional) Prepare to install the Solaris software from the network. 

To install a system from a remote Solaris Operating System DVD or Solaris Software for SPARC Platforms CD image, you need to set up the system to boot and install from an install server or a boot server. 

Chapter 5, Installing From the Network With DVD Media (Tasks), in Solaris 10 8/07 Installation Guide: Network-Based Installations

Chapter 6, Installing From the Network With CD Media (Tasks), in Solaris 10 8/07 Installation Guide: Network-Based Installations

(Optional) Prepare for a Solaris Flash archive installation. 

Set up specifics for a Solaris Flash archive installation. 

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

Perform an installation or upgrade. 

Boot the system to initiate the installation or upgrade. 

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

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.

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

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

    fdisk (x86 only)

    filesys


    Note –

    You cannot set the filesys keyword to the value auto.


     

    forced_deployment

     

    (required) install_type

    local_customization

    no_content_check

     

    no_master_check

     

    package

     

    root_device

    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:

  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.

ProcedureSPARC: 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.

Option 

Description 

[cd–dvd|net]

Specifies to boot from a CD or a DVD or to boot from an install server on the network. 

  • cd-dvd - Use cdrom to boot from a CD or a DVD.

  • net - Specifies to boot from an install server on the network.

[url| ask]

Specifies the location of the custom JumpStart files or prompts you for the location.  

  • url – Specifies the path to the files. You can specify a URL for files that are located in an HTTP or HTTPS server:

    HTTP server


    http://server_name:IP_address/jumpstart_dir_path/
    compressed_config_file&proxy_info
    
    • If you placed a sysidcfg file in the compressed configuration file, you must specify the IP address of the server that contains the file, as in the following example:


      http://131.141.2.32/jumpstart/config.tar
    • If you saved the compressed configuration file on an HTTP server that is behind a firewall, you must use a proxy specifier during boot. You do not need to specify an IP address for the server that contains the file. You must specify an IP address for the proxy server, as in the following example:


      http://www.shadow.com/jumpstart/
      config.tar&proxy=131.141.6.151
  • ask – Specifies that the installation program prompt you to type the location of the compressed configuration file. The prompt happens after the system boots and connects to the network. If you use this option, you are not able to do a completely hands off JumpStart installation.

    If you bypass the prompt by pressing Return, the Solaris installation program interactively configures the network parameters. The installation program then prompts you for the location of the compressed configuration file.

options

  • dhcp – Specifies to use a DHCP server to obtain network installation information that is needed to boot the system. This option is not needed for a JumpStart installation. If you do not specify to use a DHCP server by typing dhcp, the system uses the /etc/bootparams file or the naming service bootparams database. For example, you would not specify dhcp if you wanted keep a static IP address.

  • The options nowin and text do not apply to a JumpStart installation. These options are useful with an interactive installation. For more information, see To Install or Upgrade With the Solaris Installation Program in Solaris 10 8/07 Installation Guide: Basic Installations.

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

Table 6–3 x86: Task Map: Setting Up a System for a Custom JumpStart Installation

Task 

Description 

For Instructions 

Determine if you need to preserve an existing operating system and user data. 

If the existing operating system on the system uses the entire disk, you must preserve the existing operating system so it can co-exist with the Solaris 10 8/07 software. This decision determines how to specify the fdisk(1M) keyword in the system's profile.

x86: fdisk Profile Keyword

Check if the system is supported. 

Check the hardware documentation for system support in the Solaris environment. 

Hardware manufacturer's documentation 

Check if the system has enough disk space for the Solaris software. 

Verify that you have planned enough space to install the Solaris software on your system. 

Chapter 4, System Requirements, Guidelines, and Upgrade (Planning), in Solaris 10 8/07 Installation Guide: Planning for Installation and Upgrade

(Optional) Set system parameters. 

You can preconfigure system information to avoid being prompted for the information during the installation or upgrade. 

Chapter 2, Preconfiguring System Configuration Information (Tasks), in Solaris 10 8/07 Installation Guide: Network-Based Installations

Prepare the system for custom JumpStart installation. 

Create and validate a rules file and profile files.

Chapter 3, Preparing Custom JumpStart Installations (Tasks)

(Optional) Prepare optional custom JumpStart features. 

If you are using begin scripts, finish scripts, or other optional features, prepare the scripts or files. 

Chapter 4, Using Optional Custom JumpStart Features (Tasks) and Chapter 5, Creating Custom Rule and Probe Keywords (Tasks)

(Optional) Prepare to install the Solaris software from the network. 

To install a system from a remote Solaris Operating System for x86 Platforms DVD or Solaris Software For x86 Platforms CD image, you need to set up the system to boot and install from an install server or a boot server. 

Chapter 6, Installing From the Network With CD Media (Tasks), in Solaris 10 8/07 Installation Guide: Network-Based Installations

(Optional) Prepare for a Solaris Flash archive installation. 

Set up specifics for a Solaris Flash archive installation. 

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

Perform an installation or upgrade. 

Boot the system to initiate the installation or upgrade. 

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

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:

Procedurex86: 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.

Procedurex86: 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
Table 6–4 GRUB Menu Boot Command Reference

Option 

Description 

- install

Performs a custom JumpStart installation. 

In the following example, the system boots from DVD media and the following options were used: 

  • - install performs a custom JumpStart

  • file://jumpstart/config.tar finds the JumpStart profile on the local disk


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

[url| ask]

Specifies the location of the custom JumpStart files or prompts you for the location.  

  • url – Specifies the path to the files. You can specify a URL for files that are located on an HTTP or HTTPS server:

    The syntax for an HTTP server is the following:


    http://server_name:IP_address/jumpstart_dir_path/
    compressed_config_file&proxy_info
    
    • If you placed a sysidcfg file in the compressed configuration file, you must specify the IP address of the server that contains the file, as in the following example:


      kernel /I86pc.Solaris_11.8/multiboot install \
      http://192.168.2.1/jumpstart/config.tar \
       -B install_media=192.168.2.1/export/Solaris_11.8/boot \
      module /I86PC.Solaris_11.8/x86.new
    • If you saved the compressed configuration file on an HTTP server that is behind a firewall, you must use a proxy specifier during boot. You do not need to specify an IP address for the server that contains the file. You must specify an IP address for the proxy server, as in the following example:


      kernel /I86pc.Solaris_11.8/multiboot install \
      http://www.shadow.com/jumpstart/config.tar&proxy=131.141.6.151 \
       -B install_media=192.168.2.1/export/Solaris_11.8/boot \
      module /I86PC.Solaris_11.8/x86.new
  • ask – Specifies that the installation program prompt you to type the location of the compressed configuration file. You are prompted after the system boots and connects to the network. If you use this option, you are not able to do a completely hands off JumpStart installation.

    If you bypass the prompt by pressing Return, the Solaris installation program interactively configures the network parameters. The installation program then prompts you for the location of the compressed configuration file.

    The following example performs a custom JumpStart and boots from DVD media. You are prompted to type the location of the configuration file after the system connects to the network.


    kernal /boot/multiboot kernel/unix install ask -B \
    install_media=192.168.2.1:export/sol_11_x86/boot module \
    /I86PC.Solaris_11.8_

options

  • dhcp – Specifies to use a DHCP server to obtain network installation information that is needed to boot the system. This option is not needed for a JumpStart installation. If you do not specify to use a DHCP server by typing dhcp, the system uses the /etc/bootparams file or the naming service bootparams database. For example, you would not specify dhcp if you wanted keep a static IP address. For example:


    kernel /I86pc.Solaris_11.8/multiboot install \
    dhcp -B install_media=192.168.2.1:/export/Solaris_11.8/ \
    boot module /I86PC.Solaris_11.8/x86.new
  • The options nowin and text do not apply to a JumpStart installation. These options are useful with an interactive installation. For more information, see To Install or Upgrade With the Solaris Installation Program With GRUB in Solaris 10 8/07 Installation Guide: Basic Installations.

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

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

Figure 7–1 Sample Site Setup

This illustration shows an install server on the engineering
subnet and a boot server on the marketing subnet.

At this sample site, the conditions are as follows:

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.

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.

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.


Note –

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

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

Table 8–1 Descriptions of Rule Keywords and Values

Keyword 

Value 

Matches 

any

minus sign (-)

Anything. The any keyword always succeeds.

arch

processor_type

Valid values for processor_type are the following:

  • SPARC: sparc

  • x86: i386

A system's processor type. 

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

disksize

actual_disk_name size_range

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

  • SPARC: The disk that contains the preinstalled boot image, which is a new SPARC based system with factory JumpStart installed

  • The c0t3d0s0 disk, if the disk exists

  • The first available disk that is searched in kernel probe order

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


Note –

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


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

Example:  

disksize c0t3d0 250-300

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

Example:  

disksize rootdisk 750-1000

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

  1. A system disk that contains a preinstalled boot image

  2. The c0t3d0s0 disk, if the disk exists

  3. The first available disk that can hold between 750 Mbytes and 1 Gbyte of information

domainname

actual_domain_name

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

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

hostaddress

actual_IP_address

A system's IP address. 

hostname

actual_host_name

A system's host name.  

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

installed

slice version

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

  • SPARC: The disk that contains the preinstalled boot image, which is a new SPARC based system with factory JumpStart installed

  • The c0t3d0s0 disk, if the disk exists

  • The first available disk that is searched in kernel probe order

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

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

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

Example:  

installed c0t3d0s1 Solaris 10

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

karch

actual_platform_group

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

A system's platform group. 

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

memsize

physical_mem

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

A system's physical memory size in Mbytes. 

Example:  

memsize 64-128

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

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

model

actual_platform_name

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

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


Note –

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

Example:

SUNW,Sun_4_50


network

network_num

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

Example:  

network 192.168.2.0

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

osname

Solaris_x

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

Example:  

osname Solaris 10

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

probe

probe_keyword

A valid probe keyword or a valid custom probe keyword. 

Example:  

probe disks

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


Note –

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


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

totaldisk

size_range

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


Note –

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


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

Example:  

totaldisk 300-500

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

Profile Keywords and Values

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

Profile Keywords Quick Reference

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

Table 8–2 Profile Keywords Overview
 

Installation Scenarios 

Profile Keyword 

Standalone System (Nonnetworked) 

Standalone System (Networked) or Server 

OS Server 

Upgrade 

Upgrade With Disk Space Reallocation 

archive_location (installing Solaris Flash archives)

     

backup_media

       

boot_device

   

bootenv createbe

   

client_arch

   

   

client_root

   

   

client_swap

   

   

cluster (adding software groups)

   

cluster (adding or deleting clusters)

dontuse

   

fdisk (x86 only)

   

filesys (mounting remote file systems)

 

   

filesys (creating local file systems)

   

filesys (creating mirrored file systems)

 

 

forced_deployment (installing Solaris Flash differential archives)

 

 

 

geo

install_type

layout_constraint

       

local_customization (installing Solaris Flash archives)

 

 

 

locale

metadb (creating state database replicas)

 

 

no_master_check (installing Solaris Flash differential archives)

 

 

 

no_content_check (installing Solaris Flash differential archives)

 

 

 

num_clients

   

   

package

partitioning

 

 

patch

root_device

system_type

 

 

usedisk

   

Profile Keyword Descriptions and Examples

archive_location Keyword

archive_location retrieval_type location
retrieval_type

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

location

Specifics for locations are noted in the following sections.


Caution – Caution –

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


Archive Stored on an NFS Server

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


archive_location nfs server_name:/path/filename retry n
server_name

The name of the server where you stored the archive.

path

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

filename

The name of the Solaris Flash archive file.

retry n

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


Example 8–1 Archive Stored on an NFS Server

archive_location nfs golden:/archives/usrarchive

archive_location nfs://golden/archives/usrarchive

Archive Stored on an HTTP or HTTPS Server

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


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

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


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

The name of the server where you stored the archive.

port

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

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

path

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

filename

The name of the Solaris Flash archive file.

optional_keywords

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

Table 8–3 Optional Keywords to Use With archive_location HTTP

Keyword 

Value Definition 

auth basic user_name password

If the archive is located on an HTTP server that is password protected, you must include the user name and password that you need to access the HTTP server in the profile file.  


Note –

The use of this authentication method in a profile that is intended for use with custom JumpStart is risky. Unauthorized users might have access to the profile file that contains the password.


timeout min

The timeout keyword enables you to specify, in minutes, the maximum length of time that is allowed to pass without receipt of data from the HTTP server. If a timeout occurs, the connection is closed, reopened, and resumed. If you specify a timeout value of 0 (zero), the connection is not reopened.

  • If a timeout reconnection occurs, the Solaris Flash installation utilities attempt to resume the installation at the last known position in the archive. If the Solaris Flash installation utilities cannot resume the installation at the last known position, the retrieval restarts from the beginning of the archive and the data that was retrieved prior to the timeout is discarded.

  • If a timeout reconnection occurs while a package is being installed, the package is retried from the beginning of the package and the data that was retrieved prior to the timeout is discarded.

proxy host:port

The proxy keyword enables you to specify a proxy host and proxy port. You can use a proxy host to retrieve a Solaris Flash archive from the other side of a firewall. You must supply a proxy port when you specify the proxy keyword.


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

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

Example of the auth basic user_name password keyword:

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

Archive Stored on an FTP Server

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


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

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

server_name

The name of the server where you stored the archive.

port

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

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

path

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.

Table 8–4 Optional Keywords to Use With archive_location FTP

Keyword 

Value Definition 

timeout min

The timeout keyword enables you to specify, in minutes, the maximum length of time that is allowed to pass without receipt of data from the HTTP server. If a timeout occurs, the connection is closed, reopened, and resumed. If you specify a timeout value of 0 (zero), the connection is not reopened.

  • If a timeout reconnection occurs, the Solaris Flash installation utilities attempt to resume the installation at the last known position in the archive. If the Solaris Flash installation utilities cannot resume the installation at the last known position, the retrieval restarts from the beginning of the archive and the data that was retrieved prior to the timeout is discarded.

  • If a timeout reconnection occurs while a package is being installed, the package is retried from the beginning of the package and the data that was retrieved prior to the timeout is discarded.

proxy host:port

The proxy keyword enables you to specify a proxy host and proxy port. You can use a proxy host to retrieve a Solaris Flash archive from the other side of a firewall. You must supply a proxy port when you specify the proxy keyword.


Example 8–3 Archive Stored on an FTP Server

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

Archive Stored on a Local Tape

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


archive_location local_tape device position
device

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

position

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


Example 8–4 Archive Stored on a Local Tape

archive_location local_tape /dev/rmt/0n 5

archive_location local_tape 0n 5

Archive Stored on a Local Device

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


Note –

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



archive_location local_device device path/filename file_system_type
device

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

path

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

filename

The name of the Solaris Flash archive file.

file_system_type

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


Example 8–5 Archive Stored on a Local Device

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

archive_location local_device c0t0d0s0 /archives/$HOST

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

archive_location local_device c0t0d0s0 /archives/usrarchive

Archive Stored on a Local File

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


archive_location local_file path/filename 
path

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

filename

The name of the Solaris Flash archive file.


Example 8–6 Archive Stored on a Local File

archive_location local_file /archives/usrarchive

backup_media Profile Keyword

backup_media type path

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

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

Valid type Value

Valid path Value

Specification 

local_tape

/dev/rmt/n

A local tape drive on the system that is being upgraded. path must be the character (raw) device path for the tape drive. n is the number of the tape drive.

local_diskette

/dev/rdisketten

A local diskette drive on the system that is being upgraded. path must be the character (raw) device path for the diskette drive. n is the number of the diskette drive.

Diskettes that you use for the backup must be formatted. 

local_filesystem

/dev/dsk/cwtxdysz

/file_system

A local file system on the system that is being upgraded. You cannot specify a local file system that is being changed by the upgrade. path can be a block device path for a disk slice. For example, the tx in /dev/dsk/cwtxdysz might not be needed. Or, path can be the absolute path to a file system that is mounted by the /etc/vfstab file.

remote_filesystem

host:/file_system

An NFS file system on a remote system. path must include the name or IP address of the remote system, host, and the absolute path to the NFS file system, file_system. The NFS file system must have read/write access.

remote_system

user@host:/directory

A directory on a remote system that can be reached by a remote shell, rsh. The system that is being upgraded must have access to the remote system through the remote system's .rhosts file. path must include the name of the remote system host and the absolute path to the directory directory. If a user login ID user is not specified, root is used by default.


Example 8–7 backup_media Profile Keyword

backup_media local_tape /dev/rmt/0

backup_media local_diskette /dev/rdiskette1

backup_media local_filesystem /dev/dsk/c0t3d0s4

backup_media local_filesystem /export

backup_media remote_filesystem system1:/export/temp

backup_media remote_system user1@system1:/export/temp

boot_device Profile Keyword

boot_device device eeprom

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

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


boot_device any update
device

Use one of the following values.

SPARC: cwtxdysz or cxdysz

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

x86: cwtxdy or cxdy

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

existing

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

any

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

eeprom

Choose to update or preserve the system's EEPROM.

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


Note –

x86: You must specify the preserve value.


update

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

preserve

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


Example 8–8 boot_device Profile Keyword

boot_device c0t0d0s2 update

bootenv createbe Profile Keyword

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

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

bename new_BE_name

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

filesystem mountpoint:device:fs_options

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

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

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

  • fs_options can be one of the following:

    • ufs, which indicates a UFS file system.

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

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

For an example of a profile 

Example 3–11

For background about using Solaris Live Upgrade that creates, upgrades, and activates inactive boot environments 

Chapter 2, Solaris Live Upgrade (Overview), in Solaris 10 8/07 Installation Guide: Solaris Live Upgrade and Upgrade Planning

For background about using a Solaris Flash archive 

Chapter 1, Solaris Flash (Overview), in Solaris 10 8/07 Installation Guide: Solaris Flash Archives (Creation and Installation)

client_arch Profile Keyword

client_arch karch_value ...

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

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


Note –

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


client_root Profile Keyword

client_root root_size

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


Note –

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


client_swap Profile Keyword

client_swap swap_size

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


Note –

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



Example 8–9 client_swap Profile Keyword

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

client_swap 64

How the Size of swap Is Determined

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

Table 8–5 Determining swap Size

Physical Memory (in Mbytes) 

Swap Space (in Mbytes) 

16–64 

32 

64–128 

64 

128–512 

128 

Greater than 512 

256 

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


Note –

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


cluster Profile Keyword (Adding Software Groups)

cluster group_name

cluster designates the software group to add to the system.


Note –

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

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


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

Software Group 

group_name

Reduced Network Support Software Group 

SUNWCrnet

Core System Support Software Group 

SUNWCreq

End User Solaris Software Group 

SUNWCuser

Developer Solaris Software Group 

SUNWCprog

Entire Solaris Software Group 

SUNWCall

Entire Solaris Software Group Plus OEM Support 

SUNWCXall

The following limitations apply:

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:


Note –

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

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


dontuse Profile Keyword

dontuse disk_name ...

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


Note –

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


x86: fdisk Profile Keyword

fdisk disk_name type size

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

disk_name

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

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

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

  • all – All the selected disks.

type

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

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

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

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


    Note –

    You can specify this value only if size is delete.


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


    Note –

    You can specify this value only if size is delete.


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

fdisk Type

DDD

HH

DOSOS12 

1

01

PCIXOS 

2

02

DOSOS16 

4

04

EXTDOS 

5

05

DOSHUGE 

6

06

DOSDATA 

86

56

OTHEROS 

98

62

UNIXOS 

99

63

size

Use one of the following values:

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

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


    x86 only –

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


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


    x86 only –

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


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

filesys Profile Keyword (Mounting Remote File Systems)

filesys server:path server_address mount_pt_name mount_options

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

server

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

path

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

server_address

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

mount_pt_name

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

mount_options

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


Note –

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



Example 8–10 filsys Profile Keyword

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

filesys Profile Keyword (Creating Local File Systems)

filesys slice size file_system optional_parameters

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

slice

Use one of the following values:

any

The JumpStart program places the file system on any disk.


Note –

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


cwtxdysz or cxdysz

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

rootdisk.sn

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


Note –

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


size

Use one of the following values:

num

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

existing

The current size of the existing file system is used.


Note –

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


auto

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

all

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

free

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


Note –

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


start:size

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

file_system

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

mount_pt_name

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

swap

The specified slice is used as swap.

overlap

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


Note –

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


unnamed

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

ignore

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

optional_parameters

Use one of the following values:

preserve

The file system on the specified slice is preserved.


Note –

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


mount_options

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


Note –

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


filesys Profile Keyword (Creating RAID-1 Volumes)

filesys mirror[:name]slice [slice] size file_system optional_parameters

By using the filesys mirror keywords with the values that are listed, the JumpStart program creates the RAID-1 and RAID-0 volumes that are necessary to create a mirrored file system. You can specify filesys mirror more than once to create RAID-1 volumes (mirrors) for different file systems.


Note –

The filesys mirror keyword is only supported for initial installations.


name

This optional keyword enables you to name the RAID-1 volume (mirror). Mirror names must start with the letter “d”, followed by a number between 0 and 127, for example, d100. If you do not specify a mirror name, the custom JumpStart program assigns a mirror name for you. For guidelines about how to name mirrors, see RAID Volume Name Requirements and Guidelines for Custom JumpStart and Solaris Live Upgrade in Solaris 10 8/07 Installation Guide: Planning for Installation and Upgrade.

slice

This value specifies the disk slice where the custom JumpStart program places the file system you want to duplicate. The slice value must follow the format cwtxdysz, for example c0t0d0s0 or c0t0d0s5. The custom JumpStart program creates a RAID-0 volume (single-slice concatenation) on the slice, and creates a RAID-1 volume to mirror the concatenation. You can specify up to two slices for two RAID-0 volumes.

size

This value specifies the size, in Mbytes, of the file system.

file_system

This value specifies the file system that you are duplicating. The custom JumpStart program creates the RAID-1 volume from the slices that are specified and mounts the RAID-1 volume on the specified file system. In addition to critical file systems, such as root (/), /usr, and /var, you can also specify swap as the file system.

optional_parameters

One or more mount options, which is the same as the -o option of the mount(1M) command. The mount options are added to the /etc/vfstab entry for the specified file_system. If you need to specify more than one mount option, the mount options must be separated by commas and no spaces, for example, ro,quota.

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

forced_deployment Profile Keyword (Installing Solaris Flash Differential Archives)

forced_deployment 

forced_deployment forces the installation of a Solaris Flash differential archive onto a clone system that is different than the software expects.


Caution – Caution –

If you use forced_deployment, all new files are deleted to bring the clone system to the expected state. If you are not certain that you want files deleted, use the default, which protects new files by stopping the installation.


geo Profile Keyword

geo region

geo designates the regional locale or locales that you want to install on a system or to add when upgrading a system. region designates a geographical area that contains the locales that you want to install. Values you can specify for region are listed in the following table.

Value 

Description 

N_Africa

Northern Africa, including Egypt 

C_America

Central America, including Costa Rica, El Salvador, Guatemala, Mexico, Nicaragua, Panama 

N_America

North America, including Canada, United States 

S_America

South America, including Argentina, Bolivia, Brazil, Chile, Colombia, Ecuador, Paraguay, Peru, Uruguay, Venezuela 

Asia

Asia, including Japan, Republic of Korea, People's Republic of China, Taiwan, Thailand 

Ausi

Australasia, including Australia, New Zealand 

C_Europe

Central Europe, including Austria, Czech Republic, Germany, Hungary, Poland, Slovakia, Switzerland 

E_Europe

Eastern Europe, including Albania, Bosnia, Bulgaria, Croatia, Estonia, Latvia, Lithuania, Macedonia, Romania, Russia, Serbia, Slovenia, Turkey 

N_Europe

Northern Europe, including Denmark, Finland, Iceland, Norway, Sweden 

S_Europe

Southern Europe, including Greece, Italy, Portugal, Spain 

W_Europe

Western Europe, including Belgium, France, Great Britain, Ireland, Netherlands 

M_East

Middle East, including Israel 

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


Note –

You can specify a geo keyword for each locale you need to add to a system.


install_type Profile Keyword

install_type initial_upgrade_flash_switch

install_type defines whether to erase and install a new Solaris OS on a system, upgrade the existing Solaris OS on a system, or install a Solaris Flash archive on the system.


Note –

You must specify install_type in a profile, and install_type must be the first profile keyword in every profile.


You must use one of the following options for the initial_upgrade_flash_switch:

initial_install

Specifies to perform an initial installation of the Solaris OS

upgrade

Specifies to perform an upgrade of the Solaris OS

flash_install

Specifies to install a Solaris Flash archive that overwrites all files

flash_update

Specifies to install a Solaris Flash differential archive that overwrites only the files that are specified


Note –

Some profile keywords can only be used with the initial_install option. Some profile keywords can only be used with the upgrade option. Some profile keywords can only be used with the flash_install option.


layout_constraint Profile Keyword

layout_constraint slice constraint minimum_size

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

Limitation 

Description 

This keyword is used only with upgrade option. 

You can use layout_constraint only for the upgrade option when you need to reallocate disk space.

If you do not specify the layout_constraint keyword

The JumpStart program lays out the disk as follows: 

  • File systems that require more space for the upgrade are marked changeable.

  • File systems that are on the same disk as the file system that requires more space and that are mounted by the /etc/vfstab file are marked changeable.

  • Remaining file systems are marked fixed because auto-layout cannot change the file systems.

If you specify one or more layout_constraint keywords

The JumpStart program lays out the disk as follows: 

  • File systems that require more space for the upgrade are marked changeable.

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

  • The remaining file systems are marked fixed.

If the file system is not marked changeable 

You cannot change the constraint on file systems that require more space for the upgrade because the file systems must be marked changeable. You can use the layout_constraint keyword to change the minimum_size values on file systems that require more space for the upgrade.

If file systems require more space for upgrade 

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

slice

Specifies the file system's disk slice on which to specify the constraint. You must specify the system's disk slice in the form cwtxdysz or cxdysz.

constraint

Use one of the following constraints for the specified file system:

changeable

Auto-layout can move the file system to another location and it can change the file system size. The changeable constraint can only be specified on file systems that are mounted by the /etc/vfstab file. You can change the file system's size by specifying the minimum_size value.

When you mark a file system as changeable and minimum_size is not specified, the file system's minimum size is set to 10 percent more than the minimum size that is required. For example, if the minimum size for a file system is 100 Mbytes, the changed size is 110 Mbytes. If minimum_size is specified, any free space that remains, original size minus minimum size, is used for other file systems.

movable

Auto-layout can move the file system to another slice on the same disk or different disk. The file system size remains the same.

available

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

collapse

Auto-layout moves and collapses the specified file system into the parent file system. You can use the collapse option to reduce the number of file systems on a system as part of the upgrade. For example, if a system has the /usr and /usr/share file systems, collapsing the /usr/share file system moves the file system into /usr, the parent file system. You can specify the collapse constraint only on file systems that are mounted by the /etc/vfstab file.

minimum_size

Specifies the size of the file system after auto-layout reallocates space. The minimum_size option enables you to change the size of a file system. The size of the file system might be larger if unallocated space is added to the file system. But, the size is never less than the value you specify. The minimum_size value is optional. Use this value only if you have marked a file system as changeable and the minimum size cannot be less than what the file system needs for the existing file system contents.


Example 8–11 layout_constraint Profile Keyword

layout_constraint c0t3d0s1 changeable 200

layout_constraint c0t3d0s4 movable

layout_constraint c0t3d1s3 available

layout_constraint c0t2d0s1 collapse

local_customization Profile Keyword (Installing Solaris Flash Archives)

local_customization local_directory

Before you install a Solaris Flash archive on a clone system, you can create custom scripts to preserve local configurations on the clone system. The local_customization keyword designates the directory where you have stored these scripts. local_directory is the path to the script on the clone system.

For information about predeployment and postdeployment scripts, see Creating Customization Scripts in Solaris 10 8/07 Installation Guide: Solaris Flash Archives (Creation and Installation).

locale Profile Keyword

locale locale_name

Note –

You can use locale with both the initial installation and upgrade options.


locale designates the locale packages you want to install or add when upgrading for the specified locale_name. The locale_name values are the same as those values that are used for the $LANG environment variable. International Language Environments Guide contains a list of valid locale values.

When you use the locale keyword, consider the following:

metadb Profile Keyword (Creating State Database Replicas)

metadb slice [size size-in-blocks] [count number-of-replicas]

The metadb keyword enables you to create Solaris Volume Manager state database replicas (mediates) during your custom JumpStart installation. You can use the metadb keyword multiple times in your profile file to create state database replicas on different disk slices.

slice

You must specify the disk slice on which you want the custom JumpStart program to place the state database replica. The slice value must follow the format cwtxdysz.

size size-in-blocks

The size optional keyword enables you to specify the size, in blocks, of the state database replica to be created. If you do not specify a size value, the custom JumpStart program uses a default size of 8192 blocks for the state database replica.

count number-of-replicas

You can specify the number of state database replicas you are creating by setting the optional count keyword value in your profile. If you do not specify a count value, the custom JumpStart program creates three state database replicas by default.

For more information about creating Solaris Volume Manager state database replicas during your installation, see State Database Replicas Guidelines and Requirements in Solaris 10 8/07 Installation Guide: Planning for Installation and Upgrade.

no_content_check Profile Keyword (Installing Solaris Flash Archives)

no_content_check

When installing a clone system with a Solaris Flash differential archive, you can use the no_content_check keyword to ignore file-by-file validation. File-by-file validation ensures that the clone system is a duplicate of the master system. Avoid using this keyword unless you are sure the clone system is a duplicate of the original master system.


Caution – Caution –

If you use no_content_check, all new files are deleted to bring the clone system to the expected state. If you are not certain that you want files deleted, use the default, which protects new files by stopping the installation.


For information about installing Solaris Flash differential archives, see To Prepare to Install a Solaris Flash Archive With a Custom JumpStart Installation.

no_master_check Profile Keyword (Installing Solaris Flash Archives)

no_master_check

When installing a clone system with a Solaris Flash differential archive, you can use the no_master_check keyword to ignore checking the clone system to make sure it was built from the original master system. Avoid using this keyword unless you are sure the clone system is a duplicate of the original master system.

For information about installing Solaris Flash differential archives, see To Prepare to Install a Solaris Flash Archive With a Custom JumpStart Installation.

num_clients Profile Keyword

num_clients client_num

When a server is installed, space is allocated for each diskless client's root (/) and swap file systems. num_clients defines the number of diskless clients, client_num, that a server supports. If you do not specify num_clients in the profile, five diskless clients are allocated by default.


Note –

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


package Profile Keyword

package package_name [add [retrieval_type location]| delete]

You can use package with both the initial installation and upgrade options. The package keyword enables you to do the following:

package_name

Specifies the package name in the form SUNWname. To view detailed information about packages and their names, on an installed system, use the pkginfo -l command.

add | delete

Specifies to add or remove the specified package. If you do not specify add or delete, add is used by default.


Note –

You can add more than one package by adding another package entry to the profile and omitting the location. The location of the previous package is used for all subsequent packages if the location is left blank.


[retrieval_type location]

Specifies the addition of a package or packages that are located outside the Solaris distribution that is being installed. The values of retrieval_type and location depend on where the package is stored. The following sections contain the values you can use for retrieval_type and location and examples of how to use the package_name keyword.

Packages Stored on an NFS Server

If the package is stored on an NFS server, use one of the following syntaxes for the package keyword.


package package_name add nfs server_name:/path [retry n]
package package_name add nfs://server_name:/path [retry n]
package_name

Specifies the package name in the form SUNWname. To view detailed information about packages and their names, on an installed system, use the pkginfo -l command.

server_name

Specifies the name of the server where you stored the package.

path

Specifies the location of the package directory on the specified server. If the path contains $HOST, $HOST is replaced with the name of the host system that you are installing.

retry n

Is an optional keyword. n is the maximum number of times the installation process attempts to mount the directory.


Example 8–12 Adding a Package by Using NFS

In this example, the package profile keyword adds the SUNWnew package from the NFS location nfs://golden/packages/Solaris_10/. If a mount fails, the NFS mount is tried five times.

package SUNWnew add nfs golden:/packages/Solaris_10 retry 5

Packages Stored on an HTTP Server

If the package is stored on an HTTP server, use one of the following syntaxes for the package keyword.


package package_name add http://server_name[:port] path optional_keywords
package package_name add http server_name[:port] path optional_keywords
package_name

Specifies the package name in the form SUNWname. To view detailed information about packages and their names, on an installed system, use the pkginfo -l command.

server_name

Specifies the name of the server where you stored the package.

port

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

If you do not specify a port, the default HTTP port number 80 is used.

path

Specifies the location of the package to be retrieved from the specified server. When using an HTTP server, the package must be in package datastream format.

optional_keywords

Specifies the optional keywords to use when you retrieve a package from an HTTP server.

Table 8–6 Optional package Keywords to Use With HTTP

Keyword 

Value Definition 

timeout min

The timeout keyword enables you to specify, in minutes, the maximum length of time that is allowed to pass without receipt of data from the HTTP server. If a timeout occurs, the connection is closed, reopened, and resumed. If you specify a timeout value of 0 (zero), the connection is not reopened.

If a timeout reconnection occurs, the package is retried from the beginning of the package and the data that was retrieved prior to the timeout is discarded. 

proxy host:port

The proxy keyword enables you to specify a proxy host and proxy port. You can use a proxy host to retrieve a Solaris package from the other side of a firewall. You must supply a proxy port when you specify the proxy keyword.


Example 8–13 Adding a Package by Using HTTP

In this example, the package profile keyword adds all the packages listed in the Solaris 10 directory from the HTTP location http://package.central/Solaris_10. If five minutes pass and no data is received, the package data is retrieved again. Previous package data is discarded. Either of the following formats can be used.

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


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

In this example, the package profile keyword adds all the packages listed in the Solaris_10 directory from the HTTP location http://package.central/Solaris_10. The package is retrieved across a firewall by using the proxy keyword.

package SUNWnew add http://package.central/Solaris_10 proxy webcache.east:8080

Packages Stored on a Local Device

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

package package_name add local_device device path file_system_type
package_name

Specifies the package name in the form SUNWname. To view detailed information about packages and their names, on an installed system, use the pkginfo -l command.

device

Specifies the name of the drive where the Solaris package resides. If the device name is a canonical path, the device is mounted directly. If you supply a device name that is not a canonical path, the installation utility adds /dev/dsk/ to the path.

path

Specifies the path to the Solaris package, relative to the root (/) file system on the device you specified.

file_system_type

Specifies the type of file system on the device. If you do not supply a file system type, the installation utility attempts to mount a UFS file system. If the UFS mount fails, the installation utility attempts to mount an HSFS file system.


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

In this example, the package profile keyword adds the SUNWnew package from the directory /Solaris_10/Product from the local device c0t6d0s0. This is a UFS file system.

package SUNWnew add local_device c0t6d0s0 /Solaris_10/Product ufs


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

In this example, the package profile keyword adds the SUNWnew package from the directory /Solaris_10/Product from the local device c0t6d0s0. This is an HSFS file system.

package SUNWnew add local_device c0t6d0s0 /Solaris_10/Product  hsfs

Packages Stored on a Local File

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


package package_name add local_file path 
package_name

Specifies the package name in the form SUNWname. To view detailed information about packages and their names, on an installed system, use the pkginfo -l command.

path

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


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

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

package SUNWnew add local_file /Solaris_10/Product

Limitations When Using the package Keyword

Note these limitations when using the package keyword:

Upgrade Behavior When Using the package Keyword

When you use package for an upgrade, the JumpStart program performs the following actions:

partitioning Profile Keyword

partitioning type

partitioning defines how the disks are divided into slices for file systems during the installation.

If you do not specify partitioning in the profile, the default type of partitioning is used by default.

type

Use one of the following values:

default

The JumpStart program selects the disks and creates the file systems on which to install the specified software, except for any file systems that are specified by the filesys keywords. rootdisk is selected first. The JumpStart program uses additional disks if the specified software does not fit on rootdisk.

existing

The JumpStart program uses the existing file systems on the system's disks. All file systems except /, /usr, /usr/openwin, /opt, and /var are preserved. The JumpStart program uses the last mount-point field from the file system superblock to determine which file-system mount point the slice represents.


Note –

When you use both the filesys and partitioning existing profile keywords, you must set size size to existing.


explicit

The JumpStart program uses the disks and creates the file systems that are specified by the filesys keywords. If you specify only the root (/) file system with the filesys keyword, all of the Solaris software is installed in the root (/) file system.


Note –

If you use the explicit profile value, you must use the filesys keyword to specify the disks to use and file systems to create.


patch Profile Keyword

patch patch_id_list | patch_file patch_location optional_keywords]
patch_id_list

Specifies the patch ID numbers that are to be installed. The list should be a list of comma-separated Solaris patch IDs. The patches are installed in the order specified in the list. Do not add a space after the comma, for example: 112467-01,112765-02.

patch_file

A file with a list of patches that is found in the patch_location. The patches are installed in the order specified in the file.

patch_location

Specifies the location where the patches reside. The locations allowed are the following:

  • NFS server

  • HTTP server

  • Local device

  • Local file

optional_keywords

Optional keywords depend on where patches are stored. The following sections describe the possible locations and optional keywords.

Patches Stored on an NFS Server

If the patch is stored on an NFS server, use one of the following syntaxes for the patch keyword.


patch patch_id_list | patch_file nfs server_name:/patch_directory [retry n]
patch patch_id_list | patch_file nfs://server_name/patch_director  [retry n]
patch_id_list

Specifies the patch ID numbers that are to be installed. The list should be a list of comma-separated Solaris patch IDs. The patches are installed in the order specified in the list.

patch_file

A file with a list of patches that is found in the patch_location. The patches are installed in the order specified in the file.

server_name

Specifies the name of the server where you stored the patches.

patch_directory

Specifies the location of the patch directory on the specified server. The patches must be in standard patch format.

retry n

Is an optional keyword. n is the maximum number of times the install utility attempts to mount the directory.


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

In this example, the patch profile keyword adds all the patches listed in the patch file from the NFS patch directory nfs://patch_master/Solaris/v10/patches. Patches are installed in the order listed in the patch. If a mount fails, the NFS mount is tried five times.

patch patch_file nfs://patch_master/Solaris/v10/patches retry 5


Example 8–19 Adding a Patch by Using NFS

In this example, the patch profile keyword adds the patches 112467–01 and 112765–02 from the patch directory /Solaris/v10/patches on the server patch_master.

patch 112467-01,112765-02 nfs patch_master:/Solaris/v10/patches

Patches Stored on an HTTP Server

If the patch is stored on an HTTP server, use one of the following syntaxes for the patch keyword.


patch  patch_id_list | patch_file http://server_name [:port] patch_directory optional_http_keywords

patch  patch_id_list | patch_file http server_name [:port] patch_directory optional_http_keywords
patch_id_list

Specifies the patch ID numbers that are to be installed. The list should be a list of comma-separated Solaris patch IDs. The patches are installed in the order specified in the list. Do not add a space after the comma, for example: 112467-01,112765-02.

patch_file

A file with a list of patches that is found in the patch_location. The patches are installed in the order specified in the file.

server_name

Specifies the name of the server where you stored the patch.

port

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

If you do not specify a port, the default HTTP port number 80 is used.

patch_directory

Specifies the location of the patch directory to be retrieved from the specified server. When using an HTTP server, the patch must be in JAR format.

optional_keywords

Specifies the optional keywords to use when you retrieve a patch from an HTTP server.

Table 8–7 Optional patch Keywords to Use With HTTP

Keyword 

Value Definition 

timeout min

The timeout keyword enables you to specify, in minutes, the maximum length of time that is allowed to pass without receipt of data from the HTTP server. If a timeout occurs, the connection is closed, reopened, and resumed. If you specify a timeout value of 0 (zero), the connection is not reopened.

If a timeout reconnection occurs, the package is retried from the beginning of the package and the data that was retrieved prior to the timeout is discarded. 

proxy host:port

The proxy keyword enables you to specify a proxy host and proxy port. You can use a proxy host to retrieve a Solaris package from the other side of a firewall. You must supply a proxy port when you specify the proxy keyword.


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

In this example, the patch profile keyword adds all the patches listed in the patch_file file from the HTTP location http://patch.central/Solaris/v10/patches. The patches are installed in the order specified in the file the patch file. If five minutes pass and no data is received, the patch data is retrieved again. Previous patch data is discarded.

patch patch_file http://patch.central/Solaris/v10/patches timeout 5


Example 8–21 Adding a Patch by Using HTTP

In this example, the patch profile keyword entry adds the patches 112467–01 and 112765–02 from the patch location http://patch_master/Solaris/v10/patches.

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

Patches Stored on a Local Device

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


patch patch_id_list | patch_file local_device \
device path file_system_type
patch_id_list

Specifies the patch ID numbers that are to be installed. The list should be a list of comma-separated Solaris patch IDs. The patches are installed in the order specified in the list. Do not add a space after the comma, for example: 112467-01,112765-02.

patch_file

A file with a list of patches that is found in the patch_location. The patches are installed in the order specified in the file.

device

Specifies the name of the drive where the Solaris package resides. If the device name is a canonical path, the device is mounted directly. If you supply a device name that is not a canonical path, the installation utility adds /dev/dsk/ to the path.

path

Specifies the path to the Solaris patch, relative to the root (/) file system on the device you specified.

file_system_type

Specifies the type of file system on the device. If you do not supply a file system type, the installation utility attempts to mount a UFS file system. If the UFS mount fails, the installation utility attempts to mount an HSFS file system.


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

In this example, the patch profile keyword adds all the patches listed in the patch_file file from the directory /Solaris_10/patches from the local device c0t6d0s0. The patch file determines the order of patches to be installed.

patch patch_file c0t6d0s0 /Solaris_10/patches


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

In this example, the patch profile keyword adds the patches 112467–01 and 112765–02 from the patch directory /Solaris_10/patches from local device c0t6d0s0.

patch 112467-01,112765-02 local_device c0t6d0s0 /Solaris_10/patches

Patches Stored on a Local File

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

patch patch_id_list | patch_file local_file patch _directory 
patch_id_list

Specifies the patch ID numbers that are to be installed. The list should be a list of comma-separated Solaris patch IDs. The patches are installed in the order specified in the list. Do not add a space after the comma, for example: 112467-01,112765-02.

patch_file

A file with a list of patches that is found in the patch_location. The patches are installed in the order specified in the file.

patch_directory

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


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

In this example, the patch profile keyword adds all the patches that are listed in the patch_file file from the /Solaris_10/patches directory. The patch file determines the order of patches to be installed.

patch patch_cal_file /Solaris_10/patches


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

In this example, the patch profile keyword adds the patches 112467–01 and 112765–02 from the patch directory /Solaris_10/patches.

patch 112467-01,112765-02 local_file /Solaris_10/patches

Limitations When Using the patch Keyword

Note the following limitations when using the patch keyword:

root_device Profile Keyword

root_device slice

root_device designates the system's root disk. How the System's Root Disk Is Determined contains additional information.


Note –

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


When you are upgrading a system, root_device designates the root (/) file system and the file systems that are mounted by its /etc/vfstab file to be upgraded. You must specify root_device if more than one root (/) file system can be upgraded on a system. You must specify slice in the form cwtxdysz or cxdysz.

When you use the root_device keyword, consider the following:


Example 8–26 root_device Profile Keyword

root_device c0t0d0s2

How the System's Root Disk Is Determined

A system's root disk is the disk on the system that contains the root (/) file system. In a profile, you can use the rootdisk variable in place of a disk name, which the JumpStart program sets to the system's root disk. Table 8–8 describes how the JumpStart program determines the system's root disk for the installation.


Note –

The JumpStart program only determines a system's root disk size during an initial installation. You cannot change a system's root disk during an upgrade.


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

Stage 

Action 

If the root_device keyword is specified in the profile, the JumpStart program sets rootdisk to the root device.

If rootdisk is not set and the boot_device keyword is specified in the profile, the JumpStart program sets rootdisk to the boot device.

If rootdisk is not set and a filesys cwtxdysz size / entry is specified in the profile, the JumpStart program sets rootdisk to the disk that is specified in the entry.

If rootdisk is not set and a rootdisk.sn entry is specified in the profile, the JumpStart program searches the system's disks in kernel probe order for an existing root file system on the specified slice. If a disk is found, the JumpStart program sets rootdisk to the found disk.

If rootdisk is not set and partitioning existing is specified in the profile, the JumpStart program searches the system's disks in kernel probe order for an existing root file system. If a root file system is not found or more than one is found, an error occurs. If a root file system is found, the JumpStart program sets rootdisk to the found disk.

If rootdisk is not set, the JumpStart program sets rootdisk to the disk where the root (/) file system is installed.

system_type Profile Keyword

system_type type_switch

system_type defines the type of system on which the Solaris OS is to be installed.

type_switch represents the option standalone or server, which you use to indicate the type of system on which the Solaris software is to be installed. If you do not specify system_type in a profile, standalone is used by default.

usedisk Profile Keyword

usedisk disk_name ...

By default, the JumpStart program uses all of the operational disks on the system when you specify partitioning default. The usedisk profile keyword designates one or more disks that you want the JumpStart program to use. You must specify disk_name in the form cxtydz or cydz, for example, c0t0d0 or c0d0s0.

If you specify usedisk in a profile, the JumpStart program uses only the disks that you specify after the usedisk keyword.


Note –

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


Custom JumpStart Environment Variables

You can use environment variables in your begin and finish scripts. For example, a begin script might extract the disk size, SI_DISKSIZES, and install or not install particular packages on a system, based on the actual disk size the script extracts.

Information that is gathered about a system is stored in these environment variables, which are generally set or not, depending on the rule keywords and values you use in the rules file.

For example, information about which operating system is already installed on a system is only available in SI_INSTALLED after the installed keyword is used.

Table 8–9 describes these variables and their values.

Table 8–9 Installation Environment Variables

Environment Variable 

Value 

SI_ARCH

The hardware architecture of the install client. The SI_ARCH variable is set when the arch keyword is used in the rules file.

SI_BEGIN

The name of the begin script, if one is used. 

SI_CLASS

The name of the profile that is used to install the install client. 

SI_DISKLIST

A comma-separated list of disk names on the install client. The SI_DISKLIST variable is set when the disksize keyword is used and matched in the rules file. The SI_DISKLIST and SI_NUMDISKS variables are used to determine the physical disk to use for the rootdisk. rootdisk is described in How the System's Root Disk Is Determined.

SI_DISKSIZES

A comma-separated list of disk sizes on the install client. The SI_DISKSIZES variable is set when the disksize keyword is used and matched in the rules file.

SI_DOMAINNAME

The domain name. The SI_DOMAINNAME variable is set when the dommainname keyword is used and matched in the rules file.

SI_FINISH

The name of the finish script, if one is used. 

SI_HOSTADDRESS

The install client's IP address. 

SI_HOSTNAME

The install client's host name. The SI_HOSTNAME variable is set when the hostname keyword is used and matched in the rules file.

SI_INSTALLED

The device name of a disk with a specific operating system on the disk, for example, Solaris, SunOS, or System V. The SI_INSTALLED variable is set when the installed keyword is used and matched in the rules file. SI_INST_OS and SI_INST_VER are used to determine the value of SI_INSTALLED.

SI_INST_OS

The name of the operating system. SI_INST_OS and SI_INST_VER are used to determine the value of SI_INSTALLED.

SI_INST_VER

The version of the operating system. SI_INST_OS and SI_INST_VER are used to determine the value of SI_INSTALLED.

SI_KARCH

The install client's kernel architecture. The SI_KARCH variable is set when the karch keyword is used and matched in the rules file.

SI_MEMSIZE

The amount of physical memory on the install client. The SI_MEMSIZE variable is set when the memsize keyword is used and matched in the rules file.

SI_MODEL

The install client's model name. The SI_MODEL variable is set when the model keyword is used and matched in the rules file.

SI_NETWORK

The install client's network number. The SI_NETWORK variable is set when the network keyword is used and matched in the rules file.

SI_NUMDISKS

The number of disks on an install client. The SI_NUMDISKS variable is set when the disksize keyword is used and matched in the rules file. The SI_NUMDISKS and SI_DISKLIST variables are used to determine the physical disk to use for the rootdisk. rootdisk is described in How the System's Root Disk Is Determined.

SI_OSNAME

The operating system release on the Solaris software image. For example, you can use the SI_OSNAME variable in a script if you are installing the Solaris software on systems that are based on the version of the operating system on the Solaris Operating System DVD or the Solaris Software - 1 CD image.

SI_ROOTDISK

The device name of the disk that is represented by the logical name rootdisk. The SI_ROOTDISK variable is set when the disksize or the installed keyword is set to rootdisk in the rules file. The SI_ROOTDISK variable sets the device to boot from during the installation.


Note –

You cannot set the place of installation by using the probe keyword “rootdisk” in the rules file. For information on the "rootdisk" variable that is set in a JumpStart profile, see How the System's Root Disk Is Determined.


SI_ROOTDISKSIZE

The size of the disk that is represented by the logical name rootdisk. The SI_ROOTDISKSIZE variable is set when the disksize or the installed keyword is set to rootdisk in the rules file.

SI_TOTALDISK

The total amount of disk space on the install client. The SI_TOTALDISK variable is set when the totaldisk keyword is used and matched in the rules file.

Probe Keywords and Values

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


Note –

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


Table 8–10 Descriptions of Probe Keywords

Rule Keyword 

Equivalent Probe Keyword 

Description of Probe Keyword 

any

None  

 

arch

arch

Determines the kernel architecture, i386 or SPARC, and sets SI_ARCH.

disksize

disks

Returns the size of a system's disks in Mbytes in kernel probe order, c0t3d0s0, c0t3d0s1, c0t4d0s0. disksize sets SI_DISKLIST, SI_DISKSIZES, SI_NUMDISKS, and SI_TOTALDISK.

domainname

domainname

Returns a system's NIS or NIS+ domain name or blank and sets SI_DOMAINNAME. The domainname keyword returns the output of domainname(1M).

hostaddress

hostaddress

Returns a system's IP address, the first address that is listed in the output of ifconfig(1M) -a that is not lo0, and sets SI_HOSTADDRESS.

hostname

hostname

Returns a system's host name that is the output from uname(1) -n and sets SI_HOSTNAME.

installed

installed

Returns the version name of the Solaris OS that is installed on a system and sets SI_ROOTDISK and SI_INSTALLED.

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

karch

karch

Returns a system's platform group, for example i86pc or sun4u, and sets SI_KARCH. For a list of platform names, see Solaris Sun Hardware Platform Guide at http://docs.sun.com.

memsize

memsize

Returns the size of physical memory on a system in Mbytes and sets SI_MEMSIZE.

model

model

Returns a system's platform name and sets SI_MODEL. For a list of platform names, see the Solaris Sun Hardware Platform Guide at http://docs.sun.com.

network

network

Returns a system's network number, which the JumpStart program determines by performing a logical AND between the system's IP address and the subnet mask. The system's IP address and the subnet mask are extracted from the first address that is listed in the output of ifconfig(1M) -a that is not lo0. The network keyword sets SI_NETWORK.

osname

osname

Returns the version and operating system name of the Solaris OS that is found on a CD and sets SI_OSNAME.

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

  

rootdisk

Returns the name and size in Mbytes of a system's root disk and sets SI_ROOTDISK.

totaldisk

totaldisk

Returns the total disk space on a system (in Mbytes) and sets SI_TOTALDISK. The total disk space includes all of the operational disks that are attached to a system.