Hi everyone,
Yesterday, I've sent out a request ....
> I have a strange problem on some of my SS1+ when I am trying to
> boot them as client via ethernet.
> When I do :
> b le()
>
> It'll say :
>
> Got error packet: Error Code 1 Message : File not foundreceive failed
> Boot load failed
>
> Strange enough is that it works on some other workstation using the
> same cable and the same /export/{root,swap}/clientname partition.
>
> What I was trying to do is to be able to boot via ethernet on these
> SS1+s and then copy my new 4.1.1 upgrade proto / and /usr to their
> local disk, so that I don't have to carry my CDROM around to do the
> upgrade but just sitting nice and cool in my office to do all the
> upgrades. So the same /export/{root,swap}/clientname will be used
> by all the client by just changing the /etc/ethers file one at a time.
> However, I just discovered that I have th above mentioned problem.
> The SS1+ has 16 Meg RAM, Rev 1.3 ..... etc.
>
> Thanks in advance.
> Tim Chan
>
Thanks to all quick response from each one of you. It turned out that
it is our own mistakes. I finally found out that there are 2 reasons for
my problem. The first one is that for some reason I have 2 entries in
the NIS's /etc/ethers file using the same ethernet address. The second
reason I found was that my server still have the workstation's old
arp entry. I've used "etherview"'s protocol analyser to filter out
the "rarp" request, and found that the server responsed with the older
IP address. As soon as I removed the arp entry or the 2nd entry in
/etc/ethers, it works great, and now I can upgrade all my some 90
workstations in just 10-15 mins per workstations without leaving my
office.
Here is a short summary of the response I made, I hope I will actually
summarize this time, as somebody has pointed out that I did do a good
job in summarize my responses last time ;-( :
=======================================================================
>From: kuno@caen.engin.umich.edu (Harumi Anne Kuno ) :
>
>Are you using tftpboot? It could be that your client is not being permitted
>to read the tftp directory for some reason. You might try taking the "-s" out
>of the /etc/inetd.conf for tftp. (Also make sure that you have the correct
>files in the directory.)
I didn't tried this, but I tried using "tftp" from my workstation and
successfully get the correct file from the server.
>From: Prabal Acharyya <prabal@cis.ohio-state.edu>
suggested to use rpc.bootparams with -d for debugging, I didn't try this
either since my problematic workstation wasn't able to get this far, it
gave me the error packet message right after it say :
booting: le(0,0,0)
>From: macphed@dvinci.usask.ca (Ian MacPhedran)
>From: cerrone@pluto.crd.ge.com (David F Cerrone)
>From: geertj@ica.philips.nl (Geert Jan de Groot)
>From: Tom Crummey <tom@sees.bangor.ac.uk>
suggested me to check /tftpboot again since the client wasn't able to
get the bootfile from the server. This turned out to be the case
since the server responsed with the wrong IP address.
>From: stern@sunne.East.Sun.COM (Hal Stern - Consultant)
asked if I have any SGI or DEC machines running rpc.bootparamd, using
the NIS bootparams map, I didn't. We only have Suns in this location.
He also suggest to try :
b le() -v
to see where the bad packet comes from. Unfortunately, I did try but
the -v didn't give me additional information, since it fails on the
first packet it received. But this is a good option to know, it works
if I can get the boot file from the server, and help debugging for
other problems.
>From: Hwa@ssc.sscnet.ucla.edu
>From: canuck@rice.edu (Mike Pearlman)
points out that under 4.1.1, I have to use fully qualified hostnames
for the bootparams file. I've checked and it works now without using
the fully qualified names, it could be that we have DNS running.
>From: ch@lks.CSI.COM
suggested me to check the arp table with "arp -a", I did and it was
one of the reason of my problem and I did "arp -d" for the offending
entry.
>From: trr@lpi.liant.com (Terry Rasmussen)
suggested me to try "b le() -asw", I didn't but I will next time.
>From: Kevin Brady <brady@mgmt4.ncsl.nist.gov>
suggested that it may be that the server and the client were not the
same architecture.
=======================================================================
How did I do this time for my summary ? Thanks again for all the quickest
responses.
Tim Chan
================================ Address ===============================
Tim Chan, System Engineer, Teknekron Communications Systems
(415)-649-3645 2121, Allston Way, Berkeley, CA94704
Internet : tim@tcs.com uucp : uunet!tcs!tim
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:13 CDT