• Please review our updated Terms and Rules here

Net boot a Sparcstation 2

Elektraglide

Experienced Member
Joined
Mar 24, 2023
Messages
326
Location
Brighton,UK
Recently got a SS2. In 1990s, I worked in a research lab with 10+ Sparcstations, a DAP, a T-800 research box etc. Did we really work with *this* much fan noise! Crazy.

Anyway, slowly getting there with getting it to boot off the network but man..

I've got rarpd and tftpd running on a Ubuntu box, the (required) vers2 UDP nfsd running my implementation I wrote over the summer for Tek4404 on a Macbook, and my PC actiing as a dumb terminal for the console! (Ubuntu dropped UDP vers2 nfs support).

It wouldn't be too tricky to write an all-in-one rarpd/tftpd/nfsd thing so folks didn't have to install all this legacy stuff. Has anyone done something like that?
 
Almost got it going. My nfs implementation has portmapper listen on 111 and assign ports for mountd and nfsd. Seems Sparc expects nfsd on 2049. mountd being on some other port seems fine..
 
I wouldn’t use Ubuntu for this sorta thing as Linux likes to drop useful stuff for no reason. NetBSD is far superior!
I started with tftpd64 on Windows but that doesn't support RARP.. So I switched to Mac, but the implementation of rarpd on Mac doesn't support udp. So I switched to Ubuntu and now that part - rarpd getting a IP address and tftp serving the miniboot file - all now works.. So I ain't changing it! :-)
 
Hats off to TruHobbyist but it looks hellish complicated to setup. I was thinking, compile a file and run it. It listens on the right ports - type thing.. :-)
 
Spent yesterday on this and its coming along nicely.
I've got RARP working so the Sparc can get its IP address. Because its an ARP packet, I used a bpf device to get raw ethernet packets. But seems to work fine.
I added a simple TFTP server (stftp: simple trivial ftp anyone? :-)) which serves the miniroot (boot.sun4) and the sparc boots up now.
I already had the NFS v2 code and that now serves the vmunix executable.

I wanted to avoid all config files so its just a big commandline like this:

Code:
mynfsd -machinename sparc2 -mac XX:XX:XX:XX:XX:XX -addr 192.168.1.71 -ftpbase /Users/Shared/export -fs /Users/Shared/export/root -swap /Users/Shared/export/swap

However.

Seems sparc expects to use the RARP service and then BOOTPARAMD by using a call to PORTMAPD on port 111 with a procedure "Call-It". Which I hadn't implement. 😞
 
I've implemented bootparamd and now the sparc gets its root and swap NFS paths. Need some advice:

I have root=/Users/Shared/export/root/sparc2 and swap=/Users/Shared/export/swap/sparc2 Both are directories.
But when vmunix boots it displays:
Code:
root on sunbootd:/Users/Shared/export/root/sparc2 fstype nfs
swap on sunbootd:/Users/Shared/export/swap/sparc2 fstype nfs size 0K
WARNING: swap space probably too small

And then everything goes south...

I understood the swap path to be a NFS mount of a folder with swap files *inside* it - right?.
I created a 64MB file called "swap" and one called "C0A80147" in the directory as I'm unsure what the swapfile is expected to be named..

nfsd logs show the sparc2 mounting the swap directory...

Code:
rarpd: 08:00:20:7f:00:00 => 192.168.1.71
bootparamd: whoami: C0A80147
bootparamd: getfile: client:sparc2 asking for root
bootparamd: getfile: client:sparc2 root => /Users/Shared/export/root/sparc2
mountd: mount Path = /Users/Shared/export/root/sparc2 for client@192.168.1.71
nfsd: get_attr: /Users/Shared/export/root/sparc2  perm:41ed  size:544
nfsd: statfs: disk:131072 free:114688
bootparamd: getfile: client:sparc2 asking for swap
bootparamd: getfile: client:sparc2 swap => /Users/Shared/export/swap/sparc2
mountd: mount Path = /Users/Shared/export/swap/sparc2 for client@192.168.1.71
nfsd: get_attr: /Users/Shared/export/swap/sparc2  perm:41ed  size:160
nfsd: statfs: disk:131072 free:114688
bootparamd: getfile: client:sparc2 asking for dump
bootparamd: getfile: client:sparc2 dump => /Users/Shared/export/dump/sparc2
mountd: mount Path = /Users/Shared/export/dump/sparc2 for client@192.168.1.71
nfsd: get_attr: /Users/Shared/export/dump/sparc2  perm:41ed  size:64
nfsd: statfs: disk:131072 free:114688
nfsd: get_attr: /Users/Shared/export/swap/sparc2  perm:41ed  size:160

Is it my get_attr on a directory should be showing the total size of all the files inside?
 
There is "love" which is an all in one (bootp, tftp, rshd) network install program for SGI/IRIX.
Ooh, nice, that looks similiar to DINA - deBugs IRIX Netboot Appliance
which was on Nekoware before that disappeared.
 
Nope, I guess I never did that part. I just set up netbooting as a way to get either FreeBSD, NetBSD or OpenBSD installed on that machine.
 
OK, I've now made it 16MB. The machine has 48MB of RAM so I presumed swap needs to be at least that size..

If I hack the nfs::getattr to claim the directory stat.st_size is actually a large number, the "WARNING: swap space probably too small" goes away but getting the size of a directory seems kinda pointless, no? Examining the swapfile itself makes sense but there is no nfs activity like that.

When vmunix crashes it logs some garbled text:

Code:
swap on 192.168.1.233:/Users/Shared/export/swap/sparc2 fstype nfs size 0K
WARNING: swap space probably too small
Warning: dump_max value inhibits crash dumps.
dump on 192.168.1.233:/Users/Shared/export/swap/sparc2 fstype nfs size 0K
▒▒▒ic:▒c▒▒'t▒cre▒te▒▒er▒el▒▒roce▒▒
                                  ▒▒▒ci▒▒file▒▒▒▒te▒▒...▒▒o▒e▒▒
                                                               00000▒low-▒e▒or▒▒t▒tic▒▒er▒el▒▒▒▒e▒
                                                                                                  00000▒▒▒▒itio▒▒l▒▒t▒tic▒▒▒▒▒▒▒▒▒▒▒er▒el▒▒▒▒e▒
                                                                                                                                               00000▒▒▒▒▒▒ic▒▒er▒el▒▒▒t▒▒▒▒e▒
                                                                                                                                                                             00000▒▒▒▒itio▒▒l▒▒▒er▒▒tr▒ct▒re▒▒▒▒e▒
                      00000▒▒e▒▒▒▒▒er▒el▒▒▒▒e▒
                                              00000▒▒e▒▒▒▒er▒el▒▒▒▒e▒
                                                                     00000▒c▒rre▒t▒▒▒er▒▒roce▒▒▒▒▒e▒
                                                                                                    00000▒▒▒er▒▒t▒c▒▒▒▒e▒
                                                                                                                         00000▒tot▒l▒▒▒▒e▒(0▒c▒▒▒▒󩍍
                                                                                                                                                   ▒▒
                                                                                                                                                     ▒▒▒▒i▒▒to▒▒▒ff0▒f5e▒▒▒off▒et▒-▒▒▒▒
                                                                                                                                                                                       -▒▒f▒_▒▒▒▒.▒▒t▒t▒󠲱▒▒
               ▒0▒tot▒l▒▒▒▒e▒▒▒▒▒i▒o▒error▒▒
                                            re▒ooti▒▒...▒▒


Looking for strings in the vmunix file match up with some of these:

%5d low-memory static kernel pages
%5d additional static and sysmap kernel pages failure dumping kernel static/sysmap pages: seg=0x%x
%5d dynamic kernel data pages failure dumping kernel heap: memseg=0x%x pp=0x%x pfn=0x%x
%5d additional user structure pages failure dumping user struct: proc=0x%x
%5d segmap kernel pages failure dumping segkmap

So some catastrophic crash and unable to dump - though I see no NFS activity. And a mystery why the text is corrupted in random places..
 
Last edited:
The garbled text looks like a serial port misconfiguration, i.e. 8N1 instead of 7E1.

In traditional Unix file systems, a directory is just a file storing directory entries in its data area. Its size is well-defined and computed the same as for every other file - the size of the data area.
 
Last edited:
Are you sure the swap parameter in bootparamd shouldn't point to a file instead of a directory? I believe 'mkfile [-nv] size[b|k|m|g] filename' is used to create it.
It should definitely point to the file, and for SunOS 4 it needs to be at least as large as RAM (and is only useful if it's bigger IIRC). For Solaris it can be smaller.
 
Back
Top