Managing NFS and NIS, 2nd Edition - Mike Eisler [103]
Debugging rarpd and bootparamd
You can debug boot parameter problems by enabling debugging on the boot server. Both rarpd and bootparamd accept a debug option.
By enabling debugging in rarpd on the server, you can see what requests for what Ethernet address the client is making, and if rarpd can map it to an IP address. You can turn on rarpd debugging by killing it on the server and starting it again with the -d option:
# ps -eaf | grep rarpd
root 274 1 0 Apr 16 ? 0:00 /usr/sbin/in.rarpd -a
root 5890 5825 0 01:02:18 pts/0 0:00 grep rarpd
# kill 274
# /usr/sbin/in.rarpd -d -a
/usr/sbin/in.rarpd:[1] device hme0 ethernetaddress 8:0:20:a0:16:63
/usr/sbin/in.rarpd:[1] device hme0 address 130.141.14.8
/usr/sbin/in.rarpd:[1] device hme0 subnet mask 255.255.255.0
/usr/sbin/in.rarpd:[5] starting rarp service on device hme0 address 8:0:20:a0:16:63
/usr/sbin/in.rarpd:[5] RARP_REQUEST for 8:0:20:a0:65:8f
/usr/sbin/in.rarpd:[5] trying physical netnum 130.141.14.0 mask ffffff00
/usr/sbin/in.rarpd:[5] good lookup, maps to 130.141.14.9
/usr/sbin/in.rarpd:[5] immediate reply sent
Keep in mind that when starting a daemon with the -d option, it usually stays in the foreground, so you won't get a shell prompt unless you explicitly place it in the background by appending an ampersand (&) to command invocation.
The two things to look out for when debugging rarpd are:
Does rarpd register a RARP_REQUEST? If it doesn't, this could indicate a physical network problem, or the server is not on the same physical network as the client.
Can rarpd map the client's Ethernet address back to an IP address? If not, this could indicate a bad ethers map, a bad /etc/ethers file, or an /etc/nsswitch.conf file that is not pointing at the right place.
By enabling debug mode in bootparamd on the server, you can see the hostname, addresses, and pathnames given to the diskless client. You can turn on bootparamd debugging by killing it on the server and starting it again with the -d option:
# ps -eaf | grep bootparamd
root 276 1 0 Apr 16 ? 0:00 /usr/sbin/rpc.bootparamd
root 5878 5825 0 00:33:27 pts/0 0:00 grep bootparamd
# kill 276
# rpc.bootparamd -d
in debug mode.
msg 1: group = 260 mib_id = 0 length = 128
msg 2: group = 261 mib_id = 0 length = 132
msg 3: group = 1025 mib_id = 0 length = 36
msg 4: group = 1026 mib_id = 0 length = 64
msg 5: group = 260 mib_id = 20 length = 144
msg 6: group = 260 mib_id = 100 length = 88
msg 7: group = 1026 mib_id = 1 length = 0
msg 8: group = 1026 mib_id = 2 length = 0
msg 9: group = 260 mib_id = 21 length = 2464
msg 10: group = 260 mib_id = 22 length = 360
mibget getmsg( ) 11 returned EOD (level 0, name 0)
interface_addr = 130.141.14.8.
interface_mask = 255.255.255.0
22 records for ipRouteEntryTable
Whoami returning name = honeymoon, router address = 130.141.14.253
getfile_1: file is "honeymoon" 130.141.14.8 "/export/root/honeymoon"
The messages that start with msg are the results of asking the IP layer for Simple Network Management Protocol (SNMP) Management Information Base (MIB) information. The bootparamd daemon makes this inquiry to find the IP address of the best router for the diskless client. The messages that say group = 260 are the ones of interest for this purpose. Of those messages, the ones with a mib_id of 0 or 20 are of interest. Normally both kinds of messages will appear. If not, that may indicate a problem with the server's network configuration. But if there are no problems, we can expect the debug output to show a router address for the client.
The getfile_1 message is simply reporting that it knows where the client's root filesystem is. Note the IP address is the same as the server's interface, which means that the NFS server for the client is the same as the bootparamd server.
If the server shows strange boot parameters passed to the client, check that the server's /etc/bootparams file is correct, and that the boot server's NIS server has up-to-date maps.
If the boot parameters received by the client are incorrect,