[  Next Article  |
Previous Article  |
Book Contents |
Library Home |
Legal |
Search ]
Network Installation Management Guide and Reference
Chapter 11. Network Installation Management Troubleshooting
This chapter suggests solutions for network 
boot problems and describes procedures for producing debug output for NIM BOS 
installations. Refer to Error and 
Warning Messages
 and AIX Version 4.3 Messages Guide and Reference 
for information about error messages.
Debugging a Network Boot Problem
If a client machine is unable to network 
boot from its boot server, there may be a problem in one or more of the 
following stages of the network boot:
The following sections describe steps that can 
be followed to determine the source of failures during each stage. 
Establishing Network Communication Between the 
Client and Server
- Before initiating the network boot 
on the client, perform a ping test from the client bootp menus. 
 
- If the ping test fails, verify that the 
client, server, and gateway addresses are specified correctly. 
 
- If the addresses are correct, try to ping the 
server from a different machine in the client's subnet. 
 
- If the server can be pinged from another 
machine, the network adapter on the boot client may be faulty. 
 
- If the server cannot be pinged from another 
machine in the client's subnet, there may be routing problems between the 
client and the server, or network communications on the server may be faulty. 
Perform network debugging procedures to determine the source of the problem. 
 
Obtaining the Boot Image from the Server
- If the ping test is successful, 
perform a network boot of the client. When a network boot is initiated on a 
client, a bootp request packet is sent from the client to the server. 
The server then replies with a packet to the client. The client machine 
displays the number of packets sent and received for the bootp request. 
If a packet is sent from the client, but none is received, another packet will 
be sent. 
 
- If bootp packets continue to be sent 
but not received, the boot server may not be responding to the request. 
 
- From the bootp server, view the 
/etc/bootptab file on the server. It should contain an entry for the 
client machine with the following information:
<hostname of client>
bf=<boot file>
ip=<client ip address>
ht=<network type>
sa=<boot server address>
sm=<client subnet mask>
ha=<network adapter hardware address> (required only if bootp
requests are sent by broadcasting)
If an entry does not exist, either the NIM command used to set up the current 
operation failed, or the machine was reset before the boot operation could 
occur. Rerun the NIM bos_inst, diag, or maint_boot operation to prepare the server for the client boot request. 
If the entry exists in /etc/bootptab, 
verify that the specified data is correct. If a field contains incorrect data, 
the information that was used to define the machine or network in the NIM 
database was probably wrong. Correct this problem by resetting the client 
machine, correcting the invalid data in the client or network definition, 
retrying the NIM operation, and rebooting the client. 
 
- If the /etc/bootptab file is correct, 
verify that the inetd daemon is running. If it is not running, start it 
and retry the network boot from the client. If the inetd daemon is 
running, it should automatically start the bootpd daemon when the 
bootp request is received at the server. 
 
- If the bootpd daemon is not started, 
verify that the bootps entry in the /etc/inetd.conf file is not 
commented out. If it is commented out, uncomment it and restart inetd 
with the refresh -s inetd command. Retry the network boot from the 
client. 
 
- If a bootp reply is still not received 
at the client, manually start the bootpd daemon in debug mode:
- Comment out the bootps 
entry from the /etc/bootptab file on the server. 
 
- Stop all running bootpd processes. 
 
- Restart inetd using the refresh -s 
inetd command. 
 
- Start bootpd from the command line 
using the /usr/sbin/bootpd -s -d -d -d command. 
 
 
- Retry to network boot from the client. If no 
output is displayed from the running bootpd command, the client 
bootp request is not reaching the server. Verify that the addresses 
specified in the bootp menus are correct. If they are correct, perform 
network debugging procedures to determine why the packet is not reaching the 
server. 
 
- If the server receives the client 
bootp request, the running bootpd command displays output 
matching the client data in the /etc/bootptab file. Verify that the 
specified addresses are correct. This information is sent back to the client in 
the bootp reply. 
 
- If the client is still not receiving the 
bootp reply, perform network debugging procedures to determine why the 
reply packet is not reaching the client. 
 
- After the client receives the bootp 
reply, it will tftp the boot image from the server. 
 
- The number of tftp packets transferred 
to the client will be displayed at the client machine. 
 
- The boot image has been successfully 
retrieved at the client machine when the LED shows 299 on rs6k-platform 
machines or when the bottom third of the screen turns gray on other platform 
machines. 
 
- If the tftp of the boot image does not 
complete successfully, the client may be trying to get the wrong boot image. 
Verify that the client definition in the NIM database shows the correct 
platform and kernel type. If the data is incorrect, correct it, reset the 
client machine, rerun the NIM operation, and reboot the client over the 
network. 
 
- Verify that the /tftpboot directory on 
the boot server contains a link with the client name to the correct boot image. 
If the link does not exist, reset the client machine, rerun the NIM operation, 
and reboot the client over the network. 
 
- If the link with the client name is pointing 
to the correct boot image and the tftp of the boot image does not 
complete successfully, the boot image may be corrupted. Recreate the boot image 
by performing a NIM check operation with the force flag on the 
SPOT. If the client is not an rs6k-platform machine, also make 
sure the client has the latest version of the firmware installed. 
 
Running the Boot Image on the Client
After the client machine has successfully 
received the boot image from the server, the most common errors encountered are 
hangs with the LED showing 608, 611, or 613. Some machines may not have LED 
displays. Debugging such problems on these machines will require using 
debug-enabled boot images. For information on building debug boot images, see 
Producing Debug Output from the 
BOS Install Program
. 
| 608  | 
  | 
| Explanation | 
  tftp retrieve of client info file failure.  | 
| Action | 
  If a 608 hang is encountered, verify that the ClientName.info 
file exists in the /tftpboot directory. If it does not exist, retry the 
NIM operation to create it. If it does exist, verify that tftp access to 
the /tftpboot directory is not restricted in the 
/etc/tftpaccess.ctl file. It is also possible that the network adapter 
was not configured properly in the boot environment. Use debug-enabled network 
boot images to look for errors in the boot environment. If the client is not an 
rs6k-platform machine, make sure that it has the latest version of 
firmware installed.  | 
| 611  | 
  | 
| Explanation | 
  Remote mount of NFS file system failure.  | 
| Action | 
  611 hangs occur when the client machine is unable to mount a 
resource from a server. Ensure that NFS is running on the resource server. 
Verify that the resources specified for the operation are exported properly by 
checking the /etc/exports and /etc/xtab files on the server. 
Also, confirm that the resources have permissions set correctly for reading. 
Debug-enabled network boot images can also be used to determine exactly which 
mount command is failing on the client.  | 
| 613 | 
  | 
| Explanation | 
  Failure setting up route tables. | 
| Action | 
  613 hangs usually occur because a route is incorrectly defined for a 
network in the NIM database. Verify that the correct gateways are specified 
between networks, and all gateways are functional. Use debug-enabled network 
boot images to determine which routes could not be defined.  | 
[  Next Article  |
Previous Article  |
Book Contents |
Library Home |
Legal |
Search ]