djk@cs.mu.OZ.AU (David Keegel) (06/05/90)
We have some Irises and Suns on the same Ethernet. When we try to reboot a diskless Sun, the Iris responds to the request and tries to boot it. Needless to say, this doesn't work, and the Sun gets very confused. The Iris in question (uno.cs.mu.oz.au) _is_ a server for another diskless Iris (due.cs.mu.oz.au), but I can't find a way to get uno to only boot due (which is want (I think) I want). I've tried ftping sgi.com:sgi/src/rpc.bootparamd.Z and installing that, but it doesn't seem to have helped. Uno's /etc/bootparams only has due listed, and /usr/etc/bootptab only has due after the "%%". Apologies if this is a well-known question, but I've only started reading comp.sys.sgi recently (I seem to remember seeing something about it in comp.sys.sun some time ago, though). -- David Keegel (djk@cs.mu.OZ.AU) Arthur: "What's so unpleasant about being drunk?" Ford: "You ask a glass of water that."
bernie@umbc5.umbc.edu (Bernard J. Duffy) (06/09/90)
In article <DJK.90Jun5191117@murgon.cs.mu.OZ.AU> djk@cs.mu.Oz.AU writes: >We have some Irises and Suns on the same Ethernet. When we try to >reboot a diskless Sun, the Iris responds to the request and tries to >boot it. Needless to say, this doesn't work, and the Sun gets very >confused. The Iris in question (uno.cs.mu.oz.au) _is_ a server for >another diskless Iris (due.cs.mu.oz.au), but I can't find a way to >get uno to only boot due (which is want (I think) I want). This happened to us. The problem was with SGI's bootparam responding to a net "boot me" request without making a clean check with it's bootptab file. In our case we had an empty bootptab file (no disk less nodes to be booted) and it was confusing the suns on the same ethernet. Our solution, which won't work for you was to turn off the bootp* inet port listeners so it couldn't respond. > >I've tried ftping sgi.com:sgi/src/rpc.bootparamd.Z and installing >that, but it doesn't seem to have helped. Uno's /etc/bootparams only >has due listed, and /usr/etc/bootptab only has due after the "%%". I remember seeing some solution coming accross this news group a while ago that patched that faulty bootp*d program(s). I'm sure SGI knows about this problem and has a solution. I just don't know whether it's include in 3.2[.0]; the problem occurred with 3.1 and I haven't check to see if it's fixed. ** SGI folks: let me know if this is fixed so I can leave the /etc/services file in standard setup. > David Keegel (djk@cs.mu.OZ.AU) > Enjoy, Bernie Duffy Systems Programmer II | Bitnet : BERNIE@UMBC2 Academic Computing - L005e | Internet : BERNIE@UMBC2.UMBC.EDU Univ. of Maryland Baltimore County | UUCP : ...!uunet!umbc3!bernie Baltimore, MD 21228 (U.S.A.) | W: (301) 455-3231 H: (301) 744-2954
jesse@camelot.sgi.com (Jesse Rendleman) (06/09/90)
This problem is fixed in the 3.2.2 maintenance release.