Sgi Indigo2 Project
2019-03-04
I like Unix workstations, and I may have mentioned it more than once that I like a diverse computing ecosystem
At my first real job, Legato Systems Inc., I was part of the SAN Device Qualification team. We all had a Windows and Unix desktop. I was lucky enough to get a sweet Sparc Ultra5:
The observant reader will notice my Ultra5 is not actually on the monitor, and there is a familiar box under the desk.
Once or twice a friend of mine and I would use a Friday lunch break and head down to Fry’s or to Sunnyvale to visit WeirdStuff. One day I came back with an Indigo2. I hooked it up at work… this may have been before there were a lot of strict rules about personally owned devices on work networks.
After that I was kind of hooked. At one point I have owned:
- Indigo2
- Octane
- O2
- Sun Sparcstation 20
- Auspex server that I never really got in a usable state
I’ve sold all of it off while moving around. The O2 and the Octane are the ones I regret the most. An Octane on ebay now is several thousands of dollars, I don’t think I’ll get the chance to use one again. Let alone a Fuel or Tezro.
Now, when I worked at LLNL in the Engineering Directorate I was able to satiate my love of all of these unices. When I first started the job, I felt like I had won the lottery.
Origin2000’s, E450’s, Ultra60 workstations, Dec Alpha’s and Octanes galore. Not to mention plenty of Linux and of course FreeBSD where ever I could introduce it and coax people into hearing about it.
In that role I always had a Irix or Solaris system to work on. I also developed a real appreciation for administrating multiple OS’s, how to support and patch them. This is what lead me to tools like Puppet and SaltStack.
In today’s modern business, we are very homogenized. We support a single OS and focus everything on a single platform.
There are benefits to this, don’t get me wrong. When I write tools for one platform at work, it makes a lot of sense to focus on one offering to speed up the real goal. Software for our customers. You know, the thing that actually pays my bills.
The case where this doesn’t work out is when your single platform has a critical vulnerability. Or, your processor architecture is plagued with multiple unfixable vulnerabilities (coughIntelcough).
Now you have the unfortunate task of patching thousands of systems at once, or in the case of a CPU bug, taking a tremendous performance hit because lets face it, SPECTRE, Meltdown, Foreshadow, Spoiler, and whatever new side channel or Speculative Execution comes outi are difficult if not impossible to fix at the moment. There there are others liek L2TF, Row Hammer that are just costly to mitigate.
What if the ARM architecture was more competitive in the server world? What if MIPS never died off when SGI tried to switch to Windows NT and Itanium? What if SPARC and Alpha were not buried in buy-outs and phased out in favor of cheaper Intel platforms?
Probably nothing, these issues are caused by speculative branch execution which nearly all modern designs use. We might be in less of a panic though.
Beyond a diverse hardware, I actually like the Irix desktop. 4dwm as it is know. In my opinion it was not just an advanced Unix based GUI, it was and remains a predictable and consistent UI.
It would have been really nice if it could have evolved along with other window managers like Gnome, and KDE. I would have like to see what could have been the next evolution. They may have converged, who knows, but the memory footprint of 4dwm and other motif based GUI’s is way smaller than modern window managers.
Okay, backstory over, lets see what I got myself into.
I picked up this non-booting Indigo2 off of the ol’ eBay. The price was good for the system, and it wasn’t booting but I felt confident I could manage that.
At the moment, I am running ISC’s Kea DHCP server, which has a lot of modern features. BOOTP is NOT one of those features as I learned. The Booterizer project was a turn key solution that was pretty impressive.
Just follow the readme, put in the release version you need (6.5.22 is the last supported release that will run on an Ingigo2) and the mac address of your host. The DHCP server will ignore other clients so I ran this along side my existing dhcp server (also, ignoring other clients).
That was one step, it turns out, one of the drives was bad. I had to remove it, set the ID to 1 on the remaining drive, and boot back into fx.ARCS so I could partition and format it.
Formatting can be simple, for this 4GB disk I just used “auto”. So, first select maintenance mode and load up fx.ARCS (for MIPS3) or fx.64 (MIP4)
bootp():/6.5.22/Overlay/disc1/stand/fx.ARCS
When that finishes, exit maintenance mode and select Install. For the source, use the IP address of your VM (mine was 192.168.1.100) and start loading the different CD’s starting with disc1/dist
6.5.22/Overlay/disc1/dist
From there, you keep adding (option 2 in Inst>) sources (or add one at a time and read the many MANY conflict messages)
192.168.1.100:6.5.22/Overlay/disc2/CDROM/dist
192.168.1.100:6.5.22/Overlay/disc3/dist
192.168.1.100:6.5.22/Overlay/disc3/dist
or you can use the generated selections file by sourcing booterizer:commands
Either way, continue to follow the booterizer README and run:
return
keep *
install standard
keep incompleteoverlays
remove java_dev*
remove java2_plugin*
conflicts
go
quit
For my install, I kept things simple and minimal, mostly due to the low memory footprint. Post-install I did thinks like install the compiler dist’s and setup nekoware.
So now what?
Getting SSH working is non-trivial. The SGI Freeware site is no longer around, and the Nekoware project has halted. Irix.cc is now carrying on the torch but there are some issues. Firstly, I’m running a MIPS3 architecture, and the current packages are mostly for the MIPS4 (so, R10k and higher). When I installed the nekoware-openssh package from current, it required nekoware-openssl. Easy enough, Inst handles that dependency just fine. Except the Current build of openssh was actually build against the obsolete openssl package. And the Beta packages for MIPS3 are really MIPS4 packages.
A few tries later, I did have a functional sshd server and ssh client.
One nice thing, is NFS works. At home, I still export via NFSv3. It’s not as optimal or secure as NFSv4 but in this type of mixed environment its good enough.
I’ll probably setup an ldap client, bind it to my home ldap server, and maybe allow XLogin’s from my other systems around the house.
This project also looks like fun so I’ll have to try it out: irix_ansible
My project is now at a slight stall, I returned the PS/2 keyboard to my co-worker so I need to source my own. Ideally also picking up a PS/2 optical mouse. Those old ball mice are not as rad as I remember.
BUT NOT BEFORE CLEANING THE HECK OUT OF IT!
~Fin