🚀 go-pugleaf

Before:  We've got an all-Sun Ethernet, with a 3/280 acting as a server
         for a diskless 3/60 (among other machines).  All is well.

After:   We attach an SGI 4D/70G to the Ethernet.  We can no longer boot
         the 3/60.

Diagnosis:  The 4D/70G's "bootparamd" daemon is responding to the 3/60's
requests for boot parameters; since we'd failed to tell the SGI about boot
parameters for Sun machines, the 3/60 gets a useless answer and can't
boot.

Cure:  We make the information in the 3/280's "/etc/bootparams" file
available to the 4D/70G.  (Another tack would be to comment out the
"bootparamd" line in the 4D/70G's "inetd.conf" file; I decided against
this to avoid changing a vendor-supplied file.)

The Question:  Who's to blame--
* Me, for not having taken the "cure" step in the first place?
* The 4D/70G, for responding to boot parameter requests of
  machines it knows nothing about?
* Or the 3/60, for paying attention to useless responses?

	Arthur David Olson   ado@alw.nih.gov   ADO is a trademark of Ampex.