[ 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 ]