Diagnosing Network Boot Issues

When configuring a network, sometimes boot and installation will not work at all or will not work as expected. Especially when configuring a complex network, you should expect to spend time diagnosing and resolving issues due to the complexity of the network and interactions between servers. You should also expect that problems might occur in the future as the complex network changes.

This section includes suggested tools and techniques for diagnosing problems.

HP-UX Diagnosing and Debugging

Simple Network Debugging

If network boot is used on a local subnet and the Ignite-UX server is not found, check these items:

Verify the client is on the same subnet as the Ignite-UX server or boot helper.
Investigate instl_bootd errors in /var/adm/syslog/syslog.log.
In the /var/adm/inetd.sec file, ensure the service instl_boots exists, and that the IP address 0.0.0.0 is allowed. (Normally, all addresses are allowed via 0.0.0.0.) The entry should look like:
instl_boots allow 0.0.0.0
If /etc/services comes from NIS, make sure the NIS server has instl_boot* entries.

Logging to `syslog.log`

The bootpd and tftpd daemons have the ability to log requests and responses. The /etc/inetd.conf file may be modified to enable logging. The bootpd -d option and tftpd -l option control logging. For example:

# tftp dgram udp wait root /usr/lbin/tftpd tftpd \
     -l /opt/ignite /var/opt/ignite
# bootps dgram udp wait root /usr/lbin/bootpd bootpd -d 9

The daemons log to the HP-UX syslog file located at /var/adm/syslog/syslog.log.




	NOTE: Logging should normally be disabled since it can consume a significant amount of disk space.

If the boot configuration includes multiple boot servers (for bootp relay, for example) it is often useful to enable logging on all servers.

Using bootpquery

To save time when configuring an HP-UX system boot, the bootpquery command may be used to simulate a network boot request by requesting bootpd to indicate how it would respond to boot requests for a specific MAC address. This is normally much faster and simpler than attempting to boot using a real client system.

To use bootpquery, add the ba option to the appropriate entries in the /etc/bootptab file. Without this option, bootpd will send responses only to the client system making the boot request. The ba option requests the response be broadcast on the subnet, so any system is able to see the response, including the system where you are using bootpquery. For more information, see bootpquery(1M).




	NOTE: The ba option should be removed once testing is completed.

The bootpquery output includes valuable debug information:

# bootpquery 0011855F549E
Received BOOTREPLY from hpignite.xyzco.com (10.1.1.11)

Hardware Address:          00:11:85:5f:54:9e
Hardware Type:             Ethernet
IP Address:                10.1.1.110

Boot file:                 /opt/ignite/boot/nbp.efi

RFC 1048 Vendor Information:
    Subnet Mask:            255.255.255.0
    Gateway:                10.1.1.1
    Bootfile Size:          24576 512 byte blocks
    Domain Name Server:     10.1.1.1
    Host Name:              hpuxsys1
    Domain Name:            xyzco.com

RDP Diagnosing and Debugging

An RDP server can be configured to log PXE boot and TFTP activity. The PXE Configuration Utility may be used to control logging. Logging should be disabled when you are finished diagnosing and debugging.

Diagnosing Network Boot Issues

Technical documentation

» Table of Contents

» Glossary

» Index

HP-UX Diagnosing and Debugging

Simple Network Debugging

Logging to `syslog.log`

Using bootpquery

RDP Diagnosing and Debugging

Diagnosing Network Boot Issues

Technical documentation

» Table of Contents

» Glossary

» Index

HP-UX Diagnosing and Debugging

Simple Network Debugging

Logging to syslog.log

Using bootpquery

RDP Diagnosing and Debugging

Logging to `syslog.log`