[ Previous | Next | Table of Contents | Index | Library Home |
Network Installation Management Guide and Reference
This chapter suggests solutions
for network boot problems and describes procedures for producing debug output
for NIM BOS installations. Refer to Chapter 10, Error and Warning Messages for information about error messages.
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
- 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
- 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>
ip=<client ip address>
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
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
- 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
- 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
- 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
- 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.
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.
||tftp retrieve of client info file failure.
||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
||Remote mount of NFS file system failure.
||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.
||Failure setting up route tables.
||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
[ Previous | Next | Table of Contents | Index |
Library Home |