SUMMARY: Diskless client won't boot (rpc call failed)

From: Peter Barneveld (Peter@metten.FenK.WAU.NL)
Date: Wed Apr 17 1996 - 05:56:14 CDT

Original message:

>> After a period of proper booting the clients now refuse to boot. The
>> symptom is as follows: when "boot" is entered at the monotor prompt, the
>> normal hex numbers appear on the screen. Instead of the usual hostname
>> message we then get:
>> RPC: Authentication error:
>> local: unkown error.
>> whoami RPC call failed with rpc status: 7
>> panic - boot: Could not mount filesystem.
>> The server and diskless client are running SunOS 5.4 patchlevel 36. All
>> further recommented patches are installed (although not always the latest
>> versions).
>> NIS nor NIS+ is used.

Sun came up with the suggestion to use the program 'snoop' to analyze the
IP traffic during the boot. After the tftp boot ends, the hostname is asked
through rpc calls or broadcasts, whatever. Snoop showed that, in response
to this request, the client receives error messages from SGI machines in an
entirely different subnet. It turned out that the system manager of the
SGI's changed the portmapper configuration a bit a few weeks ago. He
configured the software such that it should respond only to request from
within its own subdomain (as is advised in the Satan software doc's). So
the RPC: Authentication error: came from the SGI and not from our boot
server. Apparently there is a bug somewhere in Sun's rpc software. The
work-around that we use now is that the SGI portmapper config is changed
such that our subdomain is given permission to use their portmap services.
When we boot in this situation, snoop reports only trafic between boot
server and client, as should be the case; no packets from the SGI's are

Sun created a bug-id on this problem, namely 1246402.

BTW, the problem was not only with booting diskless nodes, but also with
starting certain software running on the server. For instance, we use
Helios ethershare for AppleTalk services. The atalkd (part of ethershare)
didn't boot during the time the SGI's had their security restrictions. With
the work-around described above, also these problems disappeared.

Thanks to all who responded,


This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:58 CDT