Re: Failing to netboot

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> Hmm, I keep hearing anecdotes about modern (GBit) switches
>> technically being able to drop down all the way to 10 MBit/s, but
>> that not working all that well - maybe try a more ... "period
>> correct" (e.g. tops out at 100 MBit/s) switch, which _might_ work
>> better with 10 MBit/s clients?

> Yes, this is essentially what I=E2=80=99ve been thinking.

My own experience is that 10/100/1000 Just Works at 10...BUT when
connected to a SPARCstation-20 (and presumably other old 10-only gear),
it takes a long time to decide it's talking to something which doesn't
autonegotiate, drop back to 10/half, and finally establish link.  This
is long enough that an SS20 typically gives up and declares no carrier.

That's _probably_ not what's going on here, since you got something,
just not something the OBP code likes.  (If you do get hit with this,
you may be able to get around it by telling the SS20 - maybe others? -
to use net:tpe instead of just net.  Personally, I work around it by
sticking an SS20-era hub, not switch, in front of it.  The hub
establishes link with the switch eventually, but that link then stays
up while the SS20 establishes link with the hub fast, because neither
end autonegotiates.  If your switch is managed, you might be able to
lock down that port to 10/half and get link faster that way.)

>>> Tftp is sitting on a raspberry pi running Debian.  Can try some
>>> other options.  The contents are actually being NFS mounted from a
>>> NAS, and try moving the files locally too.

As in, the pi has an NFS mount from the NAS, with the TFTP server
reading its files out of that mount point?  I would _expect_ that
wouldn't matter.  But I think you said that copying the files to local
storage on the pi helped, so there is _something_ odd there.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B