|
|
JumpStartObjectives: Explain custom JumpStart configuration, including the boot, identification, configuration, and installation services.
There are two versions of JumpStart: JumpStart and custom JumpStart. JumpStart lets you automatically install the Solaris software on a SPARC-based system just by inserting the Solaris CD and powering on the system. You do not need to specify the boot command at the ok prompt. The software that is installed is specified by a default class file that is chosen based on the system's model and the size of its disks; you can't choose the software that is installed. For new SPARC systems shipped from Sun, this is the default method of installing the operating system when you first power on the system. The custom JumpStart method of installing the operating system provides a way to install groups of similar systems automatically and identically. If you use the interactive method to install the operating system, you must interact with the installation program by answering various questions. At a large site with several systems that are to be configured exactly the same, this task can be monotonous and time consuming. In addition, there is no guarantee that each system is set up the same. Custom JumpStart solves this problem by providing a method to create sets of configuration files beforehand so that the installation process can use them to configure each system automatically. Custom JumpStart requires up-front work, creating custom configuration files before the systems can be installed, but it's the most efficient way to centralize and automate the operating system installation at large enterprise sites. Custom JumpStart can be set up to be completely hands off. The custom configuration files that need to be created for JumpStart are the rules and class files. Both of these files consist of several keywords and values and are described in this chapter. Another file that is introduced in this chapter is the sysidcfg file, which can be used to preconfigure the system identification information and achieve a fully hands-off installation. Table 14.1 lists the various commands that are introduced in this chapter. There are three main components to JumpStart:
Note Server Configurations At times we describe the boot server, the install server, and the configuration server as though they are three separate systems. The reality, however, is that most sites will have one system that performs all three functions. This is described in more detail in the section "The Install Server," later in this chapter. Each of these components is described in this chapter. If any of these three components is improperly configured, the JumpStart clients can
Preparing for a Custom JumpStart InstallationThe first step in preparing a custom JumpStart installation is to decide how you want the systems at your site to be installed. Here are some questions that need to be answered before you begin:
These questions will help you group the systems when you create the class and rules files later in this chapter. Additional concerns to be addressed include what software packages need to be installed and what size the disk partitions need to be in order to accommodate the software. After you answer these questions, group systems according to their configuration (as shown in the example of a custom JumpStart near the end of this chapter). The next step in preparing a custom JumpStart installation is to create the configuration files that will be used during the installation: the rules.ok file (a validated rules file) and a class file for each group of systems. The rules.ok file is a file that should contain a rule for each group of systems you want to install. Each rule distinguishes a group of systems based on one or more system attributes. The rule links each group to a class file, which is a text file that defines how the Solaris software is to be installed on each system in the group. Both the rules.ok file and the class files must be located in a JumpStart directory that you define. The custom JumpStart configuration files that you need to set up can be located on either a diskette (called a configuration diskette) or a server (called a configuration server). Use a configuration diskette when you want to perform custom JumpStart installations on non-networked standalone systems. Use a configuration server when you want to perform custom JumpStart installations on networked systems that have access to the server. This chapter covers both procedures. What Happens During a Custom JumpStart Installation?This section provides a quick overview of what takes place during a custom JumpStart installation. Each step is described in detail in this chapter. To prepare for the installation, you create a set of JumpStart configuration files, the rules and class files, on a server that is located on the same network as the client you are installing. Next, you set up the server to provide a startup kernel that is passed to the client across the network. This is called the boot server (or sometimes it is referred to as the startup server). After the client starts up, the boot server directs the client to the JumpStart directory, which is usually located on the boot server. The configuration files in the JumpStart directory direct and automate the entire Solaris installation on the client. To be able to start up and install the operating system on a client, you need to set up three servers: a boot server, an install server, and a configuration server. These can be three separate servers; however, in most cases, one server provides all of these services. The Boot ServerThe boot server, also called the startup server, is where the client systems access the startup files. This server must be on the local subnet (not across routers). Though it is possible to install systems over the network that are not on the same subnet as the install server, there must be a boot server that resides on the same subnet as the client. When a client is first turned on, it does not have an operating system installed or an IP address assigned; therefore, when the client is first started, the boot server provides this information. The boot server running the RARP (Reverse Address Resolution Protocol) daemon, in.rarpd, looks up the Ethernet address in the /etc/ethers file, checks for a corresponding name in its /etc/hosts file, and passes the Internet address back to the client. Note Check rarpd Daemon rarpd is a daemon that is not always running. The inetd daemon is the network listener that starts rarpd automatically whenever a request is made. A corresponding entry for rarpd should exist in inetd.conf. RARP is a method by which a client is assigned an IP address based on a lookup of its Ethernet address. After supplying an IP address, the server searches the /tftpboot directory for a symbolic link named for the client's IP address expressed in hexadecimal format. This link points to a boot program for a particular Solaris release and client architecture. For SPARC systems, the file name is <hex-IP address.architecture>, for example: C009C864.SUN4U -> inetboot.sun4u.Solaris_10-1 The boot server uses the in.tftpd daemon to transmit the boot program to the client via trivial file transfer protocol (TFTP). The client runs this boot program to start up. The boot program tries to mount the root file system. To do so, it issues the whoami request to discover the client's hostname. The boot server running the boot parameter daemon, rpc.bootparamd, looks up the hostname and responds to the client. The boot program then issues a getfile request to obtain the location of the client's root and swap space. The boot server responds with the information obtained from the /etc/bootparams file. Once the client has its boot parameters, the boot program on the client mounts the / (root) file system from the boot server. The client loads its kernel and starts the init program. When the boot server is finished bootstrapping the client, it redirects the client to the configuration server. The client searches for the configuration server using the bootparams information. The client mounts the configuration directory and runs sysidtool. The client then uses the bootparams information to locate and mount the installation directory where the Solaris image resides. The client then runs the suninstall program and installs the operating system. For boot operations to proceed, the following files and directories must be properly configured on the boot server: The following sections describe each file. /etc/ethersWhen the JumpStart client boots, it has no IP address, so it broadcasts its Ethernet address to the network using RARP. The boot server receives this request and attempts to match the client's Ethernet address with an entry in the local /etc/ethers file. If a match is found, the client name is matched to an entry in the /etc/hosts file. In response to the RARP request from the client, the boot server sends the IP address from the /etc/hosts file back to the client. The client continues the boot process using the assigned IP address. An entry for the JumpStart client must be created by editing the /etc/ethers file or using the add_install_client script described later in this chapter in the section titled "Setting Up Clients." /etc/hostsThe /etc/hosts file was described in Chapter 8, "The Solaris Network Environment." The /etc/hosts file is the local file that associates the names of hosts with their IP addresses. The boot server references this file when trying to match an entry from the local /etc/ethers file in response to a RARP request from a client. In a name service environment, this file would be controlled by NIS. See Chapter 12, "Naming Services," for more information on how this file can be managed by NIS. /etc/dfs/dfstabThe /etc/dfs/dfstab file lists local file systems to be shared to the network. This file is described in detail in Chapter 9, "Virtual File Systems, Swap, and Core Dumps." /etc/bootparamsThe /etc/bootparams file contains entries that network clients use for booting. JumpStart clients retrieve the information from this file by issuing requests to a server running the rpc.bootparamd program. See the section titled "Setting Up Clients" later in this chapter for more information on how this file is configured. /tftpboot/tftpboot is a directory that contains the inetboot.SUN4x.Solaris_10-1 file that is created for each JumpStart client when the add_install_client script is run. The client's IP address is expressed in hexadecimal format. This link points to a boot program for a particular Solaris release and client architecture. When booting over the network, the JumpStart client's boot PROM makes a RARP request, and when it receives a reply, the PROM broadcasts a TFTP request to fetch the inetboot file from any server that responds and executes it. See how this directory is configured in the section titled "Setting Up Clients." Setting Up the Boot ServerThe boot server is set up to answer RARP requests from clients using the add_install_client command. Before a client can start up from a boot server, the setup_install_server command is used to set up the boot server. If the same server is going to be used as a boot server and an install server, proceed to the next section titled "The Install Server." To setup the boot server, follow the steps in Step by Step 14.1. Note Booting on a Separate Subnet Normally, the install server also provides the boot program for booting clients. However, the Solaris network booting architecture requires you to set up a separate boot server when the install client is on a different subnet than the install server. Here's the reason: SPARC install clients require a boot server when they exist on different subnets because the network booting architecture uses the reverse address resolution protocol (RARP). When a client boots, it issues a RARP request to obtain its IP address. RARP, however does not acquire the netmask number, which is required to communicate across a router on a network. If the boot server exists across a router, the boot will fail because the network traffic cannot be routed correctly without a netmask. Note Insufficient Disk Space The following error indicates that there is not enough room in the directory to install the necessary files. You'll need to either clean up files in that file system to make more room or choose a different file system: ERROR: Insufficient space to copy Install Boot image 362978 necessary -69372 available. Note Destination Must Be Empty The location in which you are trying to create the boot server must be empty. You'll see the following error if the target directory is not empty: The target directory /export/jumpstart is not empty. Please choose\ an empty directory or remove all files from the specified\ directory and run this program again. If no errors are displayed, the boot server is now set up. This boot server will handle all boot requests on this subnet. A client can only boot to a boot server located on its subnet. If you have JumpStart clients on other subnets, you'll need to create a boot server for each of those subnets. The installation program will create a subdirectory named Solaris_10 in the <boot_dir_path> directory. The Install ServerAs explained in the previous section, the boot server and the install server are typically the same system. The exception is when the client on which Solaris 10 is to be installed is located on a different subnet than the install server. Then a boot server is required on that subnet. The install server is a networked system that provides Solaris 10 CD images (or a single DVD image) from which you can install Solaris 10 on another system on the network. You can create an install server by copying the images on the Solaris installation media onto the server's hard disk. This chapter focuses on using CD images, but you should be aware that Solaris 10 is also available on a single DVD. By copying these CD images to the server's hard disk, you enable a single install server to provide Solaris 10 CD images for multiple releases, including Solaris 10 CD images for different platforms. For example, a SPARC install server could provide the following:
To set up a server as a boot and installer server, complete Step by Step 14.2. This Step by Step assumes that all systems are on the same subnet, and the boot and install server are to be on the same system.
The Configuration ServerIf you are setting up custom JumpStart installations for systems on the network, you have to create a directory on a server called a configuration directory. This directory contains all the essential custom JumpStart configuration files, such as the rules file, the rules.ok file, the class file, the check script, and the optional begin and finish scripts. The server that contains a JumpStart configuration directory is called a configuration server. It is usually the same system as the install and boot server, although it can be a completely different server. The configuration directory on the configuration server should be owned by root and should have permissions set to 755. To set up the configuration server, follow Step by Step 14.3.
You can also use the add_install_client script, which makes an entry into the /etc/dfs/dfstab file as part of the script. The add_install_client script is described in the section titled "Setting Up Clients." Setting Up a Configuration DisketteAn alternative to setting up a configuration server is to create a configuration diskette (provided that the systems that are to be installed have diskette drives). If you use a diskette for custom JumpStart installations, the essential custom JumpStart files (the rules file, the rules.ok file, and the class files) must reside in the root directory on the diskette. The diskette that contains JumpStart files is called a configuration diskette. The custom JumpStart files on the diskette should be owned by root and should have permissions set to 755. See Step by Step 14.4 to set up a configuration disk.
You have completed the creation of a disk that can be used as a configuration disk. Now you can create the rules file and create class files on the configuration disk to perform custom JumpStart installations. The Rules FileThe rules file is a text file that should contain a rule for each group of systems you want to install automatically. Each rule distinguishes a group of systems based on one or more system attributes and links each group to a class file, which is a text file that defines how the Solaris software is installed on each system in the group. After deciding how you want each group of systems at your site to be installed, you need to create a rules file for each specific group of systems to be installed. The rules.ok file is a validated version of the rules file that the Solaris installation program uses to perform a custom JumpStart installation. After you create the rules file, validate it with the check script by changing to the /export/jumpstart directory and issuing the check command. If the check script runs successfully, it creates the rules.ok file. During a custom JumpStart installation, the Solaris installation program reads the rules.ok file and tries to find the first rule that has a system attribute matching the system being installed. If a match occurs, the installation program uses the class file specified in the rule to install the system. A sample rules file for a Sun Ultra is shown next. You'll find a sample rules file on the install server located in the <install_dir_path>/Solaris_10/Misc/jumpstart_sample directory, where <install_dir_path> is the directory that was specified using the setup_install_server script when the install server was set up. For the examples in this chapter, the install directory is /export/install/sparc_10. Notice that almost all the lines in the file are commented out. These are simply instructions and sample entries to help the system administrator make the correct entry. The last, uncommented line is the rule we added for the example. The syntax is discussed later in this chapter. Each line in the code table has a rule keyword and a valid value for that keyword. The Solaris installation program scans the rules file from top to bottom. If the program matches an uncommented rule keyword and value with a known system, it installs the Solaris software specified by the class file listed in the class file field. Following is the sample rules file: # # @(#)rules 1.12 94/07/27 SMI # # The rules file is a text file used to create the rules.ok file for # a custom JumpStart installation. The rules file is a lookup table # consisting of one or more rules that define matches between system # attributes and profiles. # # This example rules file contains: # o syntax of a rule used in the rules file # o rule_keyword and rule_value descriptions # o rule examples # # See the installation manual for a complete description of the rules file # # ########################################################################## # # RULE SYNTAX: # # [!]rule_keyword rule_value [&& [!]rule_keyword rule_value]... \ begin profile finish # # "[ ]" indicates an optional expression or field # "..." indicates the preceding expression may be repeated # "&&" used to "logically AND" rule_keyword and rule_value pairs \ together # "!" indicates negation of the following rule_keyword # # rule_keyword a predefined keyword that describes a general system # attribute. It is used with the rule_value to match a # system with the same attribute to a profile. # # rule_value a value that provides the specific system attribute # for the corresponding rule_keyword. A rule_value can # be text or a range of values (NN-MM). # To match a range of values, a system's value must be # greater than or equal to NN and less than or equal \ to MM. # # begin a file name of an optional Bourne shell script # that will be executed before the installation begins. # If no begin script exists, you must enter a minus sign(-) # in this field. # # profile a file name of a text file used as a template by the # custom JumpStart installation software that defines how # to install Solaris on a system. # # finish a file name of an optional Bourne shell script # that will be executed after the installation completes. # If no finish script exists, you must enter a minus sign (-) # in this field. # # Notes: # 1. You can add comments after the pound sign (#) anywhere on a \ line. # 2. Rules are matched in descending order: first rule through \ the last rule. # 3. Rules can be continued to a new line by using the backslash\ (\) before # the carriage return. # 4. Don't use the "*" character or other shell wildcards, \ because the rules # file is interpreted by a Bourne shell script. # # ########################################################################## # # RULE_KEYWORD AND RULE_VALUE DESCRIPTIONS # # # rule_keyword rule_value Type rule_value Description # ------------ --------------- ---------------------- # any minus sign (-) always matches # arch text system's architecture type # domainname text system's domain name # disksize text range system's disk size # disk device name (text) # disk size (MBytes range) # hostname text system's host name # installed text text system's insta lled version of Solaris # disk device name (text) # OS release (text) # karch text system's kernel architecture # memsize range system's memory size (MBytes range) # model text system's model number # network text system's IP address # totaldisk range system's total disk size (MBytes range) # # ########################################################################## # # RULE EXAMPLES # # The following rule matches only one system: # #hostname sample_host - host_class set_root_pw # The following rule matches any system that is on the 924.222.43.0 \ network # and has the sun4u kernel architecture: # Note: The backslash (\) is used to continue the rule to a new line. #network 924.222.43.0 && \ # karch sun4c - net924_sun4u - # The following rule matches any sparc system with a c0t3d0 disk that is # between 400 to 600 MBytes and has Solaris 2.1 installed on it: #arch sparc && \ # disksize c0t3d0 400-600 && \ # installed c0t3d0s0 solaris_2.1 - upgrade - # # The following rule matches all x86 systems: #arch i386 x86-begin x86-class - # # The following rule matches any system: #any - - any_machine - # # END RULE EXAMPLES # # karch sun4u - basic_prof - Table 14.2 describes the syntax that the rules file must follow.
Rules File RequirementsThe rules file must have the following:
The rules file should be saved in the JumpStart directory, should be owned by root, and should have permissions set to 644. The rules file can contain any of the following:
Table 14.3 describes the rule_keywords and rule_values that were introduced earlier.
During a custom JumpStart installation, the Solaris installation program attempts to match the system being installed to the rules in the rules.ok file in orderthe first rule through the last rule. Rules File MatchesA rule match occurs when the system being installed matches all the system attributes defined in the rule. As soon as a system matches a rule, the Solaris installation program stops reading the rules.ok file and begins installing the software based on the matched rule's class file. Here are a few sample rules: karch sun4u - basic_prof - The previous example specifies that the Solaris installation program should automatically install any system with the sun4u platform group based on the information in the basic_prof class file. There is no begin or finish script. hostname pyramid2 - ultra_class - The rule matches a system on the network called pyramid2. The class file to be used is named ultra_class. No begin or finish script is specified: network 192.168.0.0 && !model 'SUNW,Ultra-5_10' - net_class set_root_passwd The third rule matches any system on the network that is not an Ultra 5 or Ultra 10. The class file to be used is named net_class, and the finish script to be run is named set_root_passwd. any - - generic_class - The last example matches any system. The class file to be used is named generic_class and there is no begin or finish script. Validating the Rules FileBefore the rules file can be used, you must run the check script to validate that this file is set up correctly. If all the rules are valid, the rules.ok file is created. To validate the rules file, use the check script provided in the <install_dir_path>/Solaris_10/Misc/jumpstart_sample directory on the install server. Copy the check script to the directory containing your rules file and run the check script to validate the rules file: cd /jumpstart ./check [-p path] [-r file_name] <install_dir_path> is the directory that was specified using the setup_install_server script when the install server was set up. The check script options are described in Table 14.4.
When you use check to validate a rules file, the following things happen:
The following is a sample session that uses check to validate a rules and class file. I named the rules file "rulestest" temporarily, the class file is named "basic_prof" and I am using the -r option. With -r, the rules.ok file is not created, and only the rulestest file is checked. # /export/jumpstart/install/Solaris_10/Misc/jumpstart_sample/check -r \
/tmp/rulestest
Validating /tmp/rulestest...
Validating profile basic_prof...
Error in file " /tmp/rulestest", line 113
any - - any_maine -
ERROR: Profile missing: any_maineIn this example, the check script found a bad option. "any_machine" had been incorrectly entered as "any_maine." The check script reported this error. In the next example, the error has been fixed, we copied the file from rulestest to /export/jumpstart/rules, and reran the check script: #cp rulestest /export/jumpstart/rules #/export/jumpstart/install/Solaris_10/Misc/jumpstart_sample/check Validating rules... Validating profile basic_prof... Validating profile any_machine... The custom JumpStart configuration is ok. As the check script runs, it reports that it is checking the validity of the rules file and the validity of each class file. If no errors are encountered, it reports The custom JumpStart configuration is ok. The rules file is now validated. After the rules.ok file is created, verify that it is owned by root and that it has permissions set to 644. begin and finish ScriptsA begin script is a user-defined Bourne shell script, located in the JumpStart configuration directory on the configuration server, specified within the rules file, that performs tasks before the Solaris software is installed on the system. You can set up begin scripts to perform the following tasks:
Output from the begin script goes to /var/sadm/system/logs/begin.log. Caution Beware of /a Be careful not to specify something in the script that would prevent the mounting of file systems to the /a directory during an initial or upgrade installation. If the Solaris installation program cannot mount the file systems to /a, an error occurs, and the installation fails. begin scripts should be owned by root and should have permissions set to 744. In addition to begin scripts, you can also have finish scripts. A finish script is a user-defined Bourne shell script, specified within the rules file, that performs tasks after the Solaris software is installed on the system but before the system restarts. finish scripts can be used only with custom JumpStart installations. You can set up finish scripts to perform the following tasks:
Output from the finish script goes to /var/sadm/system/logs/finish.log. When used to add patches and software packages, begin and finish scripts can ensure that the installation is consistent between all systems. Creating class FilesA class file is a text file that defines how to install the Solaris software on a system. Every rule in the rules file specifies a class file that defines how a system is installed when the rule is matched. You usually create a different class file for every rule; however, the same class file can be used in more than one rule. A class file consists of one or more class file keywords (they are described in the following sections). Each class file keyword is a command that controls one aspect of how the Solaris installation program installs the Solaris software on a system. Use the vi editor (or any other text editor) to create a class file in the JumpStart configuration directory on the configuration server. You can create a new class file or edit one of the sample profiles located in /cdrom/cdrom0/s0/Solaris_10/Misc/jumpstart_sample on the Solaris 10 Software CD 1. The class file can be named anything, but it should reflect the way in which it installs the Solaris software on a system. Sample names are basic_install, eng_profile, and accntg_profile. A class file must have the following:
A class file can contain either of the following:
The class file is made up of keywords and their values. The class file keywords and their respective values are described in the following sections. archive_locationThis keyword is used when installing a Solaris Flash Archive and specifies the source of the Flash Archive. The syntax for this option is shown here: archive_location retrieval type locationThe retrieval_type parameter can be one of the following:
The syntax for a Flash Archive located on an NFS server is as follows: archive_location nfs server_name:/path/filename retry nWhere retry n specifies the maximum number of attempts to mount the archive. The syntax for a Flash Archive located on an HTTP or HTTPS server is as follows: archive_location http://server_name:port/path/filename <optional keywords> archive_location https://server_name:port/path/filename <optional keywords> Table 14.5 lists the optional keywords that can be used with this option:
The syntax for a Flash Archive located on an FTP server is as follows: archive_location ftp://username:password@server_name:port/path/filename <optional
keywords>Table 14.6 lists the optional keywords that can be used with this option:
The syntax for a Flash Archive located on local tape is as follows: archive_location local_tape device positionwhere device specifies the device path of the tape drive and position specifies the file number on the tape where the archive is located. The position parameter is useful because you can store a begin script or a sysidcfg file on the tape prior to the actual archive. The syntax for a Flash Archive located on a local device is as follows: archive_location local_device device path/filename file_system_typeThe syntax for a Flash Archive located in a local file is as follows: archive_location local_file path/filenameAll that is needed for this option is to specify the full pathname to the Flash Archive file. backup_mediabackup_media defines the medium that is used to back up file systems if they need to be re-allocated during an upgrade because of space problems. If multiple tapes or disks are required for the backup, you are prompted to insert these during the upgrade. Here is the backup_media syntax: backup_media <type> <path> type can be one of the keywords listed in Table 14.7.
Here are some examples of class file keywords being used: backup_media local_tape /dev/rmt/0 backup_media local_diskette /dev/rdiskette0 backup_media local_filesystem /dev/dsk/c0t3d0s7 backup_media local_filesystem /export backup_media remote_filesystem sparc1:/export/temp backup_media remote_system bcalkins@sparc1:/export/temp backup_media must be used with the upgrade option only when disk space re-allocation is necessary. boot_deviceboot_device designates the device where the installation program installs the root file system and consequently what the system's startup device is. The eeprom value also lets you update the system's EEPROM if you change its current startup device so that the system can automatically start up from the new startup device. Here's the boot_device syntax: boot_device <device> <eeprom> The device and eeprom values are described in Table 14.8.
Note X86 Preserve Only For x86 systems, the <eeprom> parameter must be preserve. The installation program installs the root file system on c0t1d0s0 and updates the EEPROM to start up automatically from the new startup device. For more information on the boot device, see Chapter 3, "Perform System Boot and Shutdown Procedures." bootenv_createbebootenv_createbe enables an empty, inactive boot environment to be created at the same time as installing the Solaris OS. You only need to create a / file system; other file system slices are reserved, but not populated. This kind of boot environment is installed with a Solaris flash archive, at which time the other reserved file system slices are created. Here's the bootenv createbe syntax: bootenv createbe bename new_BE_name filesystem mountpoint:device:fs_options The bename and filesystem values are described in Table 14.9.
client_archclient_arch indicates that the operating system server supports a platform group other than its own. If you do not specify client_arch, any diskless client that uses the operating system server must have the same platform group as the server. client_arch can be used only when system_type is specified as server. You must specify each platform group that you want the operating system server to support. Here's the client_arch syntax: client_arch karch_value [karch_value...] Valid values for <karch_value> are sun4u and i86pc. client_arch sun4u client_rootclient_root defines the amount of root space, in MB, to allocate for each diskless client. If you do not specify client_root in a server's profile, the installation software automatically allocates 15MB of root space per client. The size of the client root area is used in combination with the num_clients keyword to determine how much space to reserve for the /export/root file system. You can only use the client_root keyword when system_type is specified as server. Here's the syntax: client_root <root_size><root_size> is specified in MB. Here's an example: client_root 20 Note Don't Waste Space When allocating root space, 20MB is an adequate size. 15MB is the minimum size required. Any more than 20MB is just wasting disk space. client_swapclient_swap defines the amount of swap space, in MB, to allocate for each diskless client. If you do not specify client_swap, 32MB of swap space is allocated. Physical memory plus swap space must be a minimum of 32MB. If a class file does not explicitly specify the size of swap, the Solaris installation program determines the maximum size that the swap file can be, based on the system's physical memory. The Solaris installation program makes the size of swap no more than 20 percent of the disk where it resides, unless there is free space left on the disk after the other file systems are laid out. Here's the syntax: client_swap <swap_size><swap_size> is specified in MB. Here's an example: client_swap 64 This example specifies that each diskless client has a swap space of 64MB. clustercluster designates which software group to add to the system. The software groups are listed in Table 14.10.
You can specify only one software group in a profile, and it must be specified before other cluster and package entries. If you do not specify a software group with cluster, the end-user software group, SUNWCuser, is installed on the system by default. Here is cluster's syntax: cluster <group_name>Here's an example: cluster SUNWCall This example specifies that the Entire Distribution group should be installed. The cluster keyword can also be used to designate whether a cluster should be added to or deleted from the software group that was installed on the system. add and delete indicate whether the cluster should be added or deleted. If you do not specify add or delete, add is set by default. Here's the syntax: cluster <cluster_name> [add | delete]<cluster_name> must be in the form SUNWCname. dontusedontuse designates one or more disks that you don't want the Solaris installation program to use. By default, the installation program uses all the operational disks on the system. <disk_name> must be specified in the form c?t?d? or c?d?, such as c0t0d0. Here's the syntax: dontuse disk_name [disk_name...] dontuse c0t0d0 c0t1d0 Note dontuse and usedisk You cannot specify the usedisk keyword and the dontuse keyword in the same class file because they are mutually exclusive. filesysfilesys can be used to create local file systems during the installation by using this syntax: filesys <slice> <size> [file_system] [optional_parameters] The values listed in Table 14.11 can be used for <slice>.
The values listed in Table 14.12 can be used for <size>.
file_system is an optional field when slice is specified as any or c?t?d?s?. If file_system is not specified, unnamed is set by default, but you can't specify the optional_parameters value. The values listed in Table 14.13 can be used for file_system.
In the following example, the size of swap is set to 512MB, and it is installed on c0t0d0s1: filesys c0t0d0s1 512 swap In the next example, /usr is based on the selected software, and the installation program determines what disk to put it on when you specify the any value: filesys any auto /usr The optional_parameters field can be one of the options listed in Table 14.14.
A new option to the filesys keyword in Solaris 10 is mirror, which facilitates the creation of RAID-1 volumes as part of the custom JumpStart installation. This facility allows the creation of mirrored filesystems. You can issue this keyword more than once to create mirrors for different file systems. Note Only on Initial Install The filesys mirror keyword is only supported for initial installations. The syntax for the filesys mirror keyword is as follows: Filesys mirror [:name]slice [slice] size file_system optional_parameters Table 14.15 details the available options for the filesys mirror keyword.
filesys can also be used to set up the installed system to mount remote file systems automatically when it starts up. You can specify filesys more than once. The following syntax describes using filesys to set up mounts to remote systems: filesys <server>:<path> <server_address> <mount_pt_name> [mount_options] The filesys keywords are described in Table 14.16.
filesys zeus:/export/home/user1 192.9.200.1 /home ro,bg,intr forced_deploymentThis keyword forces a Solaris Flash differential archive to be installed on a clone system even though the clone system is different than what the software expects. This option deletes files to bring the clone system to an expected state, so it should be used with caution. install_typeinstall_type specifies whether to perform the initial installation option or the upgrade option on the system. install_type must be the first class file keyword in every profile. Following is the syntax: install_type [initial_install | upgrade] Select one of initial_install, upgrade, flash_install or flash_update. install_type initial_install geoThe geo keyword followed by a locale designates the regional locale or locales you want to install on a system (or to add when upgrading a system). The syntax is geo <locale> Values you can specify for locale are listed in Table 14.17.
Refer to the "International Language Environments Guide" in the "Solaris 10 International Language Support Collection" for a complete listing of locale values. This guide is available on the Solaris 10 documentation CD, or online at http://docs.sun.com. Here's an example where the locale specified is S_America: geo S_America layout_constraintlayout_constraint designates the constraint that auto-layout has on a file system if it needs to be re-allocated during an upgrade because of space problems. layout_constraint can be used only for the upgrade option when disk space re-allocation is required. With layout_constraint, you specify the file system and the constraint you want to put on it. Here's the syntax: layout_constraint <slice> <constraint> [minimum_size] The <slice> field specifies the file system disk slice on which to specify the constraint. It must be specified in the form c?t?d?s? or c?d?s?. Table 14.18 describes the options for layout_constraint.
The following are some examples: layout_constraint c0t0d0s3 changeable 1200 The file system c0t0d0s3 can be moved to another location, and its size can be changed to more than 1200MB but no less than 1200MB. layout_constraint c0t0d0s4 movable The file system on slice c0t0d0s4 can move to another disk slice, but its size stays the same: layout_constraint c0t2d0s1 collapse c0t2d0s1 is moved into its parent directory to reduce the number of file systems. local_customizationThis keyword is used when installing Solaris Flash archives and can be used to create custom scripts to preserve local configurations on a clone system before installing a Solaris Flash Archive. The syntax for this option is local_customization local_directory The local_directory parameter specifies the directory on the clone system where any scripts are held. localelocale designates which language or locale packages should be installed for the specified locale_name. A locale determines how online information is displayed for a specific language or region, such as date, time, spelling, and monetary value. Therefore, if you want English as your language but you also want to use the monetary values for Australia, you would choose the Australia locale value (en_AU) instead of the English language value (C). The English language packages are installed by default. You can specify a locale keyword for each language or locale you need to add to a system. Following is the locale syntax: locale locale_nameHere's an example: locale es This example specifies Spanish as the language package you want installed. metadbThe metadb keyword allows you to create Solaris Volume Manager state database replicas as part of the custom JumpStart installation. You can use this keyword more than once to create state database replicas on several disk slices. The syntax for this keyword is shown here: metadb slice [size size-in-blocks] [count number-of-replicas] Table 14.19 describes the options for metadb.
no_content_checkThis keyword is used when installing Solaris Flash Archives. When specified, it ignores file-by-file validation, which is used to ensure that a clone system is a duplicate of the master system. Only use this option if you are sure the clone is a duplicate of the master system, because files are deleted to bring the clone to an expected state if discrepancies are found. no_master_checkThis keyword is used when installing Solaris Flash Archives. When specified, it ignores the check to verify that a clone system was built from the original master system. Only use this option if you are sure the clone is a duplicate of the original master system. num_clientsWhen 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 that a server supports. If you do not specify num_clients, five diskless clients are allocated. You can only use this option when system_type is set to server. Following is the syntax: num_clients client_num Here's an example: num_clients 10 In this example, space is allocated for 10 diskless clients. packagepackage designates whether a package should be added to or deleted from the software group that is installed on the system. add or delete indicates the action required. If you do not specify add or delete, add is set by default. Following is the syntax: package package_name [add [retrieval_type location] | delete] The package_name must be in the form SUNWname. The retrieval_type parameter can be one of the following:
The syntax for a package located on an NFS server is as follows: package package_name add nfs server_name:/path retry n where retry n specifies the maximum number of attempts to mount the directory. The syntax for a package located on an HTTP or HTTPS server is as follows: package package_name add http://server_name:port/path <optional keywords> package package_name add https://server_name:port/path <optional keywords> Table 14.20 lists the optional keywords that can be used with this option.
The syntax for a package located on a local device is as follows: package package_name add local_device device path file_system_type The syntax for a package located in a local file is as follows: package package_name add local_file path All that is needed for this option is to specify the full pathname to the directory containing the package. Here's an example: package SUNWxwman add nfs server1:/var/spool/packages retry 5 In this example, SUNWxwman (X Window online man pages) is being installed on the system from a location on a remote NFS server. partitioningpartitioning defines how the disks are divided into slices for file systems during the installation. If you do not specify partitioning, the default is set. Following is the syntax: partitioning default|existing|explicit The partitioning options are described in Table 14.21.
root_deviceroot_device designates the system's root disk. Following is the syntax: root_device slice Here's an example: root_device c0t0d0s0 Note Specifying Mirrors If you are upgrading a RAID-1 (mirror) volume then the slice you specify should be one side of the mirror. The other side will be upgraded automatically. system_typesystem_type defines the type of system being installed. If you do not specify system_type in a class file, standalone is set by default. Following is the syntax: system_type [standalone | server] Here's an example: system_type server usediskusedisk designates one or more disks that you want the Solaris installation program to use when the partitioning default is specified. By default, the installation program uses all the operational disks on the system. disk_name must be specified in the form c?t?d? or c?d?, such as c0t0d0. If you specify the usedisk class file keyword in a class file, the Solaris installation program uses only the disks that you specify. Following is the syntax: usedisk disk_name [disk_name] Here's an example: usedisk c0t0d0 c0t1d0 Note dontuse and usedisk You cannot specify the usedisk keyword and the dontuse keyword in the same class file because they are mutually exclusive. Testing Class FilesAfter you create a class file, you can use the pfinstall command to test it. Testing a class file is sometimes called a dry run installation. By looking at the installation output generated by pfinstall, you can quickly determine whether a class file will do what you expect. For example, you can determine whether a system has enough disk space to upgrade to a new release of Solaris before you actually perform the upgrade. To test a class file for a particular Solaris release, you must test it within the Solaris environment of the same release. For example, if you want to test a class file for Solaris 10, you have to run the pfinstall command on a system running Solaris 10. To test the class file, change to the JumpStart directory that contains the class file and type the following: /usr/sbin/install.d/pfinstall -d or type the following: /usr/sbin/install.d/pfinstall -D Caution Install or Test? Without the -d or -D option, pfinstall actually installs the Solaris software on the system by using the specified class file, and the data on the system is overwritten. Following is the syntax for pfinstall: /usr/sbin/install.d/pfinstall [-D|-d] <disk_config> [-c <path>] <profile> The pfinstall options are described in Table 14.22.
You can create a <disk_config> file by issuing the following command: prtvtoc /dev/rdsk/<device_name> > <disk_config> /dev/rdsk/<device_name> is the device name of the system's disk. <device_name> must be in the form c?t?d?s2 or c?d?s2. <disk_config> is the name of the disk configuration file to contain the redirected output. Note Identifying Disks c?t?d?s2 designates a specific target for a SCSI disk, and c?d?s2 designates a non-SCSI disk. Here's an example: prtvtoc /dev/rdsk/c0t0d0s2 > test The file named "test" created by this example would be your <disk_config> file, and it would look like this: * /dev/rdsk/c0t0d0s2 partition map
*
* Dimensions:
* 512 bytes/sector
* 126 sectors/track
* 4 tracks/cylinder
* 504 sectors/cylinder
* 4106 cylinders
* 4104 accessible cylinders
*
* Flags:
* 1: unmountable
* 10: read-only
*
* First Sector Last
*Partition Tag Flags Sector Count Sector Mount Directory
0 2 00 0 268632 268631 /
1 3 01 268632 193032 461663
2 5 00 0 2068416 2068415
3 0 00 461664 152712 614375 /export
4 0 00 614376 141624 755999 /export/swap
6 4 00 756000 1312416 068415 /usrNote Multiple Disks If you want to test installing Solaris software on multiple disks, concatenate single disk configuration files and save the output to a new file. The following example tests the ultra_class class file against the disk configuration on a Solaris 10 system on which pfinstall is being run. The ultra_class class file is located in the /export/jumpstart directory, and the path to the Solaris CD image is specified because Volume Management is being used. In addition, if you want to test the class file for a system with a specific system memory size, set SYS_MEMSIZE to the specific memory size in MB as follows: SYS_MEMSIZE=memory_size export SYS_MEMSIZE cd /export/jumpstart /usr/sbin/install.d/pfinstall -D -c /cdrom/cdrom0/s0 ultra_class The system tests the class file and displays several pages of results. Look for the following message, which indicates that the test was successful: Installation complete Test run complete. Exit status 0. sysidcfg FileWhen a JumpStart client boots for the first time, the booting software first tries to obtain system identification information (such as the system's hostname, IP address, locale, timezone, and root password) from a file named sysidcfg and then from the name service database. If you're not using a name service, you'll use this file to answer system identification questions during the initial part of the installation. If you're using a name service, you'll want to look over the section titled "Setting Up JumpStart in a Name Service Environment." You'll use the sysidcfg file to answer system identification questions during the initial part of the installation. If the JumpStart server provides this information, the client bypasses the initial system identification portion of the Solaris 10 installation process. Without the sysidcfg file, the client displays the appropriate interactive dialog to request system identification information. You must create a unique sysidcfg file for every system that requires different configuration information. The sysidcfg file can reside on a shared NFS directory or the root (/) directory on a UFS file system. It can also reside on a PCFS file system located on a diskette. Only one sysidcfg file can reside in a directory or on a diskette. The location of the sysidcfg file is specified by the -p argument to the add_install_client script used to create a JumpStart client information file. Creating a sysidcfg file requires the system administrator to specify a set of keywords in the sysidcfg file to preconfigure a system. There are two types of keywords you use in the sysidcfg file: independent and dependent. Here's an example illustrating independent and dependent keywords: name_service=NIS {domain_name=pyramid.com name_server=server(192.168.0.1)}In this example, name_service is the independent keyword, while domain_name and name_server are the dependent keywords. Note Dependent Keywords Enclose all dependent keywords in curly braces {} to tie them to their associated independent keyword. Values can optionally be enclosed in single (') or double quotes ("). To help explain sysidcfg keywords, we'll group them in categories and describe each of them in detail. Name Service, Domain Name, and Name Server KeywordsThe following keywords are related to the name service you will be using. The name_service=<value> keyword is assigned one of five values which specify the name service to be used: NIS, NIS+, LDAP, DNS, and NONE. These are described below:
Network Related KeywordsNetwork related keywords relate to the network interface to be used. Specify this item as follows: network_interface=<value>Specify a <value> for the interface to be configured. You can enter a specific interface, such as hme0, or you can enter NONE (if there are no interfaces to configure) or PRIMARY (to select the primary interface) as follows: network_interface=hme0 If you are not using DHCP, the dependent keywords for a PRIMARY interface are as follows: hostname=<hostname> ip_address=<ip_address> netmask=<netmask value> default_route=<ip_address> protocol_ipv6=<yes or no> For example, if your primary network interface is named hme0, here's a sample sysidcfg file: network_interface=hme0
{primary hostname=client1
ip_address=192.168.0.10
netmask=255.255.255.0
default_route=192.168.0.1
protocol_ipv6=no}If you are using DHCP, the only keywords available are the following: dhcp protocol_ipv6=<yes or no>For example, here's a sample entry: network_interface=hme0
{primary dhcp protocol_ipv6=no}Whether using DHCP or not, the protocol_ipv6 keyword is optional. Note Multiple Interfaces Allowed You can now enter multiple network interfaces into the sysidcfg file; just specify a separate network_interface entry for each one to be included. Setting the Root Passwordroot_password=<encrypted passwd>The value for <encrypted passwd> is taken from the /etc/shadow file. For example, an entry might look like this: root_password=XbcjeAgl8jLeI The following is the security related keyword: security_policy=<value>Where <value> is either KERBEROS or NONE. When specifying the KERBEROS value, you'll need to also specify the following dependent keywords: default_realm=<fully qualified domain name>
admin_server=<fully qualified domain name>
kdc=<value><value> can list a maximum of three key distribution centers (KDCs) for a security_policy keyword. At least one is required. Here's an example using the security_policy keyword: security_policy=kerberos
{default_realm=pyramid.com
admin_server=krbadmin.pyramid.com
kdc=kdc1.pyramid.com,kdc2.pyramid.com}Setting the System Locale, Terminal, Time Zone, and Time ServerThe keyword used to set the system locale is system_locale=<value><value> is an entry from the /usr/lib/locale directory. The following example sets the value to English: system_locale=en_US The keyword to set the terminal type is as follows: terminal=<terminal_type> <terminal_type> is an entry from the /usr/share/lib/terminfo database. The following example sets the terminal type to vt100: terminal=vt100 The keyword to set the time zone is as follows: timezone=<timezone><timezone> is an entry from the /usr/share/lib/zoneinfo directory. The following entry sets the time zone to Eastern Standard Time: timezone=EST The keyword to set the time server is as follows: timeserver=<value><value> can be LOCALHOST, HOSTNAME, or IP_ADDRESS. The following example sets the time server to be the localhost: timeserver=localhost The following rules apply to keywords in the sysidcfg file:
The following is a sample sysidcfg file, located in the configuration directory named /export/jumpstart: system_locale=en_US
timezone=EST
timeserver=localhost
terminal=vt100
name_service=NONE
security_policy=none
root_password=XbcjeAgl8jLeI
network_interface=hme0 {primary protocol_ipv6=no netmask=255.255.255.0}Setting Up JumpStart in a Name Service EnvironmentAs stated in the previous section, you can use the sysidcfg file to answer system identification questions during the initial part of installation regardless of whether a name service is used. When the sysidcfg file is used with the NIS naming service, identification parameters such as locale and time zone can be provided from the name service. The sysidcfg file necessary for installing a JumpStart client on a network running the NIS name service is typically much shorter, and a separate sysidcfg file for each client is unnecessary. You'll use the /etc/locale, /etc/timezone, /etc/hosts, /etc/ethers, and /etc/netmasks files as the source for creating NIS databases to support JumpStart client installations. See Chapter 12, "Naming Services," for more information on NIS and how to create NIS maps. Setting Up ClientsNow you need to set up the clients to install over the network. After setting up the /export/jumpstart directory and the appropriate files, use the add_install_client command on the install server to set up remote workstations to install Solaris from the install server. The command syntax for the add_install_client command is as follows: add_install_client [-e <ethernet_addr>] [-i <ip_addr>] \ [-s <install_svr:/dist>] [-c <config_svr:/config_dir>] \ [-p <sysidcfg_svr/sysid_config_dir>] <host_name> <platform group> add_install_client -d [-s <install_svr:/dist>] [-c <config_svr:/config_dir>] \ [-p <sysidcfg_svr/sysid_config_dir>] [-t install_boot_image_path] \ <platform_name> <platform group> The add_install_client options are described in Table 14.23.
For additional options to the add_install_client command, see the Solaris online manual pages. In Step by Step 14.5, you'll create a JumpStart client that will boot from a system that is configured as both the boot and install server. In addition, the entire Solaris 10 media is copied to the local disk.
Tip Know your config files Make sure you are familiar with the differences between the rules file, a class file, and the sysidcfg file. It is quite common to get an exam question that displays the contents of one of them and asks the candidate to identify which one it is. Troubleshooting JumpStartThe most common problems encountered with custom JumpStart involve the setting up of the network installation, or booting the client. This section describes briefly some of the more popular errors and what to do if you are faced with them. Installation SetupWhen running the add_install_client command to set up a new JumpStart client, you might get the following message: Unknown client "hostname" The probable cause of this error message is that the client does not have an entry in the hosts file (or table if using a name service). Make sure the client has an entry in the hosts file, or table, and rerun the add_install_client command. When you have setup the JumpStart Install server, make sure the relevant directories are shared correctly. It is a common problem to share the file systems at the wrong level, so that the table of contents file cannot be found when the client tries to mount the remote file system. Client Boot ProblemsThe following error message can appear if the Ethernet address of the JumpStart client has been specified incorrectly: Timeout waiting for ARP/RARP packet... Check the /etc/ethers file on the JumpStart server and verify that the client's Ethernet address has been specified correctly. When booting the client from the network, to initiate a custom JumpStart installation, you might get the following error message if more than one server attempts to respond to the boot request: WARNING: getfile: RPC failed: error 5 (RPC Timed out). This error indicates that more than one server has an entry for the client in its /etc/bootparams file. To rectify this problem, you will need to check the servers on the subnet to find any duplicate entries and remove them, leaving only the entry required on the JumpStart server. When booting the client from the network, you could get the following error message if the system cannot find the correct media required for booting: The file just loaded does not appear to be executable You will need to verify that the custom JumpStart server has been correctly set up as a boot and install server. Additionally, make sure you specified the correct platform group for the client when you ran add_install_client to set up the client to be able to use JumpStart. A Sample JumpStart InstallationThe following example shows how you would set up a custom JumpStart installation for a fictitious site. The network consists of an Enterprise 3000 server and five Ultra1 workstations. The next section details how to start the JumpStart installation process by creating the install server. Setting Up the Install ServerThe first step is to set up the install server (see Step by step 14.6). You'll choose the Enterprise server. This is where the contents of the Solaris CD are located. The contents of the CD can be made available by either loading the CD in the CD-ROM drive or copying the CD to the server's local hard drive. For this example, you will copy the files to the local hard drive. Use the setup_install_server command to copy the contents of the Solaris CD to the server's local disk. Files are copied to the /export/install directory.
Creating the JumpStart DirectoryAfter you install the install server, you need to set up a JumpStart configuration directory on the server. This directory holds the files necessary for a custom JumpStart installation of the Solaris software. You set up this directory by copying the sample directory from one of the Solaris CD images that has been put in /export/install. Do this by typing the following: mkdir /jumpstart cp -r /export/install/Solaris_10/Misc/jumpstart_sample /jumpstart Any directory name can be used. You'll use /jumpstart for this example. Setting Up a Configuration ServerFollow the procedure in Step by Step 14.7 to set up a configuration server.
Setting Up ClientsNow, on the install server, set up each client as follows: cd /export/install/Solaris_10/Tools ./add_install_client -s sparcserver:/export/install -c sparcserver:/jumpstart\ -p sparcserver:/jumpstart -e 8:0:20:21:49:25 -i 192.9.200.106 sun1 sun4u ./add_install_client -s sparcserver:/export/install -c sparcserver:/jumpstart \ -p sparcserver:/jumpstart -e 8:0:20:21:49:24 -i 192.9.200.107 sun2 sun4u This example sets up two engineering workstations, sun1 and sun2, so that they can be installed over the network from the install server named sparcserver. Starting Up the ClientsAfter the setup is complete, you can start up the engineering systems by using the following startup command at the OK (PROM) prompt of each system: boot net - install You'll see the following displayed on the screen: Rebooting with command: net - install
Boot device: /pci@1f,0/pci@1,1/network@1,1 File and args: - \
install
20800
SunOS Release 5.10 Version Generic_64-bit
Copyright 1983-2005 Sun Microsystems, Inc. All rights reserved.
whoami: no domain name
Configuring /dev and /devices
Using RPC Bootparams for network configuration information.
Configured interface hme0
Using sysid configuration file 192.9.200.101:/jumpstart/sysidcfg
The system is coming up. Please wait.
Starting remote procedure call (RPC) services: sysidns done.
Starting Solaris installation program...
Searching for JumpStart directory...
Using rules.ok from 192.9.200.101:/jumpstart.
Checking rules.ok file...
Using profile: engrg_prof
Executing JumpStart preinstall phase...
Searching for SolStart directory...
Checking rules.ok file...
Using begin script: install_begin
Using finish script: patch_finish
Executing SolStart preinstall phase...
Executing begin script "install_begin"...
Begin script install_begin execution completed.
Processing default locales
- Specifying default locale (en_US)
Processing profile
- Selecting cluster (SUNWCprog)
WARNING: Unknown cluster ignored (SUNWCxgl)
- Selecting package (SUNWaudmo)
- Selecting locale (en_US)
Installing 64 Bit Solaris Packages
- Selecting all disks
- Configuring boot device
- Configuring swap (any)
- Configuring /opt (any)
- Automatically configuring disks for Solaris operating environment
Verifying disk configuration
Verifying space allocation
- Total software size: 2401.60 Mbytes
Preparing system for Solaris install
Configuring disk (c0t0d0)
- Creating Solaris disk label (VTOC)
Creating and checking UFS file systems
- Creating / (c0t0d0s0)
- Creating /opt (c0t0d0s5)
Beginning Solaris software installation
Starting software installation
SUNWxwrtl...done. 2401.55 Mbytes remaining.
SUNWulcf....done. 2397.28 Mbytes remaining.
SUNWuium....done. 2397.25 Mbytes remaining.
SUNWuiu8....done. 2390.46 Mbytes remaining.
<output truncated>
Completed software installation
Solaris 10 software installation succeeded
Customizing system files
- Mount points table (/etc/vfstab)
- Network host addresses (/etc/hosts)
Customizing system devices
- Physical devices (/devices)
- Logical devices (/dev)
Installing boot information
- Installing boot blocks (c0t0d0s0)
Installation log location
- /a/var/sadm/system/logs/install_log (before reboot)
- /var/sadm/system/logs/install_log (after reboot)
Installation complete
Executing SolStart postinstall phase...
Executing finish script "patch_finish"...
Finish script patch_finish execution completed.
Executing JumpStart postinstall phase...
The begin script log 'begin.log'
is located in /var/sadm/system/logs after reboot.
The finish script log 'finish.log'
is located in /var/sadm/system/logs after reboot.
syncing file systems... done
rebooting...The client reads the sysidcfg file, then the class file, and then the rules.ok file on the server. If any system identification information is missing in the sysidcfg file, the client will display the appropriate dialog requesting identification information. The system then automatically installs the Solaris operating environment. This completes the JumpStart configuration.  |
|
|