SLXT and existing SunOS/Solaris networks
You can break existing, network-boot, Sun clients by installing
the SLXT package on your network.
If you have Sun diskless, dataless or AutoClient systems on your network,
you should read and fully understand the following information before
attempting to install the SLXT package.
Because of the way in which the Sun boot PROM works, diskless, dataless
and AutoClient systems will assume that the server which answers the
client's initial, broadcast RARP request will also answer subsequent
bootparams requests. This means that installing the SLXT package on
a server other than the existing boot server on your Sun network can,
under certain circumstances, cause your Sun clients to fail to boot.
This can happen when:-
- The server chosen to support SLXT clients is not the
same machine as the server supporting the existing, diskless,
Sun clients.
- The SLXT server shares service information (ie:- ethers,
hosts, bootparams, etc) with the existing server via NIS or
NIS+.
In these circumstances the SLXT server can, especially if it is lightly
loaded as compared to the existing server, answer RARP requests first.
Because the SLXT server shares the ethers map, it can correctly provide
the MAC to hostname mapping for the Sun client, but, because it does
not have correct /tftpboot entries for the client and isn't running the
bootparams daemon, the client is still unable to boot.
If your existing diskless clients fail to boot, you should kill the tftp
(or rarpd) daemon on your SLXT server (and disable it in /etc/inetd.conf)
and try to reboot the client again.
If the client still fails to boot, check the client console messages.
- "Lost Carrier" indicates that you have a
cable/network problem and it is nothing to do with the SLXT
server.
- "RARP/ARP send error" also indicates a cable or
network problem (not SLXT).
- "Waiting for ARP/RARP packet" indicates that neither
your Sun nor SLXT server is responding to client broadcasts and
you probably do not have the client MAC address in the ethers
file/map, or you have the client plugged into the wrong sub-net.
- No console messages (after the initial "Boot device:
net...") usually mean that your SLXT server
is answering the initial ARP/RARP request
and that the client has bound to it and is waiting for further
packets.
- "receive failed" can also mean that your SLXT
server has answered the ARP/RARP request but has failed to
provide the client with a second stage boot file.
If you're seeing the last two symptoms, halt the SLXT server and try
again. If you still have problems, then there may be a third machine
on the network answering ARP/RARP requests.
At this stage you need to use "snoop" (SunOS/Solaris) or
"tcpdump" to identify what other machines on the network
are talking to your client.
If in any doubt, halt the SLXT server.
Last updated: $Date: 2003/05/18 08:25:02 $.
Gaijin@pobox.COM