Booting the Indy
Once the power supply was in order, my next focus was booting it to a usable state. I ran into quite a few stumbling blocks along the way - this post doesn’t end with a 4Dwm desktop (though a future one will!).
Broken hard drive
The first issue was the scraping and grinding sound coming from one of the hard drives! On boot, it sounded like one of the disks was trying to spin up, encountering some…resistance…spinning down, and trying again. My Indy has two disks in it, so I figured out which one by process of elimination and disconnected it.
Working from a console
Since I don’t have a PS/2 keyboard and mouse, hooking the Indy up to a monitor and directly using it is not an option. Some researching on the Nekochan wiki confirmed that a DB25 to mini-DIN 8 cable would do the trick - I grabbed one from Monoprice. These are fairly common thanks to Apple using the same connector (mini-DIN 8) for their serial ports in the pre-USB era.
By chance, I seem to have gotten the right one: they sell a very similar cable that sounds like it tries to account for a different signaling standard (Mac serial ports were RS-422, whereas the Indy’s is RS-232). The one I got also seems to be a null-modem cable (though the listing doesn’t say this) - that means I can more or less directly connect it to the Indy and to my USB Serial adapter and be all set.
With the wires plugged in, I used minicom
on my laptop (set to 9600bps, no parity, one stop bit, 8 bits per character, and software flow control), and turned on the Indy. To get a Unix tty on the serial port, you have to enable it in the PROM monitor. At the prompt, I pressed <Esc>
to enter maintenance:
To perform system maintenance instead, press <Esc>
System Maintenance Menu
1) Start System
2) Install System Software
3) Run Diagnostics
4) Recover System
5) Enter Command Monitor
Option?
picked option 5 (the PROM monitor), and disabled the local graphics console:
Command Monitor. Type "exit" to return to the menu.
>> setenv console d
After rebooting, an OS came up!
Getting root
Incredibly, the remaining hard drive had a functioning OS on it! The
IRIX Release 6.5 IP22 Version 05190003 System V
Copyright 1987-1998 Silicon Graphics, Inc
All Rights Reserved.
banner was encouraging. The login prompt, however, was not. The internet pointed towards some typically wide-open IRIX user accounts (EZsetup
, lp
, and guest
) but this machine had them locked down. On some operating systems (macOS and most Linuxes, in particular), there is a “single-user mode” that automatically logs you in as root. This sounds like a huge security hole (and kind of is), but is in keeping with the reality that if you have physical access to a computer, you can get root anyway. IRIX’s single-user mode requires you to know the root password, so I had to do it the hard way.
The goal is to mount the Indy’s filesystem and clear out root’s password from /etc/shadow
, letting me log in with no password. My Indy doesn’t have a floppy drive, and I don’t have an external SCSI CD drive, so the only remaining option to get an OS running where I can mount the local disk is to netboot.
A netbooting detour
SGI machines support netbooting using a familiar collection of protocols:
- bootp for getting an IP address
- tftp for fetching a boot loader over the network
- rsh for the boot loader to fetch further parts of a root file system
The first two might be familiar in a netbooting context - bootp
evolved into dhcp
, which along with tftp
, are used in modern PXE netbooting of x86 computers. rsh
is interesting though - where nowadays, a PXE bootloader usually grabs an OS image via HTTP, the Indy seems to use ssh
’s completely insecure predecessor. I’m not completely sure what it ends up running over rsh
(perhaps the topic of a future blog post!), but my research indicates that whatever it does, it strongly expects the user it logs in as (guest
, with no password) to use the Korn shell (some discussion here).
My router handles bootp
fine, and I can run tftpd
easily on one of my home servers, but rsh
felt like it crossed a bit of a line into “what am I even doing”. Thankfully, the SGI enthusiast community produced a virtual machine that is already set up - DINA (deBug’s IRIX Netboot Appliance). I followed along with the guide on the Nekochan wiki, bringing IRIX 6.5 install CD images that I got from the Internet Archive.
Getting root, take 2
Netbooted into the IRIX installer, I launched a shell and took stock. My Indy’s root partition had been mounted for me (entertainingly at /root
, since IRIX seems to make /
the root user’s home directory). Remember, my goal is to clear the root user’s password by editing /etc/shadow
.
So, all I need to do is a quick
# vi /root/etc/shadow
right? Well, it turns out the IRIX install image doesn’t have vi
installed. What does it have? The standard editor, ed
. I had never actually used ed
- it’s mostly the butt of a running joke from 1991. With the help of the (aptly named) Actually Using Ed, I managed to clear root’s password.
Moment of truth
Was this enough to get in? My first attempt (straight up booting and trying to log in) failed - this time, with a message that root wasn’t allowed to log in on this console. Though I later learned where that is configured (and so could have gone back to the netbooted installer environment and hacked it), in the moment, I tried single-user mode again:
{ extremely "I'm in" voice }
— cron mom (@sophaskins) August 25, 2017
I'M IN pic.twitter.com/UQWKcrgrS5
Success! Time to give poor root a password again, and make myself a normal user account (soph
instead of my more typical sophaskins
, because of IRIX’s 8 character limit on usernames).
Frustration
Unfortunately, I never was able to log in as soph
. My logins didn’t fail (there was no message like when I used an incorrect password), it just…didn’t happen. I’d just get sent immediately back to a login prompt. Attempts to find logs indicating what happened, obvious permissions problems, or really any indication of what happened were fruitless.
At the same time, I still couldn’t log in as root in multi-user mode! After unlock root logins at any console, I’d be faced with a segfault (!?!?!) when trying to log in. By this time, I was feeling pretty bummed out and decided that perhaps it was time to try a fresh install. That story (and the graphical desktop it resulted in) will be in a future post!