Managing NFS and NIS, 2nd Edition - Mike Eisler [231]
Boot parameter confusion
Different vendors do not always agree on the format of responses to various broadcast requests. Great variation exists in the bootparam RPC service, which supplies diskless nodes with the name of their boot server, and pathname for their root partition. If a diskless client's request for boot parameters returns a packet that it cannot understand, the client produces a rather cryptic error message and then aborts the boot process.
As an example, we saw the following strange behavior when a diskless Sun workstation attempted to boot. The machine would request its Internet address using RARP, and receive the correct reply from its boot server. It then downloaded the boot code using tftp, and sent out a request for boot parameters. At this point, the boot sequence would abort with one of the errors:
null domain name
invalid reply
Emulating the request for boot parameters using rpcinfo located the source of the invalid reply quickly. Using a machine close to the diskless node, we sent out a request similar to that broadcast during the boot sequence, looking for bootparam servers:
% rpcinfo -b bootparam 1
192.9.200.14.128.67 clover
192.9.200.1.128.68 lucy
192.9.200.4.128.79 bugs
lucy and bugs were boot and root/swap servers for diskless clients, but clover was a machine from a different vendor. It should not have been interested in the request for boot parameters. However, clover was running rpc.bootparamd, which made it listen for boot parameter requests, and it used the NIS bootparams map to glean the boot information. Unfortunately, the format of its reply was not digestible by the diskless Sun node, but its reply was the first to arrive. In this case, the solution merely involved turning off rpc.bootparamd by commenting it out of the startup script on clover.
If clover supported diskless clients of its own, turning off rpc.bootparamd would not have been an acceptable solution. To continue running rpc.bootparamd on clover, we would have had to ensure that it never sent a reply to diskless clients other than its own. The easiest way to do this is to give clover a short list of clients to serve, and to keep clover from using the bootparams NIS map.[1]
* * *
[1] Solaris uses the name switch to specify the name service used by rpc.bootparamd. Remove NIS from the bootparams entry in /etc/nsswitch.conf and remove the "+" entry from /etc/bootparams to avoid using NIS. Once bootparamd is restarted, it will no longer use the bootparams NIS map.
Incorrect directory content caching
A user of a Solaris NFS client reported having intermittent problems accessing files mounted from a non-Unix NFS server. The Solaris NFS client tarsus was apparently able to list files that had previously been removed by another NFS client, but was unable to access the contents of the files. The files would eventually disappear. The NFS client that initially removed the files did not experience any problems and the user reported that the files had indeed been removed from the server's directory. He verified this by logging into the NFS server and listing the contents of the exported directory.
We suspected the client tarsus was not invalidating its cached information, and proceeded to try to reproduce the problem while capturing the NFS packets to analyze the network traffic:
[1] tarsus$ ls -l /net/inchun/export/folder
total 8
-rw-rw-rw- 1 labiaga staff 2883 Apr 10 20:03 data1
-rw-rw-rw- 1 root other 12 Apr 10 20:01 data2
[1] protium$ rm /net/inchun/export/folder/data2
[2] tarsus$ ls /net/inchun/export/folder
data1 data2
[3] tarsus$ ls -l /net/inchun/export/folder