Re: Sun-4/110 NetBSD Diskless NFS Issue

[Samuel Furtaw <samfurtaw%gmail.com@localhost>]

Thank you both for the suggestions!

Jason - on the SCSI emulator front, I was using a ZuluSCSI device with
a HDD image I put together in QEMU; I had it emulate a sun4m and then
replaced the kernel with my Sun4/110 kernel. When I copied this image
over to the ZuluSCSI it could get pretty far into the boot process but
after loading the color framebuffer it would catch a bunch of stray
interrupts and would panic over "crazy interrupts". I could probably
replicate it if I could dig up the old toolchain/emulator setup I was
using.

(Side note - is there a way to build a tape install image with a
custom kernel instead of doing QEMU shenanigans? I haven't found any
resources on this.)

Alex - it seems like both are using NFSv2 calls; I might play around
with NFS server parameters to see if there is any effect.

Here is the PCAP file on Google Drive - the NFS conversation in
question is between 172.16.0.2 (server) and 10.100.0.4 (sun4). The
sun4 jumps between two different IPs in the PCAP since its RARP and
BOOTP addresses are different.
https://drive.google.com/file/d/1iy0JUlSL3GMwMBKWHRiCf8r49xWEdxRK/view?usp=drive_link

Thanks,
Samuel

On Mon, Apr 8, 2024 at 3:00 AM Alexander Schreiber <als%thangorodrim.ch@localhost> wrote:
>
> Hi,
>
> On Sun, Apr 07, 2024 at 03:20:58PM -0400, Samuel Furtaw wrote:
> > Hi all,
> >
> > I've been tinkering on-and-off for several months trying to get NetBSD
> > to run on my Sun-4/110 workstation. I haven't had any success with
> > SCSI emulators, so I've been working on running the machine diskless.
> > I have already successfully run SunOS 4.1.4 diskless over the network,
> > so I translated most of my existing server setup into a "NetBSD"
> > config.
> >
> > The issue I'm running into is that, when pulling the kernel over NFS,
> > the loader times out (with an error=60) when pulling the second chunk
> > of the kernel. It does actually pull the first 1024 bytes of the
> > kernel successfully, judging based on a Wireshark capture.
> >
> > Here is the text output to the terminal:
> > ```
> > root addr=172.16.0.2 path=/export/netbsd/root
> > read header failed: Unknown error: code 60
> > Cannot load netbsd: error=60
> > ```
> >
> > In order to get it loading at all, I have compiled a kernel without
> > most other SPARC components in order to fit within RAM - in my
> > disk-based testing it refused to unpack the kernel if it was larger
> > than 4MB (I only have 8MB total to work with.)
> >
> > In the Wireshark capture, what's odd is that the first 1024-byte chunk
> > of the kernel is pulled successfully, but when requesting the second
> > chunk (offset 1024), the responses are sent by the server and plainly
> > visible. The loader still asks for 3 retransmits before finally
> > quitting.
> >
> > Oh - and my NFS, TFTP, and RARP are hosted on a NetBSD 9.3 VM; my
> > DHCP/BOOTP and boot options are handled by OpenWrt.
>
> Just to check the standard trap: the NFS server has NFSv2 explicitly
> enabled, correct? That's something that has bitten me before when using
> Linux as an NFS server for this where NFSv2 is disabled by default
> these days and I'm not sure about the defaults on NetBSD for that.
> The sparc64 loader only supports NFSv2, I assume the sparc loader
> has the same issue.
>
> Kind regards,
>            Alex.
> --
> "Opportunity is missed by most people because it is dressed in overalls and
>  looks like work."                                      -- Thomas A. Edison