Sometime back i wrote :
>
> Hello sun managers,
>
> I have a sun 3/60, a diskless machine which boots off of a
> sun 3/280 both running 4.1. The other day one of the users switched the
> machine off and turned it on and it has hung since then.
> It identifies what its name is and what domain it belongs to and
> also who its server is and then tftp's data from the server. After that it
> hangs saying
> Requesting ethernet address for 128.193.114.2 = ( hex # )
> Here 128.193.114.2 is the gateway to our outside world and the ip # of the
> server is 128.193.112.1 and the client that refuses to boot is 128.193.112.101
> I have looked at the /etc/ethers, bootparams and also the associated NIS info
> which we run on our network and it all looks fine to me.
> What we could diagnose is that the client is asking for some information which
> the client is not set up to give, namely the address of the gateway. Is there
> a way i can force it to proceed ignoring this information? or is there a bug
> ( an obvious one ;-) that I have not looked at? Any help will be > appreciated!
> Thanks in advance
I got responses from 4 people on the list :
Mike Raffety <miker@sbcoc.com> wrote :
----------------------------------------------------------------------------
Perhaps your bootparams gives the name of the wrong interface on the
server (le1 versus le0)? Or the /etc/fstab of the host specifies the
root or /usr partition is mounted from some host off the local Ethernet
segment?
Please be sure to summarize back to the list; thanks.
----------------------------------------------------------------------------
I double checked my /etc/bootparam and found that I was exporting the proper
stuff. Also added fully qualified hostnames just to make sure, but no success.
vasey@issi.com (Ron Vasey) wrote :
----------------------------------------------------------------------------
The key is just what's in the file(s), but where the daemons are running
(rarpd and bootparamd) and what info they read (file or NIS). Be sure
both bootparamd and rarpd are running on the server you want to boot from
AND that daemons on another server (with possibly bad info or no info)
aren't intercepting your client's requests. This frequently happens with
Sparcs and Sun3s on the same network -- the Sparcs win every time. :^)
----------------------------------------------------------------------------
It sounded like a good idea to me and so i turned off DNS on the other machines
on our network, which are faster (being a sparc 2 and an ipx ) than the
server which is a 3/60. But this was kind of close to the problem that we were
actually having. Put me on the right track though.
cxh@bell.berkeley.edu wrote :
----------------------------------------------------------------------------
Sent me a long mail;-) Thanks!! It basically gave the name of the ftp site
titan.rice.edu from where i got a bootparamd and a program called callbootd.
By running this you can find out how far the diskless client has gotten in its
reboot and how much information it has like : disk, swap , root . Kind of
informative to me as i could determine that the diskless client had all this
information but was choking on something else.
----------------------------------------------------------------------------
kla!brandari%sunra@Sun.COM (Paul Brandariz x6546) wrote :
----------------------------------------------------------------------------
Try booting with
> b -v
This was helpful too as i got more debugging information as to where the
diskless client was choking.
----------------------------------------------------------------------------
lidl@sura.net wrote :
----------------------------------------------------------------------------
some explation of how arp and rarp work. Thanks for the info!!
He suggessted that i flush the routing tables and restart the routed again.
I tried that as some conflicts might have arisen with the NIS servers on
the net.
But this also did not produce any results.
----------------------------------------------------------------------------
steve@archone.tamu.edu wrote:
----------------------------------------------------------------------------
Why dont u create a file
80C17202 --> boot.sun3.sunos4.1.1
which the gateway address translated to hex.
I did try this before i sent out the query , but it also did not work.
----------------------------------------------------------------------------
The ANSWER:
The problem was due to the DNS service. We do not do our own Nameservice
Another node on our campus does it for us. The problem that was happening was
due to the fact that our gateway 128.193.114.2 and the machine which was
acting as our gateway 128.193.112.1 were named the same. So when the
diskless machine tried to get stuff it looked for 128.193.114.2 ( the gateway)
and to do so it had to go thro 128.193.112.1 ( the machine ). So it was caught
in a flux without knowing how to get to the gateway and then on to the
client. So the solution was to change the DNS tables at the other node on
campus such that the gateway and the machine were called different names and
lo and behold the diskless client rebooted!!
Thanks a lot to all the people who sent me their answers.
satish
----------------------------------------------------------------------------
Satish Srinivas home : (503) 757 9560
srinivs@sequoia.fsl.orst.edu office : (503) 737 5547
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:38 CDT