Re: Getting started netbooting a NeXTcube

Ok so I've now been able to load the "boot" file via TFTP.  Once
loaded, I get "en: tx not ready" looping on the console.  I also have
NFS set up to serve the kernel, but I don't see a mount attempt.
(I've tested the NFS server from a separate machine and I do see the
mount in that case.)

Taking a look at the "boot" binary, I was able to find the "en: tx not
ready" string.  Anyone know where the source for "boot" lives?  Here's
the binary: http://archive.netbsd.org/pub/NetBSD-archive/NetBSD-1.6.2/next6=
8k/installation/

Dave

On Sun, Sep 26, 2021 at 9:38 PM David Ross <[email protected]> wrote:
>
> Thank you for those words of encouragement...  Turns out it works just
> as you said!
> Pic: https://twitter.com/randomdross/status/1442341255845875716
>
> And as a bonus, looks like it enables networking in NeXTSTEP as well.
>
> Dave
>
> On Sun, Sep 26, 2021 at 7:22 PM Brian Willoughby
> <[email protected]> wrote:
> >
> > Hi David,
> >
> > When I was learning about how NEXTSTEP networking "works," I remember b=
eing very confused about BOOTP. It's entirely possible that my confusion wa=
s entirely due to lack of knowledge of TCP/IP and networking itself, but I =
do seem to recall some weird behavior that sounds like the race conditions =
you're describing.
> >
> > I say go for it: Set up a BOOTP server and then see what happens. It's =
entirely possible that the race condition is a separate issue. But it's als=
o possible that's normal behavior and the NeXT will take a different path i=
f it receives a prompt reply to its BOOTP request.
> >
> > Brian
> >
> >
> > On Sep 26, 2021, at 18:23, David Ross <[email protected]> wrote:
> > > Hey Brian,
> > >
> > > Thanks for that response, and it's great to know there are still
> > > people hanging out on this list.  =3D)
> > >
> > > The next thing I was going to try (and probably will try in any event=
)
> > > is in fact to set up a BOOTP server.  The reason I didn't go do that
> > > yet is only because the strange behavior I'm seeing from the NeXTcube
> > > makes me think it won't work.  To me, it looks like a kind of a race
> > > condition, where the link is only up for a very short period of time,
> > > and during that time, a BOOTP packet _might_ make it out.  When
> > > booting with "ben" I will see a BOOTP packet sometimes, but it's quit=
e
> > > inconsistent.  And then I see the link immediately go down.  In fact,
> > > in some cases it appears the link never even turns on at all.  Maybe
> > > there's some setting configured that could cause this?
> > >
> > > My thinking is that I could have a BOOTP server responding to the
> > > BOOTP packet, but then the link will still go down regardless.  And i=
t
> > > won't even work half the time because the BOOTP packet doesn't always
> > > go out.
> > >
> > > If anyone has free time and a NeXT handy, here's what might help a bi=
t:
> > > 1)  Plug in an empty ethernet network switch into the NeXT, just to
> > > observe if the link LED turns on.
> > > 2)  Boot into the ROM monitor using Command-`
> > > 3)  Type "ben" to boot from the network.
> > > 4)  Observe what gets displayed on the console.  Also, does the link
> > > light on the ethernet switch turn on?  And if so, does it stay on or
> > > turn off after a second or two?
> > >
> > > Dave
> > >
> > > On Sun, Sep 26, 2021 at 6:05 PM Brian Willoughby <brianw@audiobanshee=
.com> wrote:
> > >>
> > >> Hi David,
> > >>
> > >> When booting from disk, BOOTP is a critical step to getting on the n=
etwork, and things like NetInfo won't even work without it.
> > >>
> > >> However, I'm not sure what happens if there isn't a BOOTP response. =
I assume that the NEXTSTEP OS on disk would still launch, but the network w=
ould not function, and all configuration from NetInfo would necessarily be =
absent.
> > >>
> > >> Since netboot has no disk to fall back on, I'm going to assume that =
BOOTP is absolutely essential to get working before the netboot can even be=
gin.
> > >>
> > >> I became very familiar with BOOTP while creating my own multi-tier N=
etInfo hierarchy of NeXTcube, NeXTstation, and even SPARCstation machines. =
Some of the information is duplicated on multiple machines in case one mach=
ine goes down, because things won't boot if the BOOTP server is down. Obvio=
usly, I had to toss all that knowledge and learn DHCP with newer systems. I=
 seem to recall that DHCP is a superset of BOOTP, and it might even be true=
 that some or all DHCP servers have the ability to respond to BOOTP request=
s.
> > >>
> > >> I have very little knowledge of netboot, but I would recommend that =
you set up a BOOTP server in conjunction / coordination with the netboot se=
rver. Once the machine receives a BOOTP response, it will probably then con=
tinue on to load the OS from the netboot server.
> > >>
> > >> Just remember: NEXTSTEP is older than DHCP, and certainly older than=
 ZeroConf (Bonjour).
> > >>
> > >> Brian
> > >>
> > >>
> > >> On Sep 26, 2021, at 15:53, David Ross <[email protected]> wrot=
e:
> > >>> Hey port-next68k,
> > >>>
> > >>> I've managed to acquire a NeXTcube and I'm playing around with gett=
ing
> > >>> the old netbsd port up and running on it.  Since it was only ever s=
et
> > >>> up to netboot, I'm starting there.  Unfortunately I'm seeing some
> > >>> really weird behavior...
> > >>>
> > >>> The ethernet network connection seems to work fine.  When I boot up
> > >>> via the hard drive, I see it recognizes when it's plugged in and
> > >>> attempts to retrieve network configuration.  Sniffing on the networ=
k I
> > >>> see BOOTP packets.
> > >>>
> > >>> However, when I attempt to netboot from the ROM monitor, I'm seeing
> > >>> that the network only comes up for a brief period of time, if at al=
l.
> > >>> During that time, in some cases a BOOTP packet manages to make it o=
ut.
> > >>> I haven't gone any further to try to respond to the BOOTP packet ye=
t.
> > >>>
> > >>> Any idea what might be causing this behavior, or how it might be
> > >>> fixed?  Can anyone attest to what the normal behavior is when
> > >>> netbooting?  (I'd expect the network comes up & stays up, and BOOTP
> > >>> packets continue to get sent on some interval until there's a
> > >>> response.)
> > >>>
> > >>> David Ross
> > >>> [email protected]
> > >>>
> > >>
> > >
> >