Port-next68k archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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/next68k/installation/

Dave

On Sun, Sep 26, 2021 at 9:38 PM David Ross <randomdross00%gmail.com@localhost> 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
> <brianw%audiobanshee.com@localhost> wrote:
> >
> > Hi David,
> >
> > When I was learning about how NEXTSTEP networking "works," I remember being very confused about BOOTP. It's entirely possible that my confusion was 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 also possible that's normal behavior and the NeXT will take a different path if it receives a prompt reply to its BOOTP request.
> >
> > Brian
> >
> >
> > On Sep 26, 2021, at 18:23, David Ross <randomdross00%gmail.com@localhost> wrote:
> > > Hey Brian,
> > >
> > > Thanks for that response, and it's great to know there are still
> > > people hanging out on this list.  =)
> > >
> > > 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 <brianw%audiobanshee.com@localhost> wrote:
> > >>
> > >> Hi David,
> > >>
> > >> When booting from disk, BOOTP is a critical step to getting on the network, 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 would 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 begin.
> > >>
> > >> I became very familiar with BOOTP while creating my own multi-tier NetInfo hierarchy of NeXTcube, NeXTstation, and even SPARCstation machines. Some of the information is duplicated on multiple machines in case one machine goes 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 set 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 ZeroConf (Bonjour).
> > >>
> > >> Brian
> > >>
> > >>
> > >> On Sep 26, 2021, at 15:53, David Ross <randomdross00%gmail.com@localhost> 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
> > >>> dross%pobox.com@localhost
> > >>>
> > >>
> > >
> >


Home | Main Index | Thread Index | Old Index