Re: Getting started netbooting a NeXTcube

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 quite
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 it
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 bit:
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
<[email protected]> wrote:
>
> Hi David,
>
> When booting from disk, BOOTP is a critical step to getting on the networ=
k, 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 ass=
ume that the NEXTSTEP OS on disk would still launch, but the network would =
not function, and all configuration from NetInfo would necessarily be absen=
t.
>
> 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 begin.
>
> I became very familiar with BOOTP while creating my own multi-tier NetInf=
o hierarchy of NeXTcube, NeXTstation, and even SPARCstation machines. Some =
of the information is duplicated on multiple machines in case one machine g=
oes down, because things won't boot if the BOOTP server is down. Obviously,=
 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 requests.
>
> I have very little knowledge of netboot, but I would recommend that you s=
et up a BOOTP server in conjunction / coordination with the netboot server.=
 Once the machine receives a BOOTP response, it will probably then continue=
 on to load the OS from the netboot server.
>
> Just remember: NEXTSTEP is older than DHCP, and certainly older than Zero=
Conf (Bonjour).
>
> Brian
>
>
> On Sep 26, 2021, at 15:53, David Ross <[email protected]> wrote:
> > Hey port-next68k,
> >
> > I've managed to acquire a NeXTcube and I'm playing around with getting
> > the old netbsd port up and running on it.  Since it was only ever set
> > 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 network 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 all.
> > During that time, in some cases a BOOTP packet manages to make it out.
> > I haven't gone any further to try to respond to the BOOTP packet yet.
> >
> > 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]
> >
>