Checking Network Connections

1. Test the connection for Inst user access:

   % /usr/bsd/rsh server -l user date

   In the previous command, server is the name of the installation server and user is the user ID you are using for installation. Normally, user is "guest." If the date isn't returned, you've specified the wrong server, there is a network problem, or user isn't a valid user ID. (See "Configuring an Installation Account" for more information about user.)

2. Test the TCP/IP connection:

   Connections to installation servers are done over Terminal Control Protocol/Internet Protocol (TCP/IP) in a manner similar to rsh (see the rsh(1C) reference page). A simple test of this connection can be done by using ping (see the ping(1M) reference page:

   % /usr/etc/ping -q -f -s 2048 -c 100 server

   PING <server> (<IPaddress>): 2048 data bytes

   ----<server> PING Statistics----

   100 packets transmitted, 100 packets received, 0% packet loss

   round-trip (ms) min/avg/max = 0/2/7

   %

   In the previous example, server is the name of the installation server. If you see packet loss, you could have a problem with your network connection. If you receive a message that the host is unknown, verify the name of the host you are trying to contact and be sure you are typing it correctly.

   This network connection test is not possible if you are using Miniroot Installation; if you are, test the connection before beginning the installation, if possible.

3. Check the setting of the netaddr NVRAM variable.

   In some situations, you might have network problems if the IP address of your workstation in its non-volatile random access memory (NVRAM) doesn't match its IP address in /etc/hosts. A mismatch can occur when you move a workstation, but it does not cause a problem until you attempt to load the miniroot for a software installation. You can check the IP address in the NVRAM on your workstation while you are using IRIX by giving this command:

   % /etc/nvram netaddr

   From the Command Monitor, you can check the IP address in the NVRAM with this command:

   >> printenv netaddr

   If the four-part number returned from either command doesn't match the IP address in /etc/hosts on your workstation, you may be able to change it from IRIX (not all models of workstations support changing NVRAM from IRIX):

   # /etc/nvram netaddr localIPaddress

   Or change it from the Command Monitor:

   >> setenv netaddr localIPaddress

4. Verify that the installation server allows tftpd access (required for miniroot installation only).

   "Enabling TFTP Access on an Installation Server" describes the procedure for verifying that the installation server has been modified to allow tftp access (see the tftpd(1M) reference page).

   To get more debugging information, add the -l argument to the tftp line in /etc/inetd.conf and restart inetd (see the inetd(1M) reference page). The line should look like this:

   tftp dgram udp wait guest /usr/etc/tftpd tftpd -l

   Debugging information is written to /var/adm/SYSLOG.

5. Verify that routers between your workstation and the installation server forward bootp packets (see the bootp(1M) reference page).

   "Enabling BOOTP Forwarding on Routers" describes the procedure for verifying that routers have been modified to allow bootp access.

   To get more debugging information, add the -d argument to the bootp line in /etc/inetd.conf and restart inetd (see the inetd(1M) reference page). The line should look like this:

   bootp dgram udp wait root /usr/etc/bootp bootp -f -d

   Debugging information is written to /var/adm/SYSLOG.

Network Problem Diagnosis During an Inst Session

Here are some of the common error messages that might occur during a remote installation session:

-- Host 'host' is not responding, retrying

The remote host did not respond in a reasonable amount of time; we'll retry a few times before giving up. See the preference "network_retry" for a discussion of how to control the number of retries Inst makes before it gives up.

-- Timed-out waiting for 'host'

The remote host has timed out several times in a row. A serious network problem probably needs to be resolved before we can continue. Either resolve the network problem and continue the install, or cancel the install and try again later.

On a very slow network, changing the network timeout (by setting the preference "timeout" to the new timeout in seconds) may be necessary, though in general this is not recommended and will probably not cure a real network problem, but will only increase the length of time before such a problem is reported to the user.

-- Can't set up network connection to host host: reason

You were unable to establish an initial network connection to the remote host for the reason given. See "Checking Network Connections" for a discussion of what to do to test the network.

-- Lost connection to host

The network connection was broken. This probably means that the remote host is down.

-- No such host: host

The host is not listed in the host table. This could mean that the host's name was mistyped, that there's something wrong with the /etc/hosts file, or that the NIS or DNS server is down.

-- Couldn't parse ls output from remote host: 'ls_output'

Running an ls command on the installation server succeeded, but gave output different from what was expected. The only immediate solution is to install a different ls program (for example, a POSIX® compatible ls program) on the installation server.

-- Failed reading remote directory dir: error_msg

It was not possible to perform an ls command on the installation server. The given error string should give some clue as to the reason. Likely reasons:

• Illegal option: The installation server has an ls command that takes a different set of arguments from the ones the local ls command takes. The only immediate solution is to install a different ls program (for example, a POSIX-compatible ls program) on the installation server.

• Cannot access ... No such file or directory: The remote directory does not exist

• Cannot access ... Permission denied: The given user does not have sufficient permissions to access the directory.

-- Can't get shell/tcp network port to host host: error_msg

The service "exec" or "shell" was not found on the system. This probably means there's something wrong with the file /etc/services or the services map on the NIS server.

Network Problem Diagnosis During Miniroot Installation

-- unable to load bootp()machine:/path/sa(sash.IPXX)
-- bootp()machine:/path/sa(sash.IPXX) is not a valid file to boot

To find out if the file exists, enter the following command on the installation server:

# mkboottape -f /pathname/sa -l |grep sash

In the previous example, pathname is the distribution directory; for example, sa may be in dist:/irix/5.3.

Chances are the file does exist and this is probably a network problem--trying to bootp through too many gateways. Since the bootp protocol is not as robust as it could be, it is sometimes unable to find a file on a server if network traffic is heavy. By installing from an NFS mounted file system on a local network, NFS is dealing with the gateways and bootp is only going across the local network.

This can also occur when the server is a multi-homed machine.

-- no server for machine:/path/sa(sash.IPXX)

-- unable to load bootp()machine:/path/sa(sash.IPXX): file not found

This could mean that the netaddr variable is set incorrectly. From the command monitor, enter a printenv netaddr command and see if the address returned is set to an address on the local subnet (see "Preliminary PROM Monitor Procedure" for information on the netaddr variable).

-- Error 7 while loading network(0)bootp()mach1:/path/sa(sashARCS)

-- UX:csh: ERROR: ./.swindow - Command not found

The previous message might appear when loading from an automounted distribution (for example, machine:/hosts/...)

These errors indicate that you need to modify /etc/inetd.conf (/usr/etc/inetd.conf on pre-5.x systems) on the installation server (mach1 in this example) and remove the "-s /usr/local/boot /usr/etc/boot" from the tftpd entry (or alternatively, add the desired pathname to the end of the list of accessible paths after -s). Then restart inetd:

# /etc/killall -HUP inetd

-- panic free'ing mbuf while loading miniroot

This is a problem in the IP12 prom and in the IP20 prom.

Check your Ethernet cable--make sure that it is connected tightly to your machine. If you still see this problem, you can try to load the miniroot from a local machine via an NFS mount. This problem rarely occurs, and only when there is high network traffic.

-- Cannot load network(0)bootp()machine:/path

-- Problem reading file magic id, err 0 cnt0

This can mean network problems, such as a bad router between the current machine and the installation server.

-- Unable to load bootp()machine:/path: ''bootp()machine:/path'' is not a valid file to boot

You are trying to boot from a file that is not a valid sa image.

If you're booting from the command monitor, be sure to specify the sa file and not just the distribution directory containing the sa file.

-- File sash.XXX not found in machine:/path/sa, directory contains (listing)

You specified an unknown or unsupported machine type XXX when selecting the sash from which to boot. See "About Miniroot Installations" for more information.

-- No remote connection

This is probably an internal error resulting from trying to access a remote connection which used to be open but is now closed.

-- Unable to locate your password information (user-id UID)

Your current user ID is not a valid account on the system. This unlikely error probably means there's something wrong with the host table (/etc/hosts) or with the NIS server.

-- Can't open network connection: no hostname!

No remote hostname was given. You must supply the name of the network host.