![]() | ![]() |
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:# 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
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, check that the server answering the request for them has current information. Because requests are broadcast to bootparamd, the server that can reply in the shortest time supplies the information. If the client refuses to boot at all, complaining of:# 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"
or similar problems, verify that the host answering its broadcasts is using the same boot protocol and configuration files. See Section 15.3, "Boot parameter confusion" for an example of invalid boot parameters. Also ensure that the boot server exports the client's root and swap filesystems with the proper root mapping and access restrictions. In /etc/dfs/dfstab, both the root and swap filesystems should have the options:null domain name invalid domain name invalid boot parameters
to limit access to the diskless client and to allow the superuser to write to the filesystems. If the swap filesystem is not exported so that root can write to it, the diskless client will not be able to start the init process to begin the single-user boot.rw=client,root=client
In this example, we would check /export/exec/Solaris_2.7_sparc.all/usr on the server wahoo. The directories in /export/exec have names with this format: Solaris_<release>_<architecture>. If the client and the server are of the same CPU architecture and are running the same release of the operating system, the usr subdirectory in /export/exec/Solaris_<release>_<architecture> is a symbolic link to the server's /usr directory. If the client and server do not have the same release and CPU architectures, the directories in /export/exec contain complete operating system releases. Three things can go wrong with this link-and-directory scheme:wahoo:/export/root/honeymoon - / nfs - - rw wahoo:/export/swap/honeymoon - /dev/swap nfs - - - wahoo:/export/exec/Solaris_2.7_sparc.all/usr - /usr nfs - - ro
If commands are executed properly, then you should be able to mount /usr safely on the diskless client in question.client# mount wahoo:/export/exec/Solaris_2.7_sparc.all/usr /mnt client# cd /var client# /mnt/bin/ls 4lib dict krb5 oasys sbin ucblib 5bin dist kvm old share vmsys X dt lib openwin snadm xpg4 adm games lost+found platform spool aset include mail preserve src bin java man proc tmp ccs java1.1 net pub ucb demo kernel news sadm ucbinclude
![]() | ![]() | ![]() |
8.5. Changing a client's name | ![]() | 8.7. Configuration options |
Copyright © 2002 O'Reilly & Associates. All rights reserved.