Causes of an LED 611 During a sysback Network Boot


Contents

About this document
      Related documentation
Causes of an LED 611
Causes and recovery procedures

About this document

This document gives a summary of the causes and recovery procedures for an LED 611 during a Sysback network boot. The information in this document has been verified for AIX Versions 3.2, 4.1, 4.2 and 4.3. It has also been verified for sysback.obj 3.3.3 and sysback.rte 4.1.x.x.

Related documentation

The following document is also recommended.

"Causes of an LED 610 During a Sysback Network Boot", document #8579

The product documentation library is also available:
http://www.rs6000.ibm.com/resource/aix_resource/Pubs/index.html


Causes of an LED 611

An LED 611 occurs when the Network File System (NFS) mount of the /usr file system from the server fails during a Sysback network boot.


Causes and recovery procedures

When the following conditions result in an LED 611, perform the solutions shown:

  1. The /etc/exports file does not have the correct permissions for the client to mount /usr.

    SOLUTION

    Enter the following command:

        exportfs 
    

    Look for the line starting with /usr. Make sure the client host name is included on the line.

    EXAMPLE

        /usr -ro, root=node1,node2 
    

    In the preceding example, only node1 and node2 are exported to NFS mount /usr. If your client's host name is not included on that line, add the network boot client as follows:

    1. Enter:
          smitty sysback 
      
    2. Choose one of the following:
          Configuration Options 
          Network Boot Configuration 
          Add or Change a Network Boot Client 
      
    3. Make sure each entry is filled in correctly, as shown:
      Client network adapter type             [token-ring] 
      Client platform/kernel type             [rspc] 
      Client hostname                         [mars.aix.dfw.ibm.com] 
      Server IP address                       [9.19.129.186] 
      Client gateway address (optional)       [9.19.141.241] 
      Client subnet mask (optional)           [255.255.240.0] 
      Client adapter hardware address (optional)    [] 
      
    4. Verify by entering the following command:
          exportfs 
      

      Look for the line starting with /usr. Make sure the client host name is included on the line.

  2. The /etc/exports file does not have an entry for /usr.

    SOLUTION

    Enter the following command:

        exportfs 
    

    If there is no entry for /usr in the /etc/exports file, follow the steps in the "Solution" section of step 1.

    The following error message may occur when adding the network boot client:

    Configuring network boot for client... thumper.aix.dfw.ibm.com
        /usr ro,root=thumper.aix.dfw.ibm.com 
    Starting NFS and BOOTP services...
        exportfs: /usr: sub-directory (/usr/lpp) already exported 
        /usr not found in /etc/exports 
    

    The preceding messages indicate that the client has been configured but you must correct the problem with the export function before booting the client.

    1. Enter:
          exportfs 
      

      If a subdirectory for /usr that is not a file system is already in the /etc/exports file, then you cannot export the parent directory /usr.

      Example output from the exportfs command is shown below:

          /usr/sys/inst.images -rw 
          /usr/lpp             -root=mars,access=mars 
      

      In this example, /usr/sys/inst.images is its own file system but /usr/lpp is still part of /usr file system. You cannot export /usr until you remove /usr/lpp from the /etc/exports file. See step b.

    2. Enter the following command to remove /usr/lpp from the /etc/exports file.
          /usr/sbin/rmnfsexp -d /usr/lpp  -B 
      

    3. Re-add the network boot client as described in step 1.

    4. Verify by entering the following command:
          exportfs 
      

      Look for the line starting with /usr. Make sure the client host name is included on the line.

  3. This could be a defect that existed in sysback.obj 3.3.1.x - 3.3.3.5. It is fixed with sysback.obj 3.3.3.17.

    [an error occurred while processing this directive]