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]
[41]Solaris uses the name switch to specify the name service used by rpc.bootparamd. Remove NIS from the bootparams entry in /etc/nsswitch.conf and remove the "+" entry from /etc/bootparams to avoid using NIS. Once bootparamd is restarted, it will no longer use the bootparams NIS map.