Thursday, September 24, 2020

Netbooting SunOS on a SPARC workstation from Ubuntu 20.04

The general procedure for booting a Sun SPARC workstation over the network is well documented. I liked this guide.The post here exists to document ways in which things break in modern Ubuntu and changes which need to be made. I was booting a SPARCstation ELC.

First you need an IP address. It is best to choose a name, add that line to /etc/hosts, and use the name whenever possible.

The boot process starts with the workstation requesting its IP address via Reverse Address Resolution Protocol (RARP). This simply works. Install the rarpd package and put the address in /etc/ethers.

You can now load boot (like kvm/stand/boot.sun4c) or the kernel (kvm/stand/vmunix) via TFTP. Note that the file name is the IP address followed by period and the architecture, capitalized, like C0A8017B.SUN4C for a SPARCstation ELC at

In either case the next step is an answer from bootparamd. Install the bootparamd package, but it won't see the requests, because they're broadcasts and not sent to the server's IP address. You need to add -r to OPTIONS in /etc/default/rpcbind for bootparamd to see the requests. For some reason the lines adding to options weren't expanding ${OPTIONS}, so I had to set them all at once. It will then answer. You must supply both root and swap values in /etc/bootparams.

After that the final step is NFS. Install nfs-kernel-server. SunOS will want NFS and rpc.mountd version 2 protocols, which are disabled. In /etc/default/nfs-kernel-server add --nfs-version 2,3,4 to both at the start of RPCNFSDCOUNT (because RPCNFSDARGS won't make any difference) and in RPCMOUNTDOPTS. Note that /etc/exports requires directories, so to share a swap file you need to share a directory containing it.

If you sent boot via TFTP, it will make a bootparamd request and then load the kernel via NFS. That might be faster than loading the kernel via TFTP, because TFTP is simple and inefficient. The kernel makes another bootparamd request, and then mounts root and swap. What happens afterwards is up to what's in the root file system.

Don't forget to restart daemons after changing configuration files.

When creating devices in the root file system, ./MAKEDEV std is insufficient. You need ./MAKEDEV pty for telnet or xterm, and ./MAKEDEV win for the windowing system. The MAKEDEV script worked fine from Linux. The arch -k error is harmless unless you're using a sun4m system.


Jbooth said...

wow this is really helpful - I was getting sunrpc broadcasts, but didn't realize rpcbind was needed to forward to bootparamd. And specifically, the "-r" option on rpcbind which helped thing progress. I then added "--nfs-version 2,3,4" to RPCMOUNTDOPTS which also helped. I'm now blocked at RPC: Authentication error:
remote: bogus credentials (seal broken). But getting closer! This is on a SPARCstation 20 and Raspberry Pi -- I've been looking for hours for an answer and your post helped SO MUCH. Thank you!

Boris Gjenero said...

I've never seen that "seal broken" error booting SunOS 4.1.3_U1 on my SPARCstation ELC. I can successfully netboot it from Raspbian Buster.

This reminds me of an error I had with Ultrix. Linux only allows up to 16 group IDs in the authentication info of an RPC request, but Ultrix allows up to 32. Normally that is only a problem if a user is a member of more than 16 groups, but because a data structure for the swap file is initialized improperly, Ultrix sends 32 copies of group ID 0. Your SunOS problem could be something totally different though.

It's best to examine these things using Wireshark or similar.

Jbooth said...

I was able to get past this -- I think I was just having some issues with NFS or needed to restart. The final "magic sauce" was the boot process just sat there with the spinning \ | / - logo. Well apparently to kick start it into actually doing anything, you need to ping the machine! Unbelievable! And that made it progress and I was able to netboot after that. Just amazing. I found some obscure post somewhere in some old instructions and someone mentioned doing a ping -c 1 and sure enough that worked. WOW! Otherwise it just sat there spinning for hours...