SUMMARY : cannot boot a sun3 diskless client. Any suggestions?

From: srinivs@thuja.FSL.ORST.EDU
Date: Mon Mar 09 1992 - 06:54:04 CST

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 = ( hex # )

> Here is the gateway to our outside world and the ip # of the
> server is and the client that refuses to boot is

> 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 <> 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

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. (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. wrote :
Sent me a long mail;-) Thanks!! It basically gave the name of the ftp site 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.
---------------------------------------------------------------------------- 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.
---------------------------------------------------------------------------- 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 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 and the machine which was
acting as our gateway were named the same. So when the
diskless machine tried to get stuff it looked for ( the gateway)
and to do so it had to go thro ( 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 Srinivas home : (503) 757 9560 office : (503) 737 5547

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:38 CDT