flarcreate -n someserver -R /net/someserver/ -c  someserver-04-22.flarZ

flar split -f <flar-file-name>

jumpserver:/jumpstart
	vi /etc/hosts #enter <hostname>
	vi /etc/ethers #enter <hostname>
	cd /jumpstart
	vi rules
	vi Profiles/<hostname>

		cd /jumpstart/OS/Solaris_8/Solaris_8/Tools/
			add_install_client someserver sun4u
			add_install_client -h someserver -a sun4u \
					-o Solaris_9 -b jump2p -d /export/jumpstart
		cd /jumpstart
			add-client someserver Solaris_9 sun4u IP-OF-JS-SERVER
	./check

	cd /tftpboot
		make sure two files link to bootfile (HEX address of IP of client)
	
console of host
	ok>boot net - install
		might have to wait if you put in a new MAC in ethers file (5 minutes)

		also, make sure local-mac-address is set to "true"


	on jumpstart server
		snoop -d hme0 | grep -i arp
		snoop multicast

files:

	/.profile
	/etc/profile
	/etc/defaultrouter
	/etc/domainname
	/etc/netmasks
	/etc/resolv.conf
	/etc/sudoers
	/etc/system
	/etc/inet/ntp.conf
	/etc/mail/sendmail.cf

	/etc/init.d/xntpd
	/etc/init.d/sendmail	
	/etc/init.d/psrfix	
	/etc/rc2.d/S25PSRFIX


	/etc/dfs/dfstab

	/etc/auto_direct
	/etc/auto_home
	/etc/auto_master

cron:
	root
		sysback
	sys
		sa1
	
setup:
	ntp

	generic
		/usr/local/bin/*
	perl
		/usr/local/bin/perl*
		/usr/local/lib/perl?

	user accounts
		/etc/passwd
		/etc/group
		/export/home/...

********************************************************
- add box to /etc/hosts

cd /JumpStart/2.6/config
	vi rules
	add client
		only use dash if script for that action is not 
		supposed to be executed
	cp files to newhost.[bfp]
	edit newhost.b - add JSCRACTH (needs to be server IP 
		and exported and writeable by root)
	mdir newhost
	cd newhost
	cp ../somehost/* . 
	vi sysidconfig
		change host and ip
	./check


cd /JumpStart/2.6/image/Solaris_2.6/Tools
	if bootserver !=  installserver then "-s bootservername:\
		/path_to_image"

	./add_install_client -e 08:00:20:80:5e:ed \
		-p jsserver:/JumpStart/2.6/config/newserverloading \
		-c jsserver:/JumpStart/2.6/config newserverloading sun4u


files:
	/etc/bootparams
	/etc/ethers
	/tftpboot/*
	/etc/hosts

on node to install

	ok> show-nets
		pick one
	ok> devlias net ^Y
	ok> boot net - install -
	ok> boot net -v install -
	ok> boot net - install - w
================================================================================
  
 

             Handsoff Jumpstart using "sysidcfg" with no Nameservice       
                                                                      
                     For Solaris 2.6, Solaris 7, & Solaris 8                     
                                            
                                Updated  09/05/00                            

A) About Jumpstart

    What is Jumpstart?
        The Jumpstart feature is an automatic installation (auto-install)
        process available in the Solaris 2.X operating environment. It allows
        system administrators to categorize machines on their network and
        automatically install systems based on the category (class) to which
        a system belongs.

    When should Jumpstart be used?
      Use Jumpstart:
        * To install new systems on the network.
        * To upgrade from one version of Solaris to another.
        * To install the Solaris environment on existing systems.

    How Jumpstart works.

     1) Boot the client across the network.
         ok boot net - install (Don't forget spaces around the "-")

        The client issues a RARP (reverse address resolution protocol)
        request across the network to the boot server in order to
        determine its Internet address.

     2) The boot server responds to the rarp request via the "rarpd"
        daemon (in.rarpd). Using the information in the /etc/ethers file the
        server can obtain the IP address of the client and return it back to
        the client.

     3) The client then gets its bootblock info by way of a TFTP request.

     4) On the boot server, the "inetd" daemon listens for and handles
        requests. This daemon receives the tftp request and spawns the
        in.tftpd daemon to handle this request. The Jumpstart boot image is
        sent back to the client.

     5) From the client, the Jumpstart boot image issues a hostconfig request
        for boot parameters.

     6) The boot server returns the information contained in the
        /etc/bootparams file to the client.

     7) Once the client has its boot parameters, the boot program on the
client
        mounts the root (/) partition from the boot server and /kernel/unix,
        which starts the "init" program (amongst other things). When the boot
        server is finished bootstrapping the client, it points the client to
        the configuration server.

     *  Note!! Keep in mind that this example is using a boot server that is
        also the install server. If this was a separate install server then
        the client would retrieve its boot info from the specified install 
        server and not the boot server.

     8) The client finds the configuration server from info in the bootparams
        file. The client mounts the configuration directory and runs
        "sysidtool". The client then uses more bootparams information to 
        locate and mount the install (OS image) directory. The client then
runs
        Suninstall and installs itself.

     * Just A Note About Boot Servers!!!!!!
        
        Normally, The install server provides the boot program for booting
        clients. However, under one condition, the Solaris network booting
        architecture requires you to set up a separate "boot server". A boot
        server is a system with just enough information to boot up a client
        over a network. You have to setup a boot server when the install
        client is on a different subnet than the install server.
        
        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 in order to obtain its IP address. RARP,
however
        does not acquire the netmask number, which is required to distribute
        information across a router on a network. If the install/boot server
        exists across a router the boot will fail because the network traffic
        cannot be routed correctly without a netmask number.
        
        The result is that you can install a client across a router, but you
        cannot boot a client across a router. So you will have to setup a 
        separate boot server on the same subnet as the client.

B) Setting up Jumpstart. (The following is a sample setup with Solaris 2.6)

    The first scenario has a system that is a boot, install, and
configuration
    server all in one. the client is a sparc 5 system.
   Note!!!
    Keep in mind that the "\"'s after some of the command lines depict a new
    line and are not actual parts to the command syntax.

    1) Gather all system and network information.

        boot/install/config server name         boot_svr
        OS image directory                      /export/install
        configuration directory                 /jumpstart
        Client Information
                Name                            sparc5_1
                Ethernet address                8:0:20:ab:cd:ef
                IP address                      129.151.29.10
                Architecture                    sun4x

    2) Create the boot/install server.

        You will first need to load the OS image from the Solaris 2.6 CD onto
        the servers local disk. You will need around 350 MB's of free space
in
        this directory.    (Takes about an hour!)
          boot_svr# cd /cdrom/cdrom0/s0/Solaris_2.6/Tools
          boot_svr# ls
           Boot                 dial                 setup_install_server
           add_install_client   rm_install_client
          boot_svr# cd /export
          boot_svr# mkdir install
          boot_svr# ./setup_install_server /export/install
           Verifying target directory...
           Calculating the required disk space for the Solaris_2.6 product
           Copying the CD image to disk...
           Install Server setup complete
          boot_svr# cd /export/install/Solaris_2.6
          boot_svr# ls
           Docs     Misc     Patches  Product  Tools


    Note: For Solaris 8 use CD 1 of 2, run setup_install_server from:
          boot_svr# cd /cdrom/cdrom0/s0/Solaris_8/Tools
          boot_svr# ./setup_install_server /export/install

    Note: If running "./setup_install_server -b" to setup a boot server only, 
          you do not need the next step.
       After this is complete, use Solaris 8 CD 2 of 2 and do the following:
          boot_svr# cd /cdrom/cdrom0/s0/Solaris_8/Tools
          boot_svr# ./add_to_install_server /export/install
    3) Create the configuration directory on the server.

        Now that the install and boot server information is taken care of,
you
        can set up the configuration portion of it.

        Create the directory and copy the necessary files in order to perform
        a custom jumpstart installation. You set this up by copying the
sample
        directory from the OS image directory (/export/install/...) to the
        /jumpstart directory.
           boot_svr# mkdir /jumpstart
           boot_svr# cp -r
/export/install/Solaris_2.6/Misc/jumpstart_sample/*
                    /jumpstart

    4) Create a Profile for the system.
        This file is used as a template for the custom jumpstart
installation.
        For this install we're going to use the default profile called
        "any_machine". This file can be found in /jumpstart. This can also be
        edited to suit your individual needs. Check out chapters 8 & 9 in the
        Automating Solaris Installations book (referenced at the end of this
        document) for instructions and examples of profiles.
           boot_svr# cat /jumpstart/any_machine
            install_type    initial_install
            system_type     standalone
            partitioning    explicit
            cluster         SUNWCXall
            cluster         SUNWCxgl delete
            package         SUNWaudmo add
            filesys         any 40 swap
            filesys         any 50 /opt

    5) Create the sysidcfg file.
        The sysidcfg file is used to automate the system identification
        portion of the Solaris install. The following is the one I used
        for this installation

           boot_svr# vi /jumpstart/sysidcfg
            system_locale=en_US
            timezone=US/Eastern
            timeserver=129.151.29.1    <------ boot_svr's IP address
            network_interface=le0 {netmask=255.255.255.0}
            terminal=dtterm
            name_service=NONE
      Note: To use "name_service=NONE" with Solaris 2.6 you will need to load
patch
            106193-03 or greater.
            For Solaris 8 you must use:     
              network_interface=primary {netmask=255.255.0.0
protocol_ipv6=no}
              security_policy=NONE
      Note: To use network_interface=primary on Solaris 2.6, you need patch
106193-03
            or greater. Solaris 7 and Solaris 8 do not need any patches.NONE
    6) Update the Rules file.
        The "rules" file is a text file used to create the "rules.ok", and is
        probably the most important file for custom jumpstart
installations.You
        can view this file as a look-up table consisting of one or more rules
        that define how install clients are installed, based on their system
        attributes.
        In this example we used the "any" keyword for the first rule
        (machine attributes) and the file "any_machine" for the fourth rule
        (profile name) and all others are left blank.
        ("-" = match always succeeds )

            boot_svr# cat /jumpstart/rules
             ####
             ####
             #
             any -   -   any_machine  -
              ^  ^   ^       ^        ^
              |  |   |       |        |
              |  |   |       |        -------------- Finish script
              |  |   |       --------------- Profile
              |  |   -------------- Begin script
              |  ----------- Rule Value (specific system attribute)
              ----- Rule keyword (general system attributes)


    7) Check the rules file.
        This is run to validate the rules file. This command creates the
rules.ok
        file which is required by the installation software to match install
        clients to the predetermined rules.
           Note!! For this example you should have one line of information in
the
                  rules that is UNcommented. (any - - any_machine -). Delete
                  any other uncommented lines in this file that don't pertain
                  to this particular install client before running the check
                  script.

            boot_svr# cd /jumpstart
            boot_svr#  ./check
             Validating rules...
             Validating profile any_machine...
             The custom JumpStart configuration is ok.
            boot_svr# cat rules.ok     (check for any unwanted lines!!)
            any -   -   any_machine  -
            boot_svr#


    8) Set up the client to install over the network
        After setting up the /jumpstart directory and appropriate files, you
use
        the "add_install_client" command on the server to setup the client to
        install Solaris from the server. You will also have to add the entry
for
        the client into  the "/etc/hosts" file manually.

            boot_svr# vi /etc/hosts
            #
            # Internet host table
            #
            127.0.0.1           localhost
            129.151.29.1        boot_svr loghost
            129.151.29.10       client_name         <----- Add this line!
            ~
            boot_svr#

        The proper syntax for this command is:
            # ./add_install_client -e <CLIENT_ETHERNET_ADDRESS>
              -s <INSTALL_SERVER>:<OS_IMAGE_DIRECTORY               
              -c <CONFIG_SERVER>:<CONFIGURATION_DIRECTORY>               
              -p <CONFIG_SERVER>:<PATH_TO_SYSIDCFG_FILE>               
              -n [SERVER]:name_service[netmask]    (The brackets "[]" are
needed!!!)
              CLIENT_NAME  ARCHITECTURE

            boot_svr# cd /export/install/Solaris_2.6/Tools
            boot_svr# ls
             Boot                  dial                  setup_install_server
             add_install_client    rm_install_client*
            boot_svr# ./add_install_client -e 8:0:20:ab:cd:ef
                      -s boot_svr:/export/install -c boot_svr:/jumpstart  \                     
                      -p boot_svr:/jumpstart  client_name sun4x
             Adding "share -F nfs -o ro,anon=0 /export/install" to
/etc/dfs/dfstab
             making /tftpboot
             enabling tftp in /etc/inetd.conf
             updating /etc/bootparams
             copying inetboot to /tftpboot
            boot_svr#

             In the "add_install_client" command,

             -e         Adds the clients info into the "/etc/ethers" file.

             -s         Specifies the name of Install server (boot_svr) and
                        path (/export/install/Solaris_2.6/) to the OS image
                        This option is necessary if the client is being added
                        to boot server.

             -c         Specifies the server (boot_svr) and path (/jumpstart)
                        to locate the configuration files.

             -p         This specifies the configuration server (boot_svr)
and
                        the path (/jumpstart) to the "sysidcfg" file.

             -n         This option specifies which name service should  be
used
                        during system configuration.  This sets the "ns"
keyword
                        in the bootparams(4) file.

                         name_service   Valid  entries  are  "nis",
                                        "nisplus", and "none".

                         SERVER   The name of the server or IP address of the
                                  specified name service. If the server
specified
                                  is on a different subnet, then the netmask
may be
                                  needed to enable the client to contact the
server.

                         netmask  The netmask value specified in
/etc/netmasks


             boot_svr   Is the name of the boot/install/configuration server.

             sparc5_1   Is the name of the jumpstart client.

             sun4m      Is the type of architecture for the client.
             
             
   9) Check to make sure the proper directories are shared.
        You may have to add the configuration (/jumpstart) directory into the
        dfstab file. The following example is how the dfstab file should
look.
        NOTE!!!
                If the /jumpstart entry doesn't exist then you will have to
                add this line manually and type in "shareall" to enable all
the
                shared entries.

            boot_svr# cd /etc/dfs
            boot_svr# more dfstab

             # place share(1M) commands here for automatic execution
             # on entering init state 3.
             #
             # share [-F fstype] [ -o options] [-d
             # "<text>"]<pathname>[resource]
             # .e.g,
             # share  -F nfs  -o rw=engineering  -d "home dirs" /export/home2
             share -F nfs -o ro,anon=0 /export/install
             share -F nfs -o ro,anon=0 /jumpstart   <-- May have to add
manually
            boot_svr# shareall     (to enable the share entries)
            boot_svr# dfshares     (to verify that they are shared)
             RESOURCE                               SERVER ACCESS
TRANSPORT
               boot_svr:/export/install              boot_svr  -      -
               boot_svr:/jumpstart                   boot_svr  -      -
          

   10) Boot the client and install the Solaris software
        This is done at the client (client_name).

           ok boot net - install
           ok boot net -v install

C) A listing of some of the files and directories that are created or changed
   on the boot server (boot_svr) during the installation procedure.


 boot_svr% cd /tftpboot
 boot_svr:
 boot_svr% ls -la
 total 362
 drwxrwxr-x   2 root   other     512 Jan 16 13:10 ./
 drwxr-xr-x  47 root   root     1024 Jan 16 13:10 ../
 lrwxrwxrwx   1 root   other      28 Jan 16 13:10 81971D0A.SUN4x ->   \ 
      inetboot.SUN4M.Solaris_2.6-1*
 -rwxr-xr-x   1 root   other  171460 Jan 16 13:10
inetboot.SUN4x.Solaris_2.6-1*

 -rw-r--r--   1 root   other     301 Jan 16 13:10 rm.129.151.29.10
 lrwxrwxrwx   1 root   other       1 Jan 16 13:10 tftpboot -> ./

 boot_svr% cat /etc/ethers
 8:0:20:ab:cd:ef client_name

 boot_svr% cat /etc/hosts
 127.0.0.1       localhost
 129.151.29.1    boot_svr   loghost
 129.151.29.10   client_name

 boot_svr% cat /etc/bootparams
 boot_svr       boottype=:os
 client_name root=boot_svr:/export/install/Solaris_2.6/Tools/Boot     \   
        install=boot_svr:/export/install boottype=:in     \         
        sysid_config=boot_svr:/jumpstart    \
        install_config=boot_svr:/jumpstart rootopts=:rsize=32768

 Note!!!! You may have to add NONE or the particular Name Service at the end
of the
          bootparams line in order to overcome any problems loading over the
network.


 boot_svr% cat /etc/dfs/dfstab

 #      place share(1M) commands here for automatic execution
 #      on entering init state 3.
 #
 #      share [-F fstype] [ -o options] [-d "<text>"] <pathname> [resource]
 #      .e.g,
 #      share  -F nfs  -o rw=engineering  -d "home dirs"  /export/home2

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

 boot_svr% cat /etc/nsswitch.conf
 #
 # /etc/nsswitch.nis:
 #
 # An example file that could be copied over to /etc/nsswitch.conf; it
 # uses NIS (YP) in conjunction with files.
 #
 # "hosts:" and "services:" in this file are used only if the
 # /etc/netconfig file has a "-" for nametoaddr_libs of "inet" transports.

 # the following two lines obviate the "+" entry in /etc/passwd and
 # /etc/group.
 passwd:     files nis
 group:      files nis

 # consult /etc "files" only if nis is down.
 hosts:      files nis
 networks:   nis [NOTFOUND=return] files
 protocols:  nis [NOTFOUND=return] files
 rpc:        nis [NOTFOUND=return] files
 ethers:     files  nis
 netmasks:   nis [NOTFOUND=return] files
 bootparams: files nis
 publickey:  nis [NOTFOUND=return] files

 netgroup:   nis

 automount:  files nis
 aliases:    files nis

 # for efficient getservbyname() avoid nis
 services:   files nis
 sendmailvars:   files
 boot_svr%

 boot_svr% cd /jumpstart
 boot_svr% ls -la
 total 84
 drwxr-xr-x   4 root     other        512 Jan 16 12:58 .
 drwxr-xr-x  47 root     root        1024 Jan 16 13:10 ..
 -rw-r--r--   1 root     other        182 Jan 16 08:22 any_machine
 -rwxr-xr-x   1 root     other      30029 Jan 15 13:34 check
 drwxr-xr-x   3 root     other        512 Jan 15 13:37 jumpstart_sample
 -rw-r--r--   1 root     other       4742 Jan 15 13:34 rules
 -rw-r--r--   1 root     other         54 Jan 16 08:22 rules.ok

 -rw-r--r--   1 root     other        188 Jan 15 13:36 sysidcfg
 boot_svr% cat sysidcfg
 system_locale=en_US
 timezone=US/Eastern
 timeserver=129.151.29.1
 network_interface=le0 {netmask=255.255.255.0}
 terminal=dtterm
 name_service=NONE

 boot_svr% cat rules.ok
 any -   -   any_machine  -
 # version=2 checksum=11112

 boot_svr% cat any_machine
 install_type   initial_install
 system_type    standalone
 partitioning   explicit
 cluster        SUNWCXall
 cluster        SUNWCxgl delete
 package        SUNWaudmo add
 filesys        any 40 swap
 filesys        any 50 /opt
 boot_svr%


D) Some Troubleshooting Hints.

 1) ARP/RARP errors while trying to boot up the client.
 
        This Error occurs when you boot an install client over the network,
        but the install client can't locate the boot server. This is
        usually caused by insufficient or incorrect information in the
        hosts and or ethers files. Also the "in.rarpd" daemon may not be
        running. Check to make sure /etc/nsswitch.conf file indicates the 
        correct search path (i.e.   ethers    files nis). Another daemon
        that can cause a client not to boot is "in.tftpd". Make sure this 
        is running (# ps -ef|grep tftpd). If it's not running then check
        the file "/etc/inetd.conf" and make sure the following line is not
        commented out: (No # symbol preceding this line)
        "tftp dgram udp wait root /usr/sbin/intftpd intftpd -s /tftpboot"
        
 2) le0 or hme0: no carrier errors.
 
        This is caused by the system not being connected to the network or
        there is a problem with the network port.
        
 3) RPC: Timed out
 
        This error occurs while trying to boot over the network and
        encountering problems with the bootparams file. Check the file
        for the proper information and spelling. You may have to end up 
        removing and re-adding the client with rm_install_client and
        add_install_client.
        
 4) Searching for Jumpstart directory...not found
        
        The install client is booting, but it fails to access the
        jumpstart directory. This will cause the "Hands Off" install
        to go interactive. This can be caused by a couple of things.
        An incorrect path name specified in the add_install_client -c
        command or the jumpstart directory isn't shared properly.
        
 5) Custom Jumpstart failing (No Hands Off install or rules.ok problems).
 
        During a custom jumpstart you may be prompted to answer
        questions in order to complete the jumpstart. This is a Hands
        off install and there shouldn't be any user intervention
        at this time. This may be a result of the OS images "netmask" 
        file not matching the /etc/netmasks file or sysidcfg file.
        Example: /etc/netmasks should look like: 129.151.0.0 255.255.255.0
        (Your network number will be different.)
        
        
        (Sol 2.4/2.5 = "cd_image"/export/exec/kvm/"arch_dir"/netmask)
        (Solaris 2.6 = "cd_image"/Tools/Boot/netmask)
        It should look like this:      255.255.255.0
        
        If you need to do either of the above, you must reboot the boot
        server.
        
 
 6) WARNING: getfile: RPC failed: error 5 (RPC Timed out)
  
        This is usually a result of two or more servers responding
        to the same boot request. The install client may attach 
        itself to the wrong server that contains the wrong information.
        Possible areas to look at are the bootparams file (look for the 
        correct boot server), the /tftpboot directory may have multiple
        entries for the same client     
        


E) Other resources to check out.

   Reference Manuals
    Solaris Advanced Installation Guide (Solaris 2.6)
                                p/n  802-5740-10
    Automating Solaris Installations (A Custom Jumpstart Guide)
                                isbn 0-13-312505-X

   SRDB's/PSD's/Infodocs....
    10919 srdb Jumpstart fails to detect rules.ok
    10952 srdb Jumpstart does not mount all file systems
    12315 srdb Client does not configure hostname.le0 after jumpstart
    11972 srdb Jumpstart boots interactive instead using rules.ok file
    12195 srdb Jumpstart: Install client boots from wrong server
    12018 srdb Jumpstart error:filename is not a valid Solaris 2.x install
CDROM
    11070 srdb Jumpstart gets stuck in configuring /dev
    12019 srdb Jumpstart add_install_client Error:Unknown client "hostname"
    12196 srdb jumpstart: install client doesn't boot, install server
configured
    12022 srdb No network boot server, unable to install the system
    12040 srdb Requesting IP address
    12171 srdb WARNING: getfile: RPC failed: error 5 (RPC timed out)
    6383  srdb autoinstall does not use begin and finish script
    11862 srdb System hangs during boot net - install
    10247 srdb Autoinstall hands off timezone problems
    11070 srdb JumpStart gets stuck in configuring /dev
    13498 srdb Jumpstart is going interactive, looking for timezone and
NIS/NIS+
               nameservice
    14733 srdb Hands Off Jumpstart to Solaris 2.5 (and 2.5.1) without using a
               naming service.

    12112 infodoc Changes in Solaris 2.5
    12139 infodoc Solaris 2.5 changes in service setup for clients
    12308 infodoc How to (re)install jumpstart image on to disk
    12063 infodoc Jumpstart model rules Platform Names and Groups
    15834 infodoc How to disable Maint. Update (MU) from jumpstart
installation
    15744 infodoc Setting up a network interface alias
  
  
  
  

  Jumpstart Setup and Troubleshooting Product Support Document (PSD) 

  If you are new to network and system administration and would like 
  to know more about jumpstart in addition to what is in this document 
  please read "Automating Solaris Installations" A Custom Jumpstart 
  Guide by Paul Anthony Kasper and Alan L. McClellan. 

  Contents: 

  1) What is jumpstart? 
  2) Setting up up the Server 
  3) Adding clients 
  4) Check list 
  5) Troubleshooting Techniques 

  Section 1: 

  What is jumpstart? 

  1a) Jumpstart is used to install new systems with preconfigured 
      software. 

  1b) Custom Jumpstart - Used to automatically configure and 
      install systems; can be made completely "hands off." 

  Section 2: 

  Setting up the server: 

  You must have an install server. If the install sever and the 
  boot server are on different subnets, the boot server must be 
  on the same subnet as the client. 

  1) On the server, insert the Solaris CD-ROM and 
      # cd /cdrom/cdrom0/s0 (for Solaris versions 2.5.1 and earlier) 
     or 
      # cd /cdrom/cdrom0/s0/Solaris_2.x/Tools (substitute 6 or 7 as required) 
      # ./setup_install_server /export/install 

      This assumes a running volume manager. 
      The script might abort for the following reasons: 

       a) Insufficient disk space. 
       b) Cannot create /export/install. 
  
  If the install server is on a different subnet, set up a boot server: 
  
  Insert the solaris cdrom on the boot server and then 
      # cd /cdrom/cdrom0/s0 
      # ./setup_install_server -b /export/install sun4c 

  This will copy required kernel architecture information from the Solaris CD 
  image to the boot server's local disk. 

  You must have a name service so that you can setup automatic 
  system configuration such as geographic region, time zone, netmask value. 

  Creating a profile server: 

  This server provides all the custom JumpStart files for install clients 
  to use. 

  Do the following to create the profile server: 

     a) Create a jumpstart directory on a server. 
     b) Edit the /etc/dfs/dfstab file and share the jumpstart directory. 
     c) Copy the sample custom jumpstart installation files into the
jumpstart 
        directory on the server. 

  2) Create profiles: 

  Sample installation profiles reside in the auto_install_sample directory 
  on the solaris CD image, do the following to create profiles: 

     a) Create a file and give it a descriptive name. 
     b) Add profile keywords and profile values to the profile. 

  Section 3: 

  Adding Clients 

  3) Update the system files or nameserver maps or tables: 
  
     Use AdminSuite to add client hosts 
      a) Select hostmanager. 
      b) Select nameservice (nis, nis+, none). 
      c) Select edit - add host. 
      d) Leave remote install disabled. 

       or 

     Add the client to files, maps, or tables manually: 

     a) /etc/ethers 
        8:0:20:12:1f:34  clienthostname 
     b) /etc/hosts 
        129.131.111.58   clienthostname 

  4) Add Clients 
  
     a) Run the add_install_client script on the install server with the -c
option 

     # cd /export/install 
     # ./add_install_client -c server:/export/install/jumpstart clientname
     # sun4c 

     Run the add_install_client on the boot server if the install 
     server is on a different subnet 

     # cd /export/install 
     # ./add_install_client -s server:/export/install -c \ 
      server:/export/install/jumpstart clientname sun4c 

  If you have more than one architecture, you can avoid using -c option 
  above by putting an asterisk (the wild card) entry in /etc/bootparams, 
  which allows all clients to access to jumpstart information 
  
    * install_config=server:/export/install/jumpstart 

  What does add_install_client do? 

    - Adds the client entry in the /etc/bootparams file. 
  
    - Creates client boot file in the /tftpboot directory. 
  
    - Enables in.tftpd daemon for booting sparc clients, modifies
      /etc/inetd.conf. 
  
    - Stores the ethernet address of the install client /etc/ethers. 
  
    - Stores the IP address and the hostname in /etc/hosts. 
  
    - Updates nsswitch.conf file to specify the name service search path 
      for the client. 
  
    - Adds an entry to /etc/dfs/dfstab to share /export/install directory. 

  Making Jumpstart Non-Interactive ( automatic or "hands-off" ) 

  If you want to make jumpstart non-interactive ( automatic ) then 
  perform these additional steps: 
  
     NOTE: These steps are required if you want to make jumpstart hands-off. 
           They are not required if you want an interactive jumsptart. 

  1) Create a jumpstart directory on the install server, which contains 
     all the files needed by clients. 

     Use the sample directory from solaris cdrom. 

     # cd /export/install 
     # cp -r auto_install_sample jumpstart 

  2) Create a custom jumpstart rules file. 
     This is a text file that is created by using the rules keywords. 
     Use the one on the Solaris cd as an example and change it 
     if necessary. 
  
     # cd /export/install/jumpstart 
     # cp rules rules.orig 
     # vi rules [ make changes as per your need ] 
  
     Make sure you use the predefined keywords. 
     For information on supported keywords see InfoDoc 12063 for model rules 
     and platform names. 

  3) Create custom profile file or files. 
     Profiles are text files used to define the installation configuration. 
  
  4) Create begin and finish scripts as needed. 
     The begin script is a shell script for pre-install tasks. 
     The finish script is a shell script for post-install tasks. 
     # cd /export/install/jumpstart 
     # cp finish finish.orig 
     # vi finish  [ make changes as per your need ] 
     See InfoDoc #11826 for a sample finish script to install patches. 

  5) Create a rules.ok file using ./check script. 
     The check script runs a validity check on the rules file and creates
rules.ok 
     you can run it by 
     # ./check -p /export/install 
  
  or 

     # cd /export/install/jumpstart 
     # ./check 

     This validates the profile and rules files for syntax and, if no errors 
     are found, creates rules.ok 

  6) Configure for "hands off" installation. 
  
     Requires the name server switch file /etc/nsswitch.conf. 
     NIS or NIS+ name service is required. 
  
  Section 4: 

  Check list: first things first 

  Have I done everything?? 

  a) Create one or more install servers. 
  b) Create a boot server on the subnets. 
  c) Enable auto-configuration. 
  d) Create a profile server. 
  e) Create profiles. 
  f) Create begin and finish scripts(optional). 
  g) Create rules files. 
  h) Create a rules.ok file, execute the check script. 
  i) Add the install client information to the name server. 
  j) Boot the install client. 
  

  Section 5: Troubleshooting 

  Understanding the Network Boot Process: 

  Client                                 Server 

  ok boot net - install 

  --------------------------------------------------------------------------| 
                                                                            | 
  PROM broadcasts RARP request ---------> RARP server sends IP address      | 
                               <---------  rarpd /etc/ethers                | 
                                                                            | 
  PROM makes TFTP request      ---------> TFTP server sends inetboot code   | 
                              <----------  in.tftpd /tftpboot/ipadd.arch    | 
                                                                            | 
  INETBOOT sends WHOAMI       ----------> server sends hostname             | 
  request                     <----------  rpc.bootparamd /etc/hosts        | 
                                                                            | 
  IBETBOOT sends GETFILE      ----------> Server sends servername and path  | 
  request                     <----------  rpc.bootparamd /etc/bootparams   | 
                                                                            | 
  INETBOOT sends NFS mount    ----------> Server sends kernel               | 
  request                     <----------  rpc.mountd /etc/dfs/dfstab       | 
                                           nfsd                             | 
                                                                            | 
  -------------------------------------------------------------------------- 

  The one best tool to use to troubleshoot jumpstart issues 
  is the snoop command. 

  Look at the manual pages for the command. 
  A couple of options that work well for debugging are: 

    snoop -o snoop.out Client_Ethernet_Address 

    use snoop -i snoop.out 
  
    (View the file infodoc 11813 for more information). 

  The use of the Client_Ethernet_Address will eliminate any traffic not 
  addressed to or from the client in question. Additionally it will 
  allow the viewing of the early portions of the boot process including 
  the initial RARP and loading of the inetboot program. 

  You can just use snoop without naming a system to capture all 
  network activity (more often more data than you'll need - although 
  you can limit the protocols monitored. Or, modify the "snoop all 
  activity" approach by naming one of the involved servers AND the 
  JumpStartClient to monitor the activity or lack of it between those 
  two systems only. 

  Also observe the boot messages for clues as to what may be happening. 

  a) Client does not boot. 
     Look for the error message. 
     boot net - install loads the inet boot code, check the server for: 
     -ethernet entry in the ethers file, table or maps. 
     -client entry /tftpboot directory has the correct IP address and 
  architecture 
  
   # ps -ef | grep in.tftpd 
  
   if this daemon is not running, make sure tftpd is enabled in the 
   /etc/inetd.conf file. 
  
  b) Client asks for hosts, time zone and netmasks information 
  
     If you are using 

     NIS or NIS+ look at SRDB # 10247 
     No nameservice look at infodoc # 16484 

  c) Time out ARP/RARP error during boot net - install 

     See InfoDoc 11812, make sure network hardware is ok 

     One helpful troubleshooting method is to, as superuser, kill 
     the in.rarpd process running on the boot server and restart it 
     as "/usr/sbin/in.rarpd -d".  If in.rarpd has any difficulties, 
     informational (debug) messages will be presented on the boot 
     server (which could also be the install/config server) console 
     screen. 

  d) client will not autoinstall 
  
     -Verify ethers or host files 
     -Verify whether the correct server is responding; if not 
      you can remove the entries for the client on the server that 
      is responding or bring the server down until the client starts to 
      boot from the correct server. 
     -Make sure you have a boot server on the same subnet as the client. 
     -Make sure the files are shared properly on the server. 

      # showmount -e 
      # dfshares 
      # unshareall 
      # shareall 

          This way you can make sure all the files are shared as per 
          /etc/dfs/dfstab. cat the /etc/dfs/dfstab file to see whether 
          you see an entry for /export/install directory. 

     -Check proper entry in the bootparams file. 

     The "rpc.bootparamd" proceess, as was mentioned above for "in.rarpd", 
     can be run in Debug mode.  On the boot server, as superuser, kill 
     the then current "rpc.bootparam" process and restart it as 
     "/usr/sbin/rpc.bootparamd -d".  If "rpc.bootparamd" encounters any 
     difficulties, informational (debug) messages will be presented on the 
     boot server (which could also be the install/config server) console 
     screen. 

  e) Problems with finish script 
  
     chroot: no such file or directory 

     use the "-R" option when installing patches or using pkgadd. 
     ( refer to SRDB 13135 ). 

  f) Patch install problems 

     Make sure the script is correct. Some of the patches and packages 
     cannot be installed using the finish script because some of these
patches 
     need the machine to be rebooted. Read the "README" file for the patches. 

  g) There are other troubleshooting tips on page 253 of the 
     Automating Solaris Installations Guide. 
  

  Summary of other SRDB and InfoDoc articles under jumpstart: 
  (As this list keeps growing, you can always search for new articles) 

  10919 srdb Jumpstart fails to detect rules.ok 
  10952 srdb Jumpstart does not mount all file systems 
  12315 srdb Client does not configure hostname.le0 after jumpstart 
  11972 srdb Jumpstart boots interactive instead using rules.ok file 
  12195 srdb Jumpstart: Install client boots from wrong server 
  12018 srdb Jumpstart error:filename is not a valid Solaris 2.x install
CDROM 
  11070 srdb Jumpstart gets stuck in configuring /dev 
  12019 srdb Jumpstart add_install_client Error:Unknown client "hostname" 
  12196 srdb jumpstart: install client doesn't boot, install server
configured 
  12022 srdb No network boot server, unable to install the system 
  12040 srdb Requesting IP address 
  12171 srdb WARNING: getfile: RPC failed: error 5 (RPC timed out) 
  6383  srdb autoinstall does not use begin and finish script 
  11862 srdb System hangs during boot net - install 

  12112 infodoc Changes in Solaris 2.5 
  12139 infodoc Solaris 2.5 changes in service setup for clients 
  12308 infodoc How to (re)install jumpstart image on to disk 
  12063 infodoc Jumpstart model rules Platform Names and Groups 
================================================================================

JumpStartTM Mechanics: Using JumpStart Application for
Questions       Hands-Free Installation of Unbundled Software - Part 2
                By John S. Howard - Enterprise Engineering
                June 2000


Introduction

Automating and standardizing the installation of the SolarisTM
Operating Environment along with the associated unbundled
software products and datacenter management tools is one of the
largest challenges facing System Administrators managing large
environments or datacenters. In this article, a procedure for
automating the initial configuration of Sun Enterprise Volume
ManagerTM (SEVM) software and encapsulation of the root disk
will be presented.

As encapsulation is a complicated process, a brief overview of
encapsulation will also be presented. This article will only
address basic configuration and encapsulation of the root disk,
and is meant to provide an examination of advanced techniques
for installation of the Solaris Operating Environment and
JumpStartTM Server configuration.The techniques and procedures
presented here are meant to be a starting point for your storage
configuration. A reference configuration for SEVM controlled
boot disks will be presented in a future article.

This article uses the terms boot disk and root disk
interchangeably to refer to the physical disk that the Solaris
Operating Environment has been installed on and is the default
boot device.


Assumptions
This article assumes that the reader has a moderate level of
experience with both JumpStart technology and the SEVM software.
Additionally, it is assumed that you have a JumpStart server
configured to install the Solaris Operating Environment and SEVM
2.6, as explained in Part 1 of this 2 part series of Sun
BluePrintsTM OnLine article published in May 2000
(http://www.sun.com/blueprints/0500/jsmech1.pdf). For clarity
and simplicity, throughout this article we will create the
rootdg disk group containing only an encapsulated boot disk.
Extending and augmenting the following scripts and procedures is
left as an exercise for the reader: mirroring the boot disk,
adding hotspares, configuring recovery disks to rootdg, and
creating and populating additional disk groups.
This article presents several scripts and procedures, it is
important to keep in mind that these scripts are not "production
ready". These scripts are presented to demonstrate a technique,
and as such, the scripts will contain limited or no error
checking.


A Brief Overview of Encapsulation

Encapsulation is the method by which the SEVM software takes
over management of a disk which has data that needs to be
preserved. The most common use of encapsulation is to put the
Solaris Operating Environment boot disk under SEVM control.
Placing the boot disk under SEVM software control is desired to
mirror the boot disk, to provide a higher level of reliability,
availability and serviceability (RAS) of the system.
All disks under SEVM software control (whether encapsulated or
initialized) are divided into 2 regions:

1. The public region, used for SEVM's volumes, subdisks, and other virtual devices.
2. The private region, used by volume manager for internal storage of its configuration information.

When encapsulating a disk, the SEVM software will require a
small amount of space (typically several cylinders) for its
private region. The challenge that the SEVM software faces is
that all space on the boot disk may have already been allocated.
In this case, the SEVM software will steal several cylinders
from the swap partition and appropriately mask off the stolen
area by creating a rootdiskPriv subdisk. Encapsulation is
usually accomplished by running vxinstall or vxdiskadm and
responding to the prompts.



A Look Under the Hood of Encapsulation
Due to being extremely interactive and difficult to script, the
usual methods of encapsulation are not viable for execution from
a JumpStart server finish script. In order to provide a
hands-free method of invoking encapsulation we will examine two
techniques: hand-crafting SEVM control files directly and using
/usr/lib/vxvm/bin/vxencap (the SEVM encapsulation preparation
script) to build the control files.

The actual work of encapsulation is performed by
/etc/init.d/vxvm-reconfig at system boot. vxvm-reconfig is
driven by the contents or presence of several control files in
the /etc/vx/reconfig.d directory.


Licensing
It is important to remember that the SEVM software requires a
license, that license can be in the form of hardware such as a
Sun StorEdgeTM A5200, or a software license key. Regardless of
which licensing method is in use at your site, the SEVM software
must be licensed before attempting to encapsulate your boot disk.

If the software license method is in use at your site, the
scripts and procedures presented here should be modified to
license the SEVM product before any SEVM commands are executed
or configuration is done. To create a software license, the
finish script should be modified to either run vxserial, or
manually create the license key in the /etc/vx/elm directory.



vxvm-reconfig, The Hardest Working Script in SEVM
All of the actual work of encapsulation, such as creating the
private region and creating any needed subdisks is done by
vxvm-reconfig. In brief, vxvm-reconfig checks for the presence
of several flag files and control files in /etc/vx/reconfig.d.
Based upon the presence and contents of these files
vxvm-reconfig will bring disks under SEVM software control and
make other SEVM software configuration changes. An in-depth
examination of vxvm-reconfig is outside the scope of this
article, however a careful reading of the script will provide
insight into the details of SEVM software start-up.



vxencap Created Control Files
Creation of the commands and the encapsulated disk layout are
done by the vxencap script. By simply executing vxencap and
specifying the desired disk media name (rootdisk), the boot disk
will take care of the set-up for encapsulation:


/usr/lib/vxvm/bin/vxencap rootdisk=c0t0d0

vxencap is the preferred method for scripting encapsulation, it
is a standard SEVM utility complete with a man page. However,
vxencap does not function as expected from a JumpStart server
finish script. The reason that vxencap should not be used from
the finish script is due to vxparms, one of the utilities used
by vxencap to query the environment and kernel. vxparms
functions correctly from the finish script, however, it is
returning information relative to the currently booted
installation mini-root environment. The mini-root environment is
different in several key areas such as device major/minor
numbers and device drivers. For example, the SEVM device drivers
are not loaded in the JumpStart server mini-root.

It is possible to build a mini-root with the SEVM drivers
installed, such as the MR system, that is served by the
JumpStart server. However, working around the device numbering
issues becomes very problematic and inefficient in terms of
time. The method that is easiest to maintain, is to have the
JumpStart finish script add a start-up script to the client
system, such as /etc/rc3.d/S99encap-root, to be executed
whenever the client system enters run-level 3. The function of
S99encap-root is to test for the presence of a flag file. If
this flag file exists, then the S99encap-root script will
execute vxencap and initiate a re-boot. At that re-boot,
vxvm-reconfig will complete the actual work of encapsulating the
boot disk.

When using vxinstall to encapsulate the boot disk and configure
SEVM, vxinstall gathers information on disks and disk
controllers currently attached to the system, and decides
specifically what disks should be encapsulated and what disks
need to be initialized. Our boot disk is c0t0d0, but there is
one other disk on the c0 controller - c0t0d0. We will need to
hand-craft the files instructing SEVM to ignore c0t0d0.

Having vxvm-reconfig ignore disks, is accomplished by listing
the disks to be ignored in a file that is named for the
controller, and then listing the controllers containing disks to
be ignored in the /etc/vx/reconfig.d/cntrls file. For example,
the following two commands will create and populate the
necessary files to ignore c0t1d0:


echo c0t1d0 >/etc/vx/reconfig.d/c0
echo c0 >/etc/vx/reconfig.d/cntrls


Finally, we need to signal vxvm-reconfig to reconfigure on the
next reboot:


touch /etc/vx/reconfig.d/state.d/reconfig


Automated Encapsulation After Installation

The JumpStart finish script used to create S99encap-root and the
flag file is:

   #!/bin/sh

   BASEDIR=/a
   SLASHAMNT=${BASEDIR}/mnt
   VXPRODUCT=${SLASHAMNT}/Product
   VXPATCH=${SLASHAMNT}/Patches
   OK=0
   NOTOK=1

   mount -F nfs blackmesa:/JumpStart/sun_sevm_2_6 ${SLASHAMNT}
   if [ $? != 0 ]; then
   exit ${NOTOK}
   fi

   echo "Installing SUNWvxvm..."
   pkgadd -a ${SI_CONFIG_DIR}/noask -d ${VXPRODUCT} \
   -R ${BASEDIR} SUNWvxvm
   echo "Installing SUNWvxva..."
   pkgadd -a ${SI_CONFIG_DIR}/noask -d ${VXPRODUCT} \
   -R ${BASEDIR} SUNWvxva
   echo "Installing SUNWasevm..."
   pkgadd -a ${SI_CONFIG_DIR}/noask \
   -r ${SI_CONFIG_DIR}/SUNWasevm.response \
   -d ${VXPRODUCT} -R ${BASEDIR} SUNWasevm
   echo "Installing SUNWvmsa..."
   pkgadd -a ${SI_CONFIG_DIR}/noask \
   -r ${SI_CONFIG_DIR}/SUNWvmsa.response \
   -d ${VXPRODUCT} -R ${BASEDIR} SUNWvmsa
   echo "Installing SUNWvmman..."
   pkgadd -a ${SI_CONFIG_DIR}/noask -d ${VXPRODUCT} \
   -R ${BASEDIR} SUNWvmman
   echo "Installing SUNWvmdev..."
   pkgadd -a ${SI_CONFIG_DIR}/noask -d ${VXPRODUCT} \
   -R ${BASEDIR} SUNWvmdev
   echo "Preparing for encapsulation of c0t0d0 ..."
   #
   # If needed, setup software license would go here
   #
   # Create any disk exclusion and inclusion files
   #
   cat < ${BASEDIR}/etc/rc3.d/S99encap-root <


This method adds one reboot to the installation process as we:
boot off the JumpStart server to install the Solaris Operating
Environment, reboot off of the newly installed disk, then reboot
a third time after the vxencap completes. However this is
certainly an equitable trade-off for having an automated,
documented, and easily maintainable method for installation and
encapsulation.



Hand-Crafting the Control Files
By hand-crafting the control files in /etc/vx/reconfig.d from
the JumpStart server's finish script, we can cause encapsulation
to occur on the next reboot after the Solaris Operating
Environment installation completes. This technique is only
presented to give understanding to the procedure of
encapsulation, for reasons that shall soon become painfully
apparent, this technique is not recommended.

The primary purpose of vxencap is to map out the specified disk
to be encapsulated. This mapping process involves specifying the
subdisk layout information for the soon-to-be encapsulated disk
and saving a copy of the disk's current volume table of contents
(VTOC). This saved VTOC is required if the disk is ever to be
unencapsulated and reverted to the underlying partitions.
Additionally, the disk media name that SEVM should use for the
device will need to be specified. For every device to be
encapsulated (controlled by the disk names listed in
/etc/vx/reconfig.d/disks-cap-part), these items are stored in
three files in a subdirectory named for the device, under the
/etc/vx/reconfig.d/disk.d directory. For example, we will be
encapsulating /dev/dsk/c0t0d0, the encapsulation control files
that need to be created are:


File Name                   Contents
The disk(s)
/etc/vx/reconfig.d/disks-cap-part         device names to be encapsulated

/etc/vx/reconfig.d/disk.d/c0t0d0          Directory The media 
/etc/vx/reconfig.d/disk.d/c0t0d0/dmname   name for this disk
/etc/vx/reconfig.d/disk.d/c0t0d0/newpart  Subdisk layout
/etc/vx/reconfig.d/disk.d/c0t0d0/vtoc     VTOC

The contents of both the newpart and vtoc file are dependant on
the underlying disk geometry. This implies that a unique file
will need to be hand crafted for each disk geometry to be
encapsulated. The SEVM utility vxprtvtoc can be used to generate
the vtoc file, however the subdisk layout information and
offsets will still need to be manually calculated and created
for each disk.

Obviously, this procedure is a manual, labor intensive process
that is extremely susceptible to human error. Additionally, this
procedure requires the System Administrator to be intimately
aware of the disk geometry of every disk to be encapsulated. As
this procedure has so many opportunities for error and very few
checkpoints for verification, this technique can not be
recommended.

Automated Encapsulation From the Finish Script
Following is the JumpStart server finish script from Part 1 of
this series, augmented to automatically encapsulate the root
disk (c0t0d0) after installation of Solaris 2.6 Operating
Environment and the SEVM 2.6 software. The remainder of this
article assumes that the JumpStart server has been configured as
specified in Part 1. Also, as in Part 1, the JumpStart server
hostname is blackmesa and the install client hostname is
ravenswood. Licensing is taken care of by the Sun StorEdge
A5200's attached to ravenswood.

As with any installation procedure or script, this should be
thoroughly tested and understood before using. Initialization of
disks by SEVM re-partitions the disks, irrevocably erasing all
pre-existing data on the disks.

The finish script we are using for this example is:



     #!/bin/sh

     BASEDIR=/a
     SLASHAMNT=${BASEDIR}/mnt
     VXPRODUCT=${SLASHAMNT}/Product
     VXPATCH=${SLASHAMNT}/Patches
     RECON=${BASEDIR}/etc/vx/reconfig.d
     DISKD=${RECON}/disk.d
     STATED=${RECON}/state.d
     ROOTDEV=c0t0d0
     OK=0
     NOTOK=1
     mount -F nfs blackmesa:/JumpStart/sun_sevm_2_6 ${SLASHAMNT}
     if [ $? != 0 ]; then
     exit ${NOTOK}
     fi
     echo "Installing SUNWvxvm..."
     pkgadd -a ${SI_CONFIG_DIR}/noask -d ${VXPRODUCT} \
     -R ${BASEDIR} SUNWvxvm
     echo "Installing SUNWvxva..."
     pkgadd -a ${SI_CONFIG_DIR}/noask -d ${VXPRODUCT} \
     -R ${BASEDIR} SUNWvxva
     echo "Installing SUNWasevm..."
     pkgadd -a ${SI_CONFIG_DIR}/noask \
     -r ${SI_CONFIG_DIR}/SUNWasevm.response \
     -d ${VXPRODUCT} -R ${BASEDIR} SUNWasevm
     echo "Installing SUNWvmsa..."
     pkgadd -a ${SI_CONFIG_DIR}/noask \
     -r ${SI_CONFIG_DIR}/SUNWvmsa.response \
     -d ${VXPRODUCT} -R ${BASEDIR} SUNWvmsa
     echo "Installing SUNWvmman..."
     pkgadd -a ${SI_CONFIG_DIR}/noask -d ${VXPRODUCT} \
     -R ${BASEDIR} SUNWvmman
     echo "Installing SUNWvmdev..."
     pkgadd -a ${SI_CONFIG_DIR}/noask -d ${VXPRODUCT} \
     -R ${BASEDIR} SUNWvmdev
     echo "Preparing for encapsulation of c0t0d0 ..."
     #
     # If needed, setup software license would go here
     #
     # Create any disk exclusion and inclusion files
     #
     echo ${ROOTDEV} > ${RECON}/disks-cap-part
     echo c0t1d0 > ${RECON}/c0
                                     echo c0 > ${RECON}/cntrls
     #
     touch ${STATED}/init-cap-part
     touch ${STATED}/reconfig
     #
     mkdir -p ${DISKD}/${ROOTDEV}
     cat > ${DISKD}/${ROOTDEV}/newpart < ${DISKD}/${ROOTDEV}/dmname
     exit ${OK}



Note that the contents of the newpart file created with the
in-line input redirection (or "here is file") to the cat command
contains several commented commands. These commands are
commented out in the newpart file and are referenced later by
the SEVM software when the SEVM plexes and subdisks are created.


Conclusion

This article has provided the procedures to fully automate the
initial configuration of SEVM and automate encapsulation of the
boot disk. JumpStart application is a powerful and flexible tool
that enables the system administrator to have a fully automated
and customizable method to standardize installation and
configuration of the Solaris Operating Environment and unbundled
products. Additionally, JumpStart application provides a
framework to ensure uniformity and adherence to site standards
or conventions for all Solaris Operating Environment
installations. However, this power and flexibility requires
careful planning and testing by the System Administrator.

This article covered basic configuration and encapsulation of
the boot disk, and is meant to provide an examination of
advanced JumpStart configuration techniques. The techniques and
procedures presented here are a starting point for your storage
configuration. These procedures are the foundation for building
an automated implementation of reference configurations to be
presented in future articles.

================================================================================
At the start, ARP/RARP is used, so you at least need a "helper" (setup_install_server -b) in those alternate subnets.
In that case you, you can either copy the /install/sbin and /install/config and the first line of /etc/bootparams from morgancreek so you can run /install/sbin/aic.

Alternatively, run aic on morgancreek and just use the regular add_install_client on the "helper" but specify -s to find the right sysidcfg from morgancreek.

Depending on your physical network topology, you may choose to jumpstart clients using an alternate hostname, then change the hostname / subnet after the fact.

Really, the goal of this new jumpstart configuration is not so much to use it to jumpstart any one of your servers "in place" but rather as a means of generating a FLAR in a way that eliminates as many manual steps as possible.  You'll need to add Strong-specific customizations before it will fulfill that goal, but over time, one script at a time you can get closer and closer.

In the end, the traditional jumpstart process involved in what I've put together takes far far longer than restoring from a FLAR.  That's why I see this more as a means to an end for generating a consistent FLAR vs. using the long-hand JumpStart for every system, every time.
----
    Here are the details on how to use the new custom jumpstart environment on morgancreek.  This should serve as a useful starting point for you as the basis for loading systems, but more important it may serve as the basis for a jumpstart configuration that you may use to generate FLAR's on an ongoing basis (but with fewer manual steps).

    NOTE: The provided jumpstart configuration and scripts are fairly comprehensive for what they do.  They are provided "AS-IS" (e.g. you support them if you care to use them) and will hopefully prove useful for you.  If nothing else, they do offer an idea or concept for what you might choose to implement on your own, given enough time away from chasing fires.


    This basic jumpstart, "AS-IS" performs the following "base load" steps:

      1.. Install base OS 
      2.. Install patches 
      3.. Install add-on packages (example VxVM, VxFS, SunVTS, Sun Explorer) 
      4.. Install additional patches 
      5.. Configure nis/dns/ntp settings 
      6.. Optionally configure additional network interfaces

    All are customizable.  The general configuration may be extended by adding your own custom scripts to /install/sparc_custom/rc.install, prefixed according to the order you'd like them executed.  Scripts execute after the initial reboot and may perform virtually any system admin operation and may refer to files you might place in /install/config as $CONFIG/... or files in /install/sparc_custom as $CUSTOM/...

    This environment is architecture aware and may be readily extended to server Solaris x86 clients, by adding the media under /install/i86pc/5.8_XXXX and by adding a corresponding /install/i86pc_custom directory following the same format as the /install/sparc_custom directory, but with i86-specific packages and patches.


    The basic procedure for the Solaris 8 02/02 release is as follows.


      1.. Add jumpstart client hostname to DNS 
      2.. Have jumpstart client MAC address available (e.g. from Customer Information Sheets [yellow, ships with system]). 
      3.. Log into morgancreek. 
      4.. Become root 
      5.. CD to the Tools directory of the Solaris 8 02/02 media (as copied by setup_install_server and add_to_install_server from the distribution CD's).

      EXAMPLE:

           root@morgancreek# cd /install/sparc/5.8_0202/Solaris_8/Tools


      6.. Run /install/sbin/aic as you would normally run add_install_client, only you need not specify the -s option, because aic will first generate a sysidcfg file (among other things) and then call add_install_client, adding -s to any options you specify.  If you do specify a -s option, it will override the one generated by /install/sbin/aic.

      EXAMPLE (still in Tools directory, from #5):

           root@morgancreek# /install/sbin/aic -e 00:03:ba:12:8b:b5 cougar sun4u


      7.. From console of jumpstart client, start the jumpstart process.

      EXAMPLE:

         ok> boot net - install

      NOTE: That reads boot<space>net<space><minus><space>install 

================================================================================
PXE (Jumpstart DHCP x86-64 bootstrap)


	OK> boot net:dhcp - install

	NOTE: We will be discussing Solaris only in this doc, and not Linux.  
	They are similar, but not exactly the same in the loading process.

	SETUP OF JUMPSTART/PXE

		NOTE: CD-ROM data is not byte-nuetral, but DVD-ROM data is.
		If using CD-ROM, due to big/little endian issues (CPU architecture), 
		you must have a x86-64 server in the Jumpstart environment to serve 
		Solaris x86-64 code (this would be to server the code with NFS, the 
		x86-64 server does NOT need to be a Jumpstart server).
		
		NOTE: The x86-64 jumpstart x86 NFS server system must have a 
		CD/DVD-ROM and be part of the site's network and name service and 
		be a part of the name service (if name service is used).	

		1. x86-64 jumpstart x86 NFS server: Export CD/DVD media

		2. jumpstart Solaris server: 


	INSTALLING A CLIENT

	DHCP and TFTP.

	1. Client does a DHCPDISCOVER (port67) (which can be routed versus bootp).
	   Configured in BIOS, normally with F12.

	2. DHCP server (or proxy server) answers with IP config data and location 
	of a TFTP file.  DHCPOFFER is given (port 68).
	
		Client does a DHCPREQUEST (port 67).
		Client: Boot Service Discover (port 67 or 4011).
		
		NBP
			if bootenv.rc
				I/O definition for console
				boot path
			else
				interactive SCA

			after boot device is determined
			Solaris kernel (defined in DHCP macro) is loaded (TFTP: in.tftp) 
			TFTP (port 69) or MTFTP.
			PXE is done when kernel is in memory

		Boots kernel
			DHCP request for OS IP: DHCPDISCOVERYREQUEST


BOOTP	Boot Program
DCA		Device Configuratin Assistant
DHCP	Dynamic Host Configuration Protocal
GRUB    GRand Unified Bootloader
PXE		Preboot eXectution Environment
NBP 	Network Bootstrap Program
SCA		Solaris Configureation Assistant
TFTP 	Trivial File Transfer Program

================================================================================