Restoring a Sun SPARCstation IPX part 1: PSU and NVRAM (2020)

We still have a SPARC IPX in production, hosting an antiquated database. The hard drive sounds like grinding metal. I've been trying to get rid of it for years. I succeeded once, but it was brought back from the dead. This thing has been running with the original parts since 1993 to 2026, minus ~1 year of downtime.

Nobody has the root password anymore, but fortunately, it's vulnerable to at least seven remote root sunrpc exploits. We "log in" by running a Python script that pops a root shell.

No, I am not kidding.

Edit: Checked out records: purchased and brought online in 1993.

Edit 2: In response to "why don't you just change the password?". When I asked, I was told they "can't" because they'd "lose access to the database". I didn't ask them to elaborate, because it would have opened a whole new can of horror worms, but I removed it from the Internet (it's on a non-routable, weakly "air gapped" network now).

I got a IPX in 2022 and restored it. I was a bit lucky and mine was an ex-IBM unit that came with the Weitek SPARC POWER μP processor (80 MHz) upgrade.

It makes for a pretty good project box as one of the smaller SPARC machines. Lots of documentation from hobbyists, Sun's own service manuals, and OpenBSD/NetBSD. Flash SCSI disk replacements are much easier to get your hands on now (I used a ZuluSCSI).

I've kept a log with photos: https://drislock.org/pkb/machines/perfect.html#a-little-lunc...

It seems to have been part of IBM's IBM-IPT Tester system. Hostnames were interesting: flower, owl, piglet, diamond, hotlips. I didn't get any interesting data though since this system relied on network resources.

Everybody hating on the IPX, but I have so much nostalgia. Yes, my friends who ran a repair shop kept employed fixing them, like transmission shops survive on minivan transmissions.

That era hardware (although I ended up with a fair bit of experience on the whole Sun 3/4 lines)... I had just gotten out of the Army, didn't know what I was going to be when I grew up, and the future was so terrifying but bright.

It's a good thing that I don't horde (except cars, that's a problem), because I'd have racks of these things. Named after Star Trek characters, not because I care about it, but because that was the naming convention at one of my first "real jobs".

IDK, maybe nobody else thinks this way, but I'm really glad to see someone fixing one.

Making the default MAC address and machine serial number depend entirely on the NVRAM/RTC battery is... a choice. You'd think they would have used some fusible links to burn the original values into the hardware to fall back on if the battery died.

Not the greatest UNIX workstation in the world, but we had rooms full of them at my uni and I learned how to Internet on them. Still a lot of love for these.

God that machine was terrible - underpowered and undercooled, which led to frequent overheating and component failures. When I first started at Sun, they put one of those on my desk as a joke on my first day (it was quickly replaced so that I could get some real work done).

I went through replacing the NVRAM on an old Sun 3/80 about a year ago. Amusing adventure, and then fun to get to use BOOTP again to network boot. Lots of nostalgia. Boy how I had forgotten how primitive it was to use SunOS 4.1.3.

Oh, man; I got my hands on a (dead) one of these when I was a freshman in college (2004) and instead of trying to restore it my friends and I gutted it and used it as an original Xbox case mod. It was pretty satisfying to show up at LAN parties with what looked like a Solaris box and watch people boggle when we played Halo on it...

This was a lot of fun to see, especially part 3 where it boots up. Us older guys (me, anyway) still find joy in seeing these old machines we learned our skills on being restored like this.

Thanks for posting this one. good find.

oh yeah that's interesting

I got a IPX in 2022 and restored it. I was a bit lucky and mine was an ex-IBM unit that came with the Weitek SPARC POWER μP processor (80 MHz) upgrade.

I've kept a log with photos: https://drislock.org/pkb/machines/perfect.html#a-little-lunc...

This was a lot of fun to see, especially part 3 where it boots up. Us older guys (me, anyway) still find joy in seeing these old machines we learned our skills on being restored like this.

Thanks for posting this one. good find.

oh yeah that's interesting

Nobody has the root password anymore, but fortunately, it's vulnerable to at least seven remote root sunrpc exploits. We "log in" by running a Python script that pops a root shell.

No, I am not kidding.

Edit: Checked out records: purchased and brought online in 1993.

QEMU has a SPARC CPU emulator; it might be possible to run the operating system and database in a VM on regular x86-64 hardware.

A BlueSCSI[0] might be an interesting thing to add if you want to alleviate the hard disk sound.

[0] https://bluescsi.com/

Out of morbid curiosity, is there a recovery plan for when it inevitably experiences a hardware failure?

This box needs an official retirement ceremony when the database is migrated.

If you get a root shell once, why not change the root password then?

> We "log in" by running a Python script that pops a root shell.

I'm surprised that when you do this, you can't then set the root password. (Also, holy cow. What a durable machine.)

dump that disk asap!!!!!

Everybody hating on the IPX, but I have so much nostalgia. Yes, my friends who ran a repair shop kept employed fixing them, like transmission shops survive on minivan transmissions.

IDK, maybe nobody else thinks this way, but I'm really glad to see someone fixing one.

I had one on my desk and eventually a collection of Sparc 2, 10's and a V in my garage. I miss the keyboard and Sun OS 4, the Trinitron display and working on difficult engineering problems on those machines.

Nobody burns in MAC addresses. MAC is usually stored on eeprom. Either in BIOS or small i2c one on the NIC. Storing it in the nvram means you save $0.1 BOM, dont have to partition your bios chip and serialization becomes cheaper and faster. Its not like losing one is a problem, just bang a random number with Sun prefix and you will be statistically fine.

Not the greatest UNIX workstation in the world, but we had rooms full of them at my uni and I learned how to Internet on them. Still a lot of love for these.

Great keyboard, great display, great OS. It was fast enough and a great terminal to bigger Sparcs if you needed it.

At work in the 90s we gave tons of old Sparcstation 10s away. They rapidly replaced all IPX and IPS at the computer clubs around Sweden. One Volvo was destined for Luleå and was really weighted down with a trunk full of pizza boxes.

I managed a lab of them. I _hated them_. They were unreliable, slow, and just absolutely miserable because they created endless complaints.

We were rolling out labs of Windows machines. Except for the lack of terminal, they were better on every single axis for the common university lab use cases - mostly netscape/mosaic and applications..

I also managed NeXT slabs and cubes; they were vastly better than the sun boxes because we had installed HDDs in the cubes and extra memory. The only problem with them was the absolutely terrible, shit behavior when users accidentally browsed the AFS root...

The only positive thing I can say about those Sun boxes is that _one_ behavior was better than NeXT. With NeXT, students would pull the power on them after wating four or five minutes of the beachball due to AFS I/O.

Totally terrible. ONe place I worked we all had sparcs and the first thing that happened whenever anyone left is there would be this mad shuffle where everyone nicked everyone else's computer with the IPX being the prize for whoever wasn't there at the time or the new joiner. So I had the IPX for a while, even just using it as an x client for a remote build server it was horrible.

Classic day 1 hazing, the Wimp Lo: https://www.youtube.com/watch?v=d696t3yALAY

Yeah it was a real piece of junk, but I guess there's no accounting for nostalgia. People also like to restore the SGI Indy, easily the worst machine that SGI ever shipped.

At one point decades ago there were a lot of these IPXs and their SCSI accessories on eBay and they were a decent source of project boxes because you could use the power supply and stick your project where the hard drive was supposed to be, with the wires coming out the SCSI port. It looks like the model 411 is still $30 or so on eBay but there are few.

A BlueSCSI[0] might be an interesting thing to add if you want to alleviate the hard disk sound.

[0] https://bluescsi.com/

This box needs an official retirement ceremony when the database is migrated.

dump that disk asap!!!!!

> We "log in" by running a Python script that pops a root shell.

I'm surprised that when you do this, you can't then set the root password. (Also, holy cow. What a durable machine.)

Great keyboard, great display, great OS. It was fast enough and a great terminal to bigger Sparcs if you needed it.

QEMU has a SPARC CPU emulator; it might be possible to run the operating system and database in a VM on regular x86-64 hardware.

You absolutely can run 32bit Solaris in qemu SPARC emulation. 64bit is not there yet unfortunately. But definitely dd this and get it virtualized!

Out of morbid curiosity, is there a recovery plan for when it inevitably experiences a hardware failure?

Buy parts from RS and fix it, silly.

If you get a root shell once, why not change the root password then?

Great, obvious question!

The answer I got: "we can't. We'll lose access to the database". I did not ask for elaboration, but it is not routable to/from the Internet.

Nobody misses the terrible optical mouse with the blue metal mouse mat though! You are right, the keyboards were great.

You absolutely can run 32bit Solaris in qemu SPARC emulation. 64bit is not there yet unfortunately. But definitely dd this and get it virtualized!

Buy parts from RS and fix it, silly.

Classic day 1 hazing, the Wimp Lo: https://www.youtube.com/watch?v=d696t3yALAY

Nobody misses the terrible optical mouse with the blue metal mouse mat though! You are right, the keyboards were great.

Great, obvious question!

The answer I got: "we can't. We'll lose access to the database". I did not ask for elaboration, but it is not routable to/from the Internet.

You can just add a second line to /etc/passwd with a different username but the same numerical uid. Like this:

    altroot:x:0:0:Alternative Root User:/:/bin/sh

Then, of course, run (as root) "passwd altroot" to set a password.

We used to do this all the time for users who needed root access to their own workstation. It allowed us to avoid telling them the common root password used on all the machines in the organization.

In your case, doing this might be beneficial in case there is a network problem because you'll have a way to log in as root locally.

Seems as though the process of changing the password on their end may not be as straightforward. Or they’re just worried that misconfiguring it may prevent them from getting connected again.

In any case, as long as it’s not directly routable to the internet and there’s a plan to phase it out, probably nothing to get worked up about.

I hope the sound of the drive isn’t particularly bothersome. It’s rather impressive to still be working.

I managed a lab of them. I _hated them_. They were unreliable, slow, and just absolutely miserable because they created endless complaints.

A younger person who only knows the comparative merits of Windows, macOS, and Linux in this decade probably cannot imagine the relief felt by people when they were finally able to move their technical applications off unix boxes onto Windows NT workstations. The situation was so bad, the computers cost so much and worked so poorly, a Dell with a Pentium Pro was like a miracle, at the time.

Yeah it was a real piece of junk, but I guess there's no accounting for nostalgia. People also like to restore the SGI Indy, easily the worst machine that SGI ever shipped.

The Indy was awesome. One client had 400 of them, as long as you didn’t take the lowest RAM entry level model they were excellent. Hardware was reliable, graphical desktop better than MacOS today, and very low support burden.

Seems as though the process of changing the password on their end may not be as straightforward. Or they’re just worried that misconfiguring it may prevent them from getting connected again.

In any case, as long as it’s not directly routable to the internet and there’s a plan to phase it out, probably nothing to get worked up about.

I hope the sound of the drive isn’t particularly bothersome. It’s rather impressive to still be working.

I remember a lab with diskless systems where your disk quota was smaller than the kernel panic dump. So basically if you crashed a machine your account was instantly filled up and basically nothing would work. I believe it affected mail as well. Fun times.

Hey, don't trash talk Indy like that. It has.. well, it is Web! and has VRML.. and it's your only option for N64 devkit. So, there's that. Overall you're right though. Entry level machine. I have one in working order, rarely has use next to Indigo2 MAX impact. I do have one Sparc, haven't been booted in ages. I have to check whether it's IPX or Classic. I'm even afraid to boot it up.

You can just add a second line to /etc/passwd with a different username but the same numerical uid. Like this:

    altroot:x:0:0:Alternative Root User:/:/bin/sh

Then, of course, run (as root) "passwd altroot" to set a password.

We used to do this all the time for users who needed root access to their own workstation. It allowed us to avoid telling them the common root password used on all the machines in the organization.

In your case, doing this might be beneficial in case there is a network problem because you'll have a way to log in as root locally.

Back in the day we would've just added our IP to the .rhosts file and no password would be required at all!

It does have me thinking about what versions of SSH would run on such an old OS. I'm sure there were versions available at one time... and since it's vulnerable to remote exploit anyways the version wouldn't really matter.

Only some people who were around at that time welcomed Windows NT; others decried the various failings of Microsoft…

There is an irony that Wine is the most stable linux ABI for GUI applications in 2026.

Only some people who were around at that time welcomed Windows NT; others decried the various failings of Microsoft…

Back in the day we would've just added our IP to the .rhosts file and no password would be required at all!

SSH v1 protocol would work; but it’s still considered insecure by SSH clients of the last two decades :-)

Repairing a dead power supply and replacing the NVRAM in a vintage UNIX workstation.

If you worked in computing in the early 90s, studied computer science around then, or just had a keen interest in computers, the chances are that Sun Microsystems was a familiar name and their workstations were highly coveted. At this time PCs were fast becoming the standard desktop computer and pretty much all looked the same, while if you worked in a creative industry you might have been lucky enough to use a Mac — but even then, the differences were not so profound.

Detail from a Sun SPARCstation 5 ad, circa 1994.

However, there was a breed of computer that really stood out from the rest and not only looked far more exotic, but had a clear lead in terms of performance and capabilities — the UNIX workstation. While most people were running Windows 3.x and being frustrated at the limited resources, lack of true multitasking and all too frequent instability, UNIX workstations provided a far more advanced, feature rich and robust environment. This included proper multitasking and typically greater RAM, more powerful CPU and advanced graphics, plus higher performance disks etc. Of course, this all came at a cost and a UNIX workstation could easily have a price tag 10x that of a typical PC.

There were numerous competing UNIX vendors and many had their own niche in which they excelled. Such as Silicon Graphics, who as the name suggests, specialised in powerful graphics workstations, which proved popular in applications such as 3D visualisation, and film and TV.

Sun Microsystems hardware found many different uses, but was notably popular in the nascent Internet industry, with “headless” (no VDU etc.) versions of their workstations and also larger server chassis configurations often being put to use as DNS, FTP, e-mail and web servers.

As the first UNIX computer that I ever used, I have a particular fondness for the Sun SPARCstation IPX, which is a compact “lunchbox” form factor machine that packed a lot of power — at that time — into a small space and featuring an attractive industrial design.

Hardware specs

40MHz 32-bit SPARC CPU + FPU (Sun 4/50)
Up to 64MB RAM as standard
Sun Turbo GX colour framebuffer
3.5” floppy drive
SCSI drive
10M Ethernet (uses an external transceiver)
Audio input and output
Serial port
2x SBus expansion slots

SPARC is a RISC instruction set architecture (ISA) that was developed by Sun and Fujitsu, first released in 1987 and which continues to be developed today by Fujitsu. Earlier Sun computers were based on the Motorola 68K processor and the first SPARC workstation was introduced in 1989.

The processor clock speed may seem incredibly low to us now and at the time there would have been Intel CPUs clocked at similar speeds. However, the SPARC CPU was designed with UNIX in mind and the IPX featured an MMU with 8x hardware contexts, which benefited multitasking.

The price upon introduction in 1991 was around $15,000 for a SPARCstation IPX complete with 19” CRT monitor, keyboard and mouse. Hence use tended to be limited to specialist applications and the one that I used around this time was employed in mobile data network conformance testing.

The SPARCstation IPX that is the subject of this blog post has a HDD installed which is a few hundred megabytes and it has 32MB of RAM fitted. I’ve owned it for some years and it did previously work, but at some point the power supply developed a fault.

Failed electrolytic capacitors

Out-of-spec and out-and-out failed electrolytic capacitors are a common issue with ageing electronics and it appears that, out of all the Sun SPARCstation models, this is particularly an issue with the IPX and IPC power supplies. Which suggests that those originally fitted may have been of a poor quality or from a bad batch, else something in the design of the PSU has caused them to fail.

The SPARCstation IPC and IPX share the same power supply and this web page gives a description of replacing the electrolytics in a PSU from an IPC. Interestingly, the author notes elsewhere that they had two IPCs with dead PSUs, whereas one fitted in an IPX worked fine. However, the IPC is a slightly earlier model and it could simply be that these were older, else perhaps pure chance. In any case, I have two IPXs and both of which with suffered from dead power supplies.

All the electrolytic capacitors were replaced, apart from the physically large line-side filter capacitor with the rubber cap on top. The RS parts used are:

Nichicon 470μF Electrolytic Capacitor 25V (715-2669)
Panasonic 3300μF Electrolytic Capacitor 10V (526-1171)
Wurth Elektronik 47μF Electrolytic Capacitor 50V (839-8850)
Wurth Elektronik 1μF Electrolytic Capacitor 50V (839-9351)
Panasonic 220μF Electrolytic Capacitor 16V (449-0974)
Nichicon 100μF Electrolytic Capacitor 25V (520-0867)
Nichicon 1000μF Electrolytic Capacitor 25V (715-2678)

There were originally both 25V and 50V rated 47uF capacitors fitted, but for the sake of convenience, only 50V rated parts were ordered and these were fitted in place of both.

As can be seen above, the original capacitors had leaked electrolyte and this is never a good sign.

This had led to what looks like corrosion on the underside of underside of the board.

Once the caps had been replaced, the power supply was reassembled and fitted back into chassis.

Following which, power could be applied and it was the moment of truth.

Unfortunately, the SPARCstation didn’t spring back into life and there was just a slight kick of the PSU fan upon powering on. At this point the PSU was removed, soldering was re-checked for shorts etc. and nothing looked obviously out of place. Apart from the aforementioned corrosion.

Given that replacing the caps didn’t take too long and there was a 2nd dead IPX, the decision was made to proceed to re-cap its power supply. This was in a much better state, without electrolyte on the top of the PCB and with no corrosion on the underside.

Unfortunately, when removing the old caps a section of pad/trace lifted, but nothing too serious and this was easily dealt with when fitting the new capacitor.

Once re-capped and reassembled, this was fitted into the first SPARCstation, power was applied and thankfully it then sprung into life.

The priority was to get one system working and at some point I’ll return to the first PSU and attempt to track down the fault, which should be easier with a second working power supply, since measurements can be made at various points on the PCB with both and then compared.

Now on to resolve the next issue.

Replacing the NVRAM

Similar to how a PC has BIOS for initialising the hardware and loading an O/S, Sun machines have OpenBoot PROM (OBP) firmware. Which like BIOS can also be used to make configuration changes — such as setting which device to boot from by default — and these are persisted in non-volatile RAM (NVRAM).

However, whereas PCs typically have a rechargeable battery or removable coin cell that is used to retain configuration settings and maintain the time-of-day while powered down, Sun hardware instead uses a TIMEKEEPER device which integrates SRAM, RTC and a battery. Hence when the battery fails, the entire device must be replaced.

Above we can see the error displayed on power-up, as the OBP determines that the NVRAM chip battery is dead. Unfortunately, this is also used to store the Ethernet MAC address and its Sun hostid, a unique ID that is used for things such as locking licensed software to a specific machine.

The venerable Sun NVRAM/hostid FAQ can be consulted to find details of the replacement part, which is specified for the IPX as being M48T02 (310-9655) . Once this is fitted we then need to program the MAC address and hostid. However, if we didn’t have a record of these we will have to make them up and just need to ensure sure that the MAC address doesn’t clash with that of another device on our network. The above linked FAQ has details of the hostid format, which has a prefix specific to the machine model, while the MAC address prefix is that assigned to Sun Microsystems.

Prior to reprogramming the IDPROM, we first need to reset to NVRAM defaults and disable the diag option, by entering at the OBP “ok” prompt:

set-defaults
setenv diag-switch? false

The OBP monitor is actually a Forth interpreter and the mkp command can be used to reprogram the IDPROM section of the NVRAM. Handily, the FAQ has an example based on SPARCstation IPX hardware and for this a hostid of 57c0ffee is used, with a MAC address of 08:00:20:c0:ff:ee.

1 0 mkp
real-machine-type 1 mkp
8 2 mkp
0 3 mkp
20 4 mkp
c0 5 mkp
ff 6 mkp
ee 7 mkp
0 8 mkp
0 9 mkp
0 a mkp
0 b mkp
c0 c mkp
ff d mkp
ee e mkp
0 f 0 do i idprom@ xor loop f mkp

The first command sets byte 0, which holds the format/version number, to 01. Bytes 2-7 hold the MAC address. Bytes c-e store the hostid. Byte f is used to hold a checksum and this is computed and programmed using the final command shown above. For detailed information, see the FAQ.

At this point we can enter reset at the prompt.

Now we find that we have a MAC address and hostid configured, but sadly there is still an error warning that NVRAM needs replacing, despite configuration changes persisting when powered down. It seems that this is not uncommon and there are various discussions online regarding this, with one thread suggesting that the issue may be resolved by fitting an M48T12 part instead.

The downside to this error persisting is that the machine will not automatically boot, so in an effort to resolve this an M48T12 part (829-4073) was ordered and the IDPROM programming repeated. Unfortunately, this gave the same results and so more research is required, but at least the SPARCstation will keep time and it won’t be necessary to program the MAC address and hostid every time it’s powered on; not automatically booting is a minor annoyance to put up with.

First boot

To boot from the internal disk we simply enter at the OBP prompt:

boot disk

Following which Solaris 7 (SunOS 5.7) was loaded.

EthAddress_fec16d08f3b5e4375b10f0f38835f780b360c9c7.jpg

After a short while it was then possible to log in as root. From the logs it appears as though the machine was last booted in the year 2000 — or at least it thought that was the year! It was also possible to search the logs to see what the Ethernet address was when it was previously booted, which is useful as we could then go back to the OBP monitor and reprogram the IDPROM with this address. Of course, it is always possible that this wasn’t the original MAC address and it had been set to some random value when the original one had previously been lost.

Next steps

Now that we have a working machine, it would be nice to see if we can clean the enclosure up and remove some of the marks and if possible, the yellowing of the plastic. Further research is also required to see if the NVRAM error can be cleared. Finally, Solaris 7 was released in late 1998 and is perhaps a little modern for a SPARCstation IPX, hence it would seem appropriate to load a Solaris 1.x release from around 1991-1994, closer to when the system was introduced.

Part 2 is available now

— Andrew Back

Hacker Times