Sun Management Center Change Manager 1.0 Administration Guide

Software Deployment Problems

The following troubleshooting issues relate to the deployment of software to managed hosts.

Custom JumpStart Installation Launches the Interactive Installation Program

Description:

If the installation program detects an invalid parameter or parameter value in a shared profile or in host properties, the hands-off installation terminates. Then, the interactive installation program launches so you can correct the problem or otherwise continue with the installation.

This scenario occurs if you provide an invalid parameter value. For information about custom JumpStart keywords, see "Preconfiguring System Configuration Information (Tasks)" in Solaris 9 Installation Guide.


Note -

The custom JumpStart keywords correspond to the Change Manager parameters, but the names are different. The Change Manager parameters begin with the base_config_ string, but the content part of the string matches closely to the custom JumpStart keyword names. To see a description of the Change Manager parameters, see Chapter 10, Creating Shared Profiles and Host Properties (Reference).


Cause:

The installation program detects the parameter problem, but cannot correct it. The custom JumpStart installation cannot continue, so it launches the interactive installation program.

Solution:

To correct the problem, review the parameters and parameter values for the managed host that failed to perform the custom JumpStart installation.

Ensure that the parameters and parameter values are correct. See Chapter 10, Creating Shared Profiles and Host Properties (Reference) for a description of the parameters specified in shared profiles and by host properties.


Note -

Be careful when copying the encrypted root password from /etc/shadow to the shared profile. Do not include the colon (:) field delimiters as part of the base_config_sysidcfg_rootpw property value.


If you find the problem and correct it, restart the initial installation.

If you do not find the problem, review the parameters and parameter values in the shared profile or in the host properties.


Note -

If you are installing only one managed host, you might continue with the interactive installation. This solution is not advisable unless you are installing just one managed host with a simple software stack.


Managed Host Hangs While Booting From the Network (4656587)

Description:

While loading the bootstrap, the managed host hangs. You can tell when the bootstrap is being loaded because of the hex count to 24000.

This problem might occur more often when the network is heavily loaded.

Cause:

An in.tftpd bug causes this intermittent failure. As a result of this bug, the transfer hangs.

Solution:

Reset the hanged managed host. Try the network boot again.

Panic: unable to mount file systems Message Appears While Booting From the Network

Description:

The network boot of your managed host might fail with an error message such as:


Panic: unable to mount file systems

If such a message appears, then your managed host is probably being served by more than one network boot server.

You must first identify all network boot servers on which your managed host is registered, other than the Change Manager server.

Solution:

Use the hostconfig(1M) command to identify the network boot servers on which your managed host is a client.

Perform the following steps to determine whether your managed host is a client of more than one network boot server:

  1. Remove your managed host from the Change Manager server from which you want to boot.

    1. Use the browser interface or the command-line interface to remove your managed host from the Change Manager topology.

    2. Log in to the boot server as superuser.

    3. Change to the Tools directory of the Solaris boot image associated with the Solaris version you want to install.

    4. Run the rm_install_client command to remove the entries for your managed host from the /etc/bootparams file.


      # ./rm_install_server hostname
      
  2. Run the hostconfig command to determine whether your managed host is a client of another network boot server.


    $ hostconfig -p bootparams -f hostname -n -v
    
  3. See if the hostconfig command identifies a network boot server for your managed host.

    • If an IP address appears in square brackets on the first line of output, your managed host is a client of another boot server. The IP address represents the boot server.


      From [192.153.72.132]: hostname = host1
      	ypdomain = yourCompany.COM
      	router = 192.153.72.1
    • If no IP address appears, then your managed host is not a client of a boot server. Go to Step 7.

  4. Determine the name of the boot server specified by the IP address.

    If you use the NIS naming service, for example, use ypmatch(1) to associate the IP address with the host name of the boot server.


    $ ypmatch 192.153.72.132 hosts.byaddr
    129.153.72.132  cmserver
  5. Repeat Step 1b to Step 4 to remove your managed host entries from the /etc/bootparams file on the boot server.

  6. Repeat Steps 2-4 to find additional boot servers.

  7. When no more boot servers are indicated by the hostconfig command, add your managed host to the Change Manager topology of the Change Manager server. Set up the files for installation. Then, restart the boot net - install from your managed host's console.

Interactive Installation Program Launched When Files For Non-Existent Managed Hosts Not Cleaned Up (4721489)

Description:

When the last reference to a managed host is removed from the Change Manager topology, the custom JumpStart data is not deleted.

The /etc/bootparams file still contains entries corresponding to the managed hosts.

The /var/opt/ichange/jsdata/hostname directories still contain boot environment information and custom JumpStart configuration files.

Extraneous /etc/bootparams entries for a managed host can cause problems. For example, if more than one Change Manager server has the same managed host registered, each server answers the call from that managed host. This situation produces excess traffic and unknown results on the managed host.

Solution:

Manually clean up the following files on the Change Manager server:

  • Find a Solaris miniroot, which might be located in the Change Manager repository under /var/opt/ichange/root. Change directory to the Tools subdirectory, for example, /var/opt/ichange/root/s9.miniroot/Solaris_9/Tools. Then, as superuser, type:


    # ./rm_install_client hostname
    

  • Delete the host-specific directories from the /var/opt/ichange/jsdata directory.