When you reinstall a system, the /var/statmon/sm directory is wiped out. In this case, if the reinstalled system tries to recontact a server that has cached information, the server will try to communicate over an old RPC port. The communication will fail for rpc.lockd and any file locking done by an application over that NFS mount will hang.

There are a several ways to avoid and/or fix the problem if it happens:

•If you are using bootsys to install clients, use the -soption to allow the client to shutdown normally and inform servers that it is going down.

•If you experience a hang, you can reboot the client or kill/restart rpc.lockd and rpc.statd on the client. At the point of the hang, the /var/statmon/sm directory will contain the name of the server, thus rebooting or restarting the daemons will tell the server to flush its cache. If more than one server is involved, you may end up doing this multiple times until all servers are notified.

•As part of the installation, create a file for each server in /var/statmon/sm that contains the server’s name. This will cause the first boot to generate a crash recovery notification message to each server, causing it to purge the stale port information. Following is an example post_config_cmd that could be placed in your /var/opt/ignite/config.local file. Replace sys* with your NFS server names.

post_config_cmd += " mkdir -p /var/statmon/sm

for server in sys1 sys2 sys3 do

echo $server > /var/statmon/sm/$server chmod 0200 /var/statmon/sm/$server

done

"

The bootsys Command Seems to Work in Reverse

With bootsys -wclient, the client does not wait for the server. With bootsys client, the client waits for the server.

This was probably due to running through the GUI once on the server prior to running bootsys. The server drops the instruction for the client to start installing, and the next time the client boots it picks that instruction up and goes. Ignite-UX tells you that the installation will happen the next time bootsys -wis used, but does not say it happens automatically. Then, the next time you run bootsys, you did not use the GUI without the client being booted from the server.

Server Not Listed

The search lan install command does not list the server.

Check these items on the Ignite-UX server from which you are trying to boot:

•Messages from instl_bootd /var/adm/syslog/syslog.log. If you need to add more IP addresses to /etc/opt/ignite/instl_boottab, you will see messages in syslog.log such as the following:

instl_bootd: Denying boot request for host: 080009F252B3 to avoid IP address collision. Try booting again in 214 seconds, or add more IP addresses to /etc/opt/ignite/instl_boottab.

•A message in syslog.log that indicates that you have no IP addresses in /etc/opt/ ignite/instl_boottab is:

instl_bootd: No available IP address found in: /etc/opt/ignite/instl_boottab

•If the client is an older system that does not use the BOOTP protocol (like 720s, 710s, 735s, 750s), then also look in the log file /var/adm/rbootd.log, and check to make sure the

228 Troubleshooting