7 Troubleshooting RIS

This chapter contains information to help you troubleshoot problems with your RIS system. Problems covered are categorized as:

7.1 RIS Lock Files

To prevent multiple users from performing operations on RIS areas simultaneously, the ris utility creates two lock files in the /tmp directory, rislock and ris.tty.lock. when a user is installing or deleting software from a RIS area. If the ris utility is run by another user or the same user on a different terminal, selecting INSTALL software products or DELETE software products from the RIS Utility Main Menu generates a message similar to the following:

The ris utility is currently locked while j_smith on //dev/ttyp3
is installing software.  Try again later.

If the ris utility is stopped prematurely, these lock files may not be removed. If the lock files are not removed, the message displays even though no other user is using RIS.

If this occurs, you must delete the lock files from the /tmp directory.

Caution

Before deleting the lock files, ensure that no other user is using the ris utility.

7.2 Client Password Expiration

If the RIS server is using C2 security and the RIS password has been set to allow expiration, it is possible for the RIS clients to be denied service. If the RIS client receives a message similar to the following, the RIS password on the server probably has expired:

Cannot find the name for client using bin/getname. Check with the system
manager of your RIS server

To fix this problem, refer to Section 3.6.

7.3 Root File System Mounting

The installation media is mounted as the root file system for installation. This occurs in both the case of CD-ROM installation and RIS installations, so it is important that the installation media is mounted locally on the server. Due to NFS limitations, RIS cannot provide client access to files that are mounted remotely from another system. The distribution media or extracted RIS area must be available through a local mount point on the RIS server.

7.4 RIS Client Registration

Problems with RIS client registration that are discussed in this section include the following topics:

No prompt for client hardware address

Duplicate client hardware addresses

Cloned client registration

Client registered on multiple RIS servers

Client not in RIS database

7.4.1 No Prompt for Client Hardware Address

The server requires a client's hardware address in order to boot the client over the network. The ris utility prompts you for the client's address during the registration process. If it does not, check the following:

If the RIS area is linked to a CD-ROM
Check that the CD-ROM that is the target of the links is mounted.

If the RIS area is serving a version prior to Version 3.0
Check that the mandatory update subsets for the release the server is serving are installed in the server's RIS area. Install the mandatory update subsets from the /local_mnt /ALPHA/UPDATE directory on the distribution CD-ROM. For example, if the CD-ROM is installed on /mnt, install the mandatory update subsets from the /mnt/ALPHA/UPDATE directory.

If the RIS area is serving Version 3.0 and later
Check that the mandatory operating system subsets are installed into the RIS area. Install the mandatory subsets from the /local_mnt /ALPHA/BASE directory on the distribution CD-ROM. For example, if the CD-ROM is installed on /mnt, install the mandatory update subsets from the /mnt/ALPHA/BASE directory.

Note

The client can use the setld utility to load optional subsets or layered product subsets over the network. See the System Administration guide and the setld(8) reference page for more information about loading subsets with the setld utility.

7.4.2 Duplicate Client Hardware Addresses

RIS checks to ensure that no other client has the same hardware address. This can happen if a client's name has changed but has not been removed from the server. If a duplicate hardware address is found, a message is displayed like the one in the following example:

The hardware address provided, 08-00-2B-39-BA-BE, has already been 
specified for another client, albany. Please check the hardware address
to ensure it is correct. If it is correct, then you will need to
deregister the client albany before continuing. If this client is not
currently registered, please contact your RIS system administrator.

If you see this message, follow the instructions provided:

Verify that the new client hardware address you entered is correct. If it is not correct, reregister the new client with the correct hardware address.

If the hardware address you entered is correct, deregister the existing client (in this example, albany), and reregister the new client.

If the existing client is not registered, contact your RIS system administrator.

7.4.3 Cloned Client Registration

A CDF is created as a result of a full installation. To use the CDF for installation cloning, the hardware configuration and the software subsets to load must be substantially similar. Before specifying a CDF for client installation cloning, RIS attempts to verify that the subsets specified in the CDF exist in the RIS area that the user has selected. If they do not match, the CDF is rejected. This error can occur if the version numbers of the subset do not match (for example, OSFBASE400 and OSFBASE440).

The CDF can be used for installation cloning of a system that is registered to a different RIS area. In this first case, it is possible that the subsets contained in these RIS areas are different.

The version of operating system served by the RIS area can be different from the version specified in the CDF. In this second case, there would be many missing subsets because none of the subsets specified in the CDF would be present in the RIS area.

In the event that a CDF is specified that contains the name of a software subset that is not present in the selected RIS area, the following message is displayed:

Enter a CDF name or press <Return> to exit CDF selection: rz26.cdf
 
The selected CDF, rz26.cdf, specifies software subsets that are not
present in the selected RIS environment. The missing software subsets are:
OSFSERPC440
 
Please select a different CDF.

7.4.4 Client Registered on Multiple RIS Servers

If the system will not boot or the system boots but is not able to mount the root file system, you should check to ensure that the RIS client is not registered for bootp service on multiple RIS or DMS servers. In order for the bootp protocol to work properly, it is important that the client be registered for bootp service on only one server. The client is registered for bootp service when they are registered for an operating system base product or when the client is registered as a DMS client.

It is possible for a RIS client to be registered to two RIS servers at the same time, given they are not both registered for the operating system base product on both servers and attempt to boot their systems using bootp.

7.4.5 Client Not in RIS Database

If a message appears on the client's console while you are performing a RIS installation that states that the client is not in the RIS database, check the following on the server:

As shown in Section 7.5, check /var/adm/ris/clients/risdb to ensure the client's name is properly entered. If it is not, use the ris utility to add or modify the client's registration. Do not edit the risdb file directly; use the ris utility.

If /var/adm/ris/clients/risdb contains the correct client name, you must determine the client's name as recognized by the name servers (for example, BIND or NIS). If no name servers are in use, check the /etc/hosts file. The client name must appear in the /etc/hosts file exactly as it appears in /var/adm/ris/clients/risdb. The /etc/hosts file contains the name by which the client is known at the server. The /var/adm/ris/clients/risdb database contains the name by which the client is known to RIS. The two names must match. If you are using the BIND or NIS name servers, use the nslookup command to find the name by which the client is known to the server.
If the /etc/hosts file or the name server and /var/adm/ris/clients/risdb both include the client, but one file uses the short client name and the other file uses the fully qualified domain name, you will have a problem. You may be able to solve the problem by editing the /etc/hosts file to include both the short and fully qualified domain name.
If you found a discrepancy between the files where /etc/hosts used the short name and /var/adm/ris/clients/risdb used the fully qualified domain name, you most likely have an error in your network configuration. It is recommended that you review the procedures used to configure your network and name servers and correct them before continuing with RIS installations.

7.5 RIS Server Response

Problems with RIS server response comprise several categories. Topics discussed in this section include the following:

Servers using the bootp daemon

Servers using the joind daemon

Loading an incorrect kernel file

Boot failures often occur because the RIS server has invalid information. The risdb and bootptab files are involved in handling RIS clients, and you should check them in the order listed:

/var/adm/ris/clients/risdb
This file is created and managed by the ris utility; it contains the utility's view of the environment. Run the ris utility to show the configuration for the client in question. Verify that the client is registered and that its registration information is correct. If not, use the ris utility to add or modify the client's registration.

/etc/bootptab (Tru64 UNIX servers only)
This file is not used exclusively by RIS which means that it can be edited for other purposes (such as Dataless Management Services), and the entry for your client could have been corrupted. Examine the client's bootptab entry to ensure that the entry agrees with both the risdb entry and the addresses and parameters of the equipment in your environment. The contents of the /etc/bootptab file are described in the bootptab(4) and joind(8) reference pages and in Section 5.1.3.

Caution

A RIS server should run either the bootpd or the joind daemon. A RIS server running both of these daemons is not supported, and results are unpredictable.

7.5.1 Servers Using the bootp Daemon

A server can respond to bootp requests from clients. If the server's information is correct for the client, but the server still fails to respond, enable logging of bootp messages on the server by editing the server's /etc/inetd.conf file and by modifying the line for bootps to include the -d option as a bootpd command argument. For example:

bootps  dgram   udp   wait   root   /usr/sbin/bootpd   bootpd -d

Then, find the process IDs for the Internet daemons. Send a HUP (hangup) signal to the inetd daemon so it will reread the /etc/inetd.conf configuration file, and kill the bootpd daemon. For example:


# ps x | egrep "inetd|bootpd"
  228 ??  I      0:00.93 /usr/sbin/inetd
  243 ??  I      0:00.91 /usr/sbin/bootpd
 9134 p2  S      0:00.23 egrep inetd|bootpd
# kill -HUP 228
# kill -KILL 243

Caution

You must kill the inetd daemon before killing the bootpd daemon.

It is not necessary to restart the bootpd daemon manually; the inetd daemon starts it automatically.

To track boot requests as they occur, run the tail -f command on the /var/adm/syslog.dated/today's-date /daemon.log file and boot the client. Many daemons other than the bootpd daemon log information to the daemon.log file; however, the log file shows a hardware address that matches the address in the /etc/bootptab file for the client.

If the client's boot requests are not logged, you can enable additional logging by editing the /etc/inetd.conf file, and add a second -d option to the bootpd command. Each additional instance of the -d option (up to three) increases reporting; the second instance enables the server to report all boot requests, even for client systems it does not recognize. This level of reporting should help you determine where in the system the request is being lost.

If you modify the /etc/inetd.conf file, restart the inetd daemon by sending it a HUP signal. Example 7-1 shows a section of a daemon.log file. It shows the data logged by various system daemons, including the bootpd daemon when run with two -d flags set.

Example 7-1: Sample daemon.log File

Jul 28 14:56:36 stlouis mountd[191]: startup
Jul 28 14:56:38 stlouis xntpd[235]: xntpd version 1.3                   [1]
Jul 28 14:56:43 stlouis mold[269]: mold (V1.10) initialization complete
Jul 28 14:56:44 stlouis evd[272]: E003-evd (V1.10) initialization complete
Jul 28 14:56:45 stlouis internet_mom[275]: internet_mom - Initialization
                complete...
Jul 28 14:56:45 stlouis snmp_pe[278]: M004 - snmp_pe (V1.10) initialization
                complete
Jul 28 16:34:55 stlouis inetd[282]: /usr/sbin/bootpd: exit status 0x9   [2]
Jul 28 16:35:47 stlouis bootpd[1228]: bootpd 2.1a #0: \                 [3]
                Fri Feb 05 00:32:28 EST 1999
Jul 28 16:35:47 stlouis bootpd[1228]: reading "/etc/bootptab"
Jul 28 16:35:47 stlouis bootpd[1228]: read 3 entries from "/etc/bootptab"
Jul 28 16:35:47 stlouis bootpd[1228]: request from hardware address \   [4]
                08002B2C9C6F
Jul 28 16:36:08 stlouis bootpd[1228]: request from hardware address \   [5]
                08002B309668
Jul 28 16:36:08 stlouis bootpd[1228]: found: host1.dec.com (08002B309668)
                at (16.69.224.83)
Jul 28 16:36:08 stlouis bootpd[1228]: file /var/adm/ris/ris0.alpha/\
                vmunix.host1.dec.com
Jul 28 16:36:08 stlouis bootpd[1228]: vendor magic field is 0.0.0.0
Jul 28 16:36:08 stlouis bootpd[1228]: sending RFC1048-style reply

Many daemons log information to this file. [Return to example]

Result of sending a HUP signal to the inetd daemon and killing the bootpd daemon. [Return to example]

A new bootpd daemon starts up in response to a boot request. The bootpd daemon reads the /etc/bootptab file as a part of its startup. [Return to example]

A bootpd request by a system with hardware address 08002B2C9C6F. Because the system is not a client of this RIS server, its hardware address is not in the server's /etc/bootptab file. [Return to example]

A bootpd request by a system with hardware address 08002B309668. The system is a client of this RIS server. [Return to example]

7.5.2 Servers Using the joind Daemon

To serve bootp requests from clients, the joind daemon, which also services Dynamic Host Configuration Protocol (DHCP) requests, should be running. DCHP enables the automatic assignment of IP address to clients on networks from a pool of addresses. The IP address assignment and configuration occurs automatically whenever appropriate client systems (workstations and portable computers) attach to a network. The current implementation of DHCP is based on the JOIN product by Competitive Automation. Ensure that the server's information on the client is correct, namely information contained in the bootptab file of the server as shown in Section 5.1.3. If the server still fails to respond, enable logging of bootp messages on the server by using the following procedure:

Check that the joind daemon is servicing your bootp request. This can be done by issuing the following command:

# ps -x | grep -E "joind"
393 ??       I        0:05.82 /usr/sbin/joind
26446 ttyp0     S +     0:00.01 grep -e joind

Determine the current setting of JOIND_FLAGS by issuing the following:
```
# rcmgr get JOIND.FLAGS
```

Stop the joind daemon by issuing the following command:
```
# /sbin/init.d/dhcp stop
```

Restart the daemon with debugging turned on by doing the following. Set the JOIND_FLAGS to indicate debugging is turned on.
```
# rcmgr set JOIND_FLAGS y -dx
   Where x is the level of debugging. A value from 0 to 9 is valid.
   Where y is the previously determined setting of the JOIND_FLAGS.
# /sbin/init.d dhcp start -dx
```
Example 7-1 shows a section of a daemon.log file. It shows the data logged by various system daemons, including the joind daemon.

To turn off debugging, do the following:


# /sbin/init.d/dhcp stop
# rcmgr set JOIND_FLAGS y
    Where y is the previous determined setting of the JOIND_FLAGS.
@    determined.
# /sbin/init.d dhcp start

7.5.3 Loading an Incorrect Kernel File

If the server responds, but an incorrect kernel (vmunix) is loaded, it is possible that the server's RIS area is configured incorrectly. You can observe the loading process by editing the /etc/inetd.conf file and restarting the Internet daemon as described in the previous section. In this case you add the -d option to the line containing the tftpd command, as follows:

tftp	dgram	udp	wait	root	/usr/sbin/tftpd	tftpd -d /tmp /var/adm/ris

Logging the server's tftp traffic shows you what file is being transferred and what time the transfer is started and finished. Ensure that the proper vmunix file is being loaded and that the loading operations are completed correctly.