> ORIGINAL QUERY:
>
> I have a problem with a diskless client trying to boot from a newly
> upgraded Sun4:
>
> Client: SparcStation IPC, 8 Meg
> (would be running 4.1.2 if it ran)
> ROM revision 1.4
> Server: Sun 4/280, 32 Meg
> SunOS 4.1.2
> The client rarps successfully, then tries to tftp download its boot
> file from the server. While the server sees these tftp requests, it
> does not answer them. However, other diskless clients can boot, and
> the boot file for this machine can be can be successfully tftp'ed
> from other machines manually. This problem appeared immediately after
> an uneventful upgrade of the server from 4.1.1 to 4.1.2.
>
> Has anyone else had these problems (and more importantly solved them)?
>
> Thanks in advance for any information anyone can pass my way.
>
> Ian.
I received three replies, one describing a similar experience, and two
suggesting that the links in /tfptboot may be incorrect. I'd like to
thank:
feldt@phyast.nhn.uoknor.edu (Andy Feldt)
Paul Kranenburg <pk@cs.few.eur.nl>
Mike Raffety <miker@sbcoc.com>
for their replies.
However, the problem was in something I neglected to include in my original
mail message.
In addition to upgrading to SunOS 4.1.2, I had upgraded our Sunlink/DNI
package to 7.0. This changed the location where the server's ethernet
address is changed to the DECnet ethernet address in the startup
procedure, and subsequently, the RARP daemon used the wrong (i.e. hardware)
ethernet address when it replied to the client's request. (Rarpd was started
when the machine thought it's eternet address was the hardware one.) The
client was trying to access the server via the hardware address, which of
course the server wasn't listening on, so the TFTP packets were unanswered.
(This was determined using tcpdump, with the -e qualifier. I had originally
used no qualifier with my tcpdump montoring. It pays to dig a little deeper
into the packets sometimes.)
I killed the rarpd daemon on the server and restarted it, and the client
booted.
I have included the address change line in /etc/rc.boot again, and things
should be okay from here on in.
Thanks again to the respondants, and I apologise for leaving out valuable
information from my original question.
Ian.
----------------------------------------------------------------------------
Ian MacPhedran, Engineering Computer Centre, University of Saskatchewan.
2B13 Engineering Building, U. of S. Campus, Saskatoon, Sask., CANADA S7N 0W0
macphed@dvinci.USask.CA macphedran@sask.USask.CA
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:44 CDT