15.3. 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.
[41]
 |  |  |
| 15.2. Renegade NIS server |  | 15.4. Incorrect directory content caching |
