era@niwot.scd.ucar.edu (02/27/90)
If you are running a mixed network which includes Suns and Silicon Graphics machines, it may be useful for you to know about the following problem. An Iris here was recently upgraded to v3.2 of SGI's OS. After the upgrade, none of the clients of a 3/280 on another part of our net would boot. We discovered that SGI's "bootp" program was replying to packets from Sun stations, even though those clients were not entered into bootp's configuration file. The following info was later received from a representative of SGI: > The problem you are seeing is caused by bug in our bootparamd code. When > the diskless Suns boot, they send a broadcast request for a name resolution. > Because we're a little faster, we answer this request, and the Sun gets the > idea that we will therefore have its bootfiles. Here the bootparamd code > should say "go to machine x" for your bootfiles, but instead, it just tries > to send bootfiles to the Sun, causing a crash (as you may have seen). > > The fix is available from anonymous ftp to sgi.sgi.com, then give your > real id as a passwd. Next cd to sgi/src, and do a binary get of README > and rpc.bootparamd.Z. When uncompressed, you can replace the current > /usr/etc/rpc.bootparamd with the new one, which will fix the problem. > > A workaround, which you may have discovered would be to comment out the > bootp entry in /etc/services. Ed Arnold * NCAR * POB 3000, Boulder, CO 80307-3000 * 303-497-1253(w) era@ncar.ucar.edu [128.117.64.4] * era@ncario.bitnet * era@ncar.uucp "See, the human mind is kind of like ... a pinata. When it breaks open, there's a lot of surprises inside." --Jane Wagner/Lily Tomlin