Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

System Administration Guide: Basic Administration
Previous Next

Troubleshooting Diskless Client Problems

This section describes problems that are encountered when managing diskless clients and possible solutions.

Troubleshooting Diskless Client Installation Problems

The smosservice add command does not install any packages that are designated ARCH=all in the root (/) or /usr file systems. As a result, these packages are skipped. No warning or error messages are displayed. You must add these packages to the newly-created Solaris OS service manually. This behavior has existed since the Solaris 2.1 OS. The behavior applies to both SPARC based and x86 based clients. Note that the list of missing packages varies, depending on which Solaris OS you are running.

How to Locate and Install Missing ARCH=all Packages

This procedure shows you how to locate and install missing ARCH=all packages after you have created the Solaris OS service on the server. Examples that are provided in this procedure apply to the Solaris 10 6/06 OS.

  1. Locate all the packages with the ARCH=all parameter.
    1. Change directories to the Product directory of the media for the Solaris 10 image. For example:
      % cd /net/server/export/Solaris/s10u2/combined.s10s_u2wos/latest/Solaris_10/Product
    2. List all the packages in the pkginfo file that have the ARCH=all parameter.
      % grep -w ARCH=all */pkginfo

      If an error message indicating the arguments list is too long is displayed, you can alternately run the following command to generate the list:

      % find . -name pkginfo -exec grep -w ARCH=all {} /dev/null \;

      Note that running this command takes longer to produce results.

      The output is similar to the following:

      ./SUNWjdmk-base/pkginfo:ARCH=all
./SUNWjhdev/pkginfo:ARCH=all
./SUNWjhrt/pkginfo:ARCH=all
./SUNWjhdem/pkginfo:ARCH=all
./SUNWjhdoc/pkginfo:ARCH=all
./SUNWmlibk/pkginfo:ARCH=all

      The information that is provided in this list enables you to determine which packages are installed in the /usr file system and which packages are installed in the root (/) file system.

    3. Check the value of the SUNW_PKGTYPE parameter in the package list you generated.

      Packages that belong in the /usr file system are designated as SUNW_PKGTYPE=usr in the pkginfo file. Packages that belong in the root (/) file system are designated as SUNW_PKGTYPE=root in the pkginfo file. In the preceding output, all the packages belong in the /usr file system.

  2. Become superuser or assume an equivalent role.

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

  3. Create the temporary installation administration files.

    You must create a separate installation administration file for packages that are installed in the root (/) file system and a separate installation administration file for packages that are installed in the /usr file system.

    • For ARCH=all packages that are installed in the /usr file system, create the following temporary installation administration file:

      # cat >/tmp/admin_usr <<EOF
mail=
instance=unique
partial=nocheck
runlevel=nocheck
idepend=nocheck
rdepend=nocheck
space=nocheck
setuid=nocheck
conflict=nocheck
action=nocheck
basedir=/usr_sparc.all
EOF
#

    • For ARCH=all packages that are installed in the root (/) file system, if any exist, create the following temporary installation administration file:

      # cat >/tmp/admin_root <<EOF
mail=
instance=unique
partial=nocheck
runlevel=nocheck
idepend=nocheck
rdepend=nocheck
space=nocheck
setuid=nocheck
conflict=nocheck
action=nocheck
EOF
#
  4. Install the missing ARCH=all packages.
    1. If the current directory is not the Product directory of the media for the Solaris 10 image, change directories to that directory. For example:
      # cd /net/server/export/Solaris/s10u2/combined.s10s_u2wos/latest/Solaris_10/Product

      You can run the pwd command to determine the current directory.

    2. Install the missing ARCH=all packages in the /usr file system.
      # pkgadd -R /export/Solaris_10 -a /tmp/admin_usr -d `pwd` [package-A package-B ...]

      Multiple packages can be listed when you running the pkgadd command.

    3. Check that the ARCH=all packages were installed.
      # pkginfo -R /export/Solaris_10 [package-A package-B ...]
    4. Install the missing ARCH=all packages that in the root (/) file system.

      Note that it is possible that none of these packages exist.

      # pkgadd -R /export/root/clone/Solaris_10/sun4u -a /tmp/admin_root -d `pwd` [package-X package-Y ...]
    5. Check that the ARCH=all packages were installed.
      # pkginfo -R /export/root/clone/Solaris_10/sun4u [package-X package- ...]
  5. After you have finished adding the missing ARCH=all packages, remove the temporary installation administration file.
    # rm /tmp/administration-file
Example 7-10 Locating and Installing Missing ARCH=allPackages

This example shows how to install the missing ARCH=all package, SUNWjdmk-base, in the /usr file system.

% uname -a
SunOS t1fac46 5.10 Generic_118833-02 sun4u sparc SUNW,UltraSPARC-IIi-cEngine

% cat /etc/release
                       Solaris 10 6/06 s10s_u2wos_03 SPARC
           Copyright 2006 Sun Microsystems, Inc.  All Rights Reserved.
                        Use is subject to license terms.
                           Assembled 06 February 2006

% cd /net/ventor/export/Solaris/s10u2/combined.s10s_u2wos/latest/Solaris_10/Product

% grep -w ARCH=all */pkginfo
Arguments too long

% find . -name pkginfo -exec grep -w ARCH=all {} /dev/null \;
./SUNWjdmk-base/pkginfo:ARCH=all
./SUNWjhdev/pkginfo:ARCH=all
./SUNWjhrt/pkginfo:ARCH=all
./SUNWjhdem/pkginfo:ARCH=all
./SUNWjhdoc/pkginfo:ARCH=all
./SUNWmlibk/pkginfo:ARCH=all

% grep -w SUNW_PKGTYPE=usr ./SUNWjdmk-base/pkginfo ./SUNWjhdev/pkginfo ...
./SUNWjdmk-base/pkginfo:SUNW_PKGTYPE=usr
./SUNWjhdev/pkginfo:SUNW_PKGTYPE=usr
./SUNWjhrt/pkginfo:SUNW_PKGTYPE=usr
./SUNWjhdem/pkginfo:SUNW_PKGTYPE=usr
./SUNWjhdoc/pkginfo:SUNW_PKGTYPE=usr

% grep -w SUNW_PKGTYPE=root ./SUNWjdmk-base/pkginfo ./SUNWjhdev/pkginfo ...

% su
Password: xxxxxx # cat >/tmp/admin_usr <<EOF mail= instance=unique partial=nocheck runlevel=nocheck idepend=nochec> k rdepend=nocheck space=nocheck setuid=nocheck conflict=nocheck action=nocheck basedir=/usr_sparc.all EOF

# pwd
/net/ventor/export/Solaris/s10u2/combined.s10s_u2wos/latest/Solaris_10/Product

# pkginfo -R /export/Solaris_10 SUNWjdmk-base 
ERROR: information for "SUNWjdmk-base" was not found

# pkgadd -R /export/Solaris_10 -a /tmp/admin_usr -d `pwd` SUNWjdmk-base

Processing package instance <SUNWjdmk-base> </net/ventor/export/Solaris/s10u2/combined.s10s_u2wos...


Java DMK 5.1 minimal subset(all) 5.1,REV=34.20060120
Copyright 2005 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
Using </export/Solaris_10/usr_sparc.all>
## Processing package information.
## Processing system information.

Installing Java DMK 5.1 minimal subset as <SUNWjdmk-base>

## Installing part 1 of 1.
2438 blocks

Installation of <SUNWjdmk-base> was successful.

# pkginfo -R /export/Solaris_10 SUNWjdmk-base
application SUNWjdmk-base Java DMK 5.1 minimal subset

# rm /tmp/admin_usr

Troubleshooting General Diskless Client Problems

This section lists some common problems with diskless clients that you might encounter and possible solutions.

Problem: Diskless client reports Owner of the module /usr/lib/security/pam_unix_session.so.1 is not root, when attempting to log in, the /usr file system is owned by nobody.

Solution: To correct the problem, follow this workaround:

  1. Using a text editor, modify the diskless client's server:/export/root/client/etc/default/nfs file.

  2. Change the #NFSMAPID_DOMAIN=domain line to the following:

    NFSMAPID_DOMAIN=the_same_value_as_in_server's_/var/run/nfs4_domain

  3. Ensure that the OS server and the diskless client have the same nfsmapid domain. To verify this information, check the /var/run/nfs4_domain file.

    Caution - If the diskless client's nfs4_domain file contains a different value than the OS server's /var/run/nfs4_domain file, you will not be able to log in to the system after the diskless client boots.

  4. Reboot the diskless client.

For more information, see Chapter 3, NFS Tunable Parameters, in Solaris Tunable Parameters Reference Manual and nfsmapid(1M).

Problem: The OS server fails to do the following:

  • Respond to client Reverse Address Resolution Protocol (RARP) requests

  • Respond to client bootparam requests

  • Mount a diskless client root (/) file system

Solution: The following solutions apply in a files environment.

  • Verify that files is listed as the first source for hosts, ethers, and bootparams in the /etc/nsswitch.conf file on the OS server.

  • Verify that the client's IP address appears in the /etc/inet/hosts file.

    Note - If you are not running at least the Solaris 10 8/07 release, you must also verify that the client's IP address appears in the /etc/inet/ipnodes file.

    In this Solaris release, there is no longer two separate hosts files. The /etc/inet/hosts file is a single file that contains both IPv4 and IPv6 entries. You do not need to maintain IPv4 entries in two hosts files that always require synchronization. For backward compatibility, the /etc/inet/ipnodes file is replaced with a symbolic link of the same name to the /etc/inet/hosts file. For more information, see the hosts(4) man page.

  • Verify that the client's Ethernet address appears in the /etc/ethers file.

  • Verify that the /etc/bootparams file contains the following paths to the client's root (/) directory and swap areas.

    client root=os-server:/export/root/client swap=os-server:
/export/swap/client

    The swap size varies depending on whether you specify the -x swapsize option when you add the diskless client. If you specify the -x dump option when you add the diskless client, the following line is present.

    dump=os-server:/export/dump/client dumpsize=512

    The dump size varies depending on whether you specify the -x dumpsize option when you add the diskless client.

  • Verify that the OS server's IP address appears in the /export/root/client/etc/inet/hosts file.

Problem: The OS server fails to do the following:

  • Respond to client RARP requests

  • Respond to client bootparam requests

  • Mount a diskless client root (/) file system

Solution: The following solutions apply in a name service environment.

  • Verify that both the OS server's and the client's Ethernet address and IP address are correctly mapped.

  • Verify that the /etc/bootparams file contains the paths to the client's root (/) directory and swap areas.

    client root=os-server:/export/
root/client swap=os-server:/export/
swap/client swapsize=24

    The swap size varies depending on whether you specify the -x swapsize option when you add the diskless client. If you specify the -x dump option when you add the diskless client, the following line is present:

    dump=os-server:/export/dump/client dumpsize=24

    The dump size varies depending on whether you specify the -x dumpsize option when you add the diskless client.

Problem: Diskless client panics

Solution: Verify the following:

  • The OS server's Ethernet address is correctly mapped to its IP address. If you physically moved a system from one network to another, you might have forgotten to remap the system's new IP address.

  • The client's host name, IP address, and Ethernet address do not exist in the database of another server on the same subnet that responds to the client's RARP, Trivial File Transfer Protocol (TFTP), or bootparam requests. Often, test systems are set up to install their OS from an install server. In these cases, the install server answers the client's RARP or bootparam request, returning an incorrect IP address. This incorrect address might result in the download of a boot program for the wrong architecture, or a failure to mount the client's root (/) file system.

  • The diskless client's TFTP requests are not answered by an install server (or previous OS server) that transfers an incorrect boot program. If the boot program is of a different architecture, the client immediately panics. If the boot program loads from a non-OS server, the client might obtain its root partition from the non-OS server and its /usr partition from the OS server. In this situation, the client panics if the root and /usr partitions are of conflicting architectures or versions.

  • If you are using both an install server and an OS server, verify that the following entry exists in the /etc/dfs/dfstab file.

    share -F nfs -o -ro /export/exec/Solaris_version-instruction-set.all/usr

    where version= 8, 9,10, 11, and instruction-set=sparc or i386.

  • Verify that the diskless client's root (/), /swap, and /dump (if specified) partitions have share entries: 

    share -F nfs -o rw=client,root=client /export/root/client 
share -F nfs -o rw=client,root=client /export/swap/client 
share -F nfs -o rw=client,root=client /export/dump/client

  • On the OS server, type the following command to check which files are shared:

    % share

    The OS server must share /export/root/client and /export/swap/client-name (defaults), or the root, /swap, and /dump partitions that you specified when you added the diskless client.

    Verify that the following entries exist in the /etc/dfs/dfstab file:

    share -F nfs -o ro /export/exec/Solaris_version-instruction-set.all/usr
share -F nfs -o rw=client,root=client /export/root/client
share -F nfs -o rw=client,root=client /export/swap/client

Problem: OS server is not responding to diskless client's RARP request

Solution: From the client's intended OS server, run the snoop command as superuser (root) by using the client's Ethernet address:

# snoop xx:xx:xx:xx:xx:xx

Problem: Boot program downloads but panics early in the process

Solution: Use the snoop command to verify that the intended OS server is answering the client's TFTP and NFS requests.

Problem: Diskless client hangs.

Solution: Restart the following daemons on the OS server:

# /usr/sbin/rpc.bootparamd
# /usr/sbin/in.rarpd -a

Problem: Incorrect server responds to diskless client's RARP request

Solution: Restart the following daemons on the OS server:

# /usr/sbin/rpc.bootparamd
# svcadm enable network/rarp
Previous Next

 
 
  Published under the terms fo the Public Documentation License Version 1.01. Design by Interspire