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 192.168.1.123.

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.

SPARCstation ELC repair

The SPARCstation ELC is a SPARC workstation built into a monochrome CRT monitor. It is fanless, and gets quite hot, which is bad for electrolytic capacitors. I suspect that also some particular capacitor models used are bad.

Accessing the computer motherboard (under the cover at the back of the top) is very easy. Unfortunately, disassembling the rest isn't very convenient. Maybe the design tried to make it convenient at first, and then changes defeated that.

Before disassembling further, consider the shock and electrocution hazards. Obviously the line voltage side of the power supply is dangerous. The secondary side is dangerous too, because besides supplying safe voltages to the computer, it also supplies higher voltages to the monitor. The main monitor board uses those to make even higher voltages, and sends some of these to the CRT socket board. Due to capacitors, voltages can persist even when the device is turned off and unplugged.

The first problem was the power supply, the board to the right when viewed from the rear. It seems like it could be possible to lift out, but the speaker bracket screwed into its bottom prevents that. So the whole side needs to be freed and moved outwards.

The power supply was pulsing. This can happen when an SMPS detects a fault, shuts down and restarts, but that's not what was happening here. The -12 V rail had excessive ripple, and I replaced its 100 µF 16 V filter capacitor (the missing C528 in the photo) to fix that, but it wasn't causing the problem either.

Just guessing I saw the 100 µF 35 V capacitor near what seems to be the SMPS controller IC. The board in that area was browned due to heat around various holes, so it makes sense that the capacitor may have been ruined by heat. Also, a failure in power supply to that IC could cause the symptoms. After testing the theory by temporarily placing a capacitor in parallel, I replaced the capacitor and fixed the problem.

Now the picture was barely visible. The firmware screen has black text on a white background, but the text was just a bit darker than the background. Replacing the two visibly leaking pairs of back to back 100 µF 10 V capacitors at the bottom of the CRT socket board took care of that.It turned out those transistors, labelled ITT 895 115C, near the corner of the board were bad as well. According to NTE's cross reference, 2N4401 was a good substitute. I don't know why they failed. I thought maybe I damaged them by accidentally solder bridging surface mount tubular C417S to the neighbouring resistor on the underside while replacing the rightmost capacitor, but that solder bridge apparently needs to be there. I also replaced some other capacitors but am not sure any of that was necessary. This board is probably the worst for capacitors because it is in its own RFI shield box inside the monitor.

Note that the CRT socket board requires the RFI shield to make ground connections. The main ground area visible at the CRT socket and the three tabs to the left of it need to be connected by wires if you remove that shield and want to power on the monitor.

Finally there was some vertical foldover at the top. It was interesting to note that its start stayed in place as vertical size and position was adjusted. Multiple guides about this problem with CRTs in general say that the prime suspect is the pump-up capacitor. The vertical deflection circuit needs a pulse of higher voltage to overcome inductance and quickly move the beam back to the top. This is accomplished via a charge pump, which charges a capacitor in parallel with the supply, and then connects it in series, to provide that higher voltage. That was another one of those 100 µF 35 V light blue capacitors, like in the power supply (the large cap in this photo). Here are the definitely bad components:

If you want to see more photos, take a look at the album.

Fixing Whirlpool part 3378207 to make dishwasher start washing reliably

A dishwasher doesn't simply recirculate water while washing. It tries to separate solids coming off the dishes from the water, and recirculate only the water. Some dishwashers have filters. This dishwasher has a soil separator. First, a chopper breaks up any large particles. Then part of the water being pumped by the wash impeller goes through the plastic doughnut surrounding it, where baffles try to trap particles. Later, when the dishwasher pumps out water, it pumps from the soil separator, sending the particles down the drain.

The outlet of the soil separator connects to the drain pump via the drain pump cover. Also, the outlet of the soil separator has a simple valve operated by water pressure. Under that little cover to the right is a diaphragm which is pushed down by a spring to open the passage. When pressure builds up, it acts against the spring, pushing the diaphragm upwards, and pulling a rubber cone which blocks the passage.

But, how does that pressure build up in the first place, while the passage is open? I'm assuming it builds up due to the drain impeller spinning the wrong way. Both the wash and drain impellers are on the same shaft, and the current function depends on the rotation direction, determined via the motor start winding.

However, if water leaks out elsewhere, then pressure may not build up enough to push up the diaphragm and seal off the passage. That Whirlpool 3378207 drain pump cover has a rubber gasket on top. It has a thin plastic ridge surrounding that gasket, to keep the gasket in place. That ridge breaks off, and then pressure stretches the gasket, allowing water to leak out. The result was that sometimes the dishwasher would fill with water normally and not start washing, even though the pump was running. It's surprising that enough water can escape that way to cause this, but apparently it can.

If I stopped and restarted it while full of water, it always started properly. I guess the big pulse happening when the pump starts provided enough pressure to move the diaphragm, but the slow pressure increase happening as it was filling didn't.

I cut two thin slices from a copper water line, and soldered them into the appropriate shape for holding the gasket in place. The gasket had been stretched a lot, but I managed to squeeze it into place.