=== Trouble-shooting ===

==> You see more than 5 "Timeout waiting for ARP/RARP responce"

Reason: RARP resolution doesn't work, i.e. rarpd can not or JUST DOESN'T CARE  to resolve client's MAC to IP. Check that:
- rarpd is running on the boot server
- that it's running with -a option OR listens exactly on the interface connected to the client's subnet
- Both NDS (or hosts) and ethers contain correct information, for instance:
/etc/hosts:
199.199.199.3 tmphost
/etc/ethers:
8:0:20:89:c3:29 tmphost

Avoid leading zeroes in MAC address! In /etc/ethers, it should look exactly the same as in RARP broadcast request which you can see by snoop.

Make sure that client IS PHYSICALLY CONNECTED to the subnet where its address is. If the thing is broadcasting on wrong subnet, rarpd doesn't care to respond even if can resolve the client's IP address. You may want to snoop for client's MAC address and AT THE SAME TIME start rarpd with -d key to see what exactly it is reading from network.

In your snoop session, you should see the RARP broadcast requests from the boot client, but no RARP responces from your boot server (admin workstation). If you don't see the RARP requests, then something is wrong with network or interface.

Some less obvious reasons for RARP failing are: exotic netmasks, inproperly configured switch ports, conflicting MAC or IP addresses, or just conflicting information in ethers and hosts databases. Make sure you do not mix up client's and server's MAC and IP addresses, as this can put the server itself in a very unastble state (like, it will stop resolving direct ARP). Look into ARP tables on the server and other machines on segment for any conflicting entries.

Finally, you may have to connect another pre-installed machine to that suspicious patch cable, configure the client's address and test if you can work through this wire with this address.

==> You see one or two RARP timeouts, or nothing at all after "boot net - install", and then it just freezes.

Reason: TFTP doesn't work.

In snoop session, you should see the TFTP requests asking to read the file XXXXXXXX (eight uppercase hexadecimal digits). Make sure this file exists in /tftpboot on the admin workstation and is world readable. This file may be a softlink to ./inetboot.* - this is OK, too. This link is normally created by bootserver script if the client's MAC address exists in /etc/ethers and corresponding IP address can be found in DNS or /etc/hosts. You also create such link by hand. Hex representation of IP address can be calculated by
awk -F. '{printf("%02x%02x%02x%02x\n",$1,$2,$3,$4)}' | dd conv=ucase

Make sure the tftpd line in /etc/inetd.conf is NOT commented out. Try to HUP the inetd again. If it doesn't work, trace (truss -p) the inetd and check if it ever tries to start tftpd at all. Normally, "bootserver stop" comments out the tftp line from inetd.conf and HUPs the daemon, and "bootserver start" does the opposite (i.e. enables tftp).

==> Client loads inetboot minikernel ("rolling numbers" on the screen) but freezes after that. Complains about BOOTPARAMD after few MINUTES.

Reason: BOOTPARAMD resolution doesn't work

Check if the bootparamd daemon is running on admin workstation, and /etc/bootparams file is not empty

Sometimes, tftp passes a corrupted inetboot image on heavily loaded networks. Try again :-( This never happens twice in a row.

Stop bootparamd and start in with -d key to see if it gets any requests at all

Client starts loading kernel:

SunOS version...
\/|-
but freezes, panics, or complains about NFS timeouts.

Reason: The root image is not properly exported on hcwe8l. Make sure anon=0 flag is there in "share" output.

Reason: root entry is wrong in bootparams (check NFS servers's name/address AND full path to the root image. Also, check if root image is PROPERLY exported o NFS server, i.e. the client has right to mount it. Sometimes, an Fully Qualified Name of the client must be specified in share commend, if this is a restricted sharing. Make sure that the client's name you specified in /etc/ethers is NOT an alias but a MAIN hostname, i.e. direct DNS lookup on name followed ba reversed DNS lookup on resulting address gives the same name again.

Most of other problems result from installation scripts and requre trouble-shooting of the root or config directories contents.