Network install IRIX 6.5 onto old SGI using Linux server

It's 2011 and I managed to get IRIX 6.5.15 freshly installed onto an old SGI Indy with a MIPS R4400 CPU (1993?). This should be helpful for related hardware (Indigo2, Challenge S, etc) as well. First some useful references:

Definitions

I will use hostname client and IP address 192.168.1.2 for the machine onto which you are installing IRIX. I will use hostname server and IP address 192.168.1.1 for the Linux machine hosting the installation images. The bootp client sends packets to the broadcast address, so client and server should be on the same local subnet. An account sgi will be set up on server for rsh access by client.

Prerequisites:

The following IRIX disk images are needed. Note that the first 5 are specific to a particular release of 6.5 (6.5.15 in this case), while the latter 5 are common to all 6.5 releases.

On the linux server, you need a bootp daemon, a tftp daemon, an rsh daemon, a Korn-like shell, and an account dedicated to booting the SGI.

NOTE: I use debian, so I will be referring to packages as named by debian. However this is all basic software that will be in any distribution.

The existing bootp daemons out there are overkill and not well-suited to this purpose. So I wrote my own simple one: bootp.tar.gz. Usage is covered later on this page. I suggest you use it and save yourself from pain. To install the remaining software:

apt-get install tftpd rsh-server mksh

Theory:

The client boots up, sets its own IP address and netmask, and makes a bootp request to the broadcast address for the filename of an image to boot. The server responds with a bootp reply containing a filename. The client makes a tftp request of that filename. The server returns the image, the client boots it.

Once in the installer, the client accesses files on the server via rsh rather than tftp.

Linux server configuration:

System-wide settings:

I cannot get rsh rhosts access to work properly without adding an entry for client to /etc/hosts.

echo 192.168.1.2 client >> /etc/hosts

You also need to run the following commands to appease the SGI firmware networking stack. See the references above for the reason.

echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
echo 2048 32767 > /proc/sys/net/ipv4/ip_local_port_range

Set up account:

While chances are good that your network between the linux server and the SGI will be private such that no other machine will be able to sniff cleartext passwords sent via rsh, in general it is not good practice to go around logging into rsh servers using accounts and passwords that are important. Set up an account dedicated to this purpose with limited privileges and do not use a password you use for other accounts.

My references above say that the client installer has trouble rsh-ing into an account with a shell other than a Korn shell. Edit /etc/passwd to change the account shell to /bin/mksh. Create a .rhosts file in the account home directory to allow password-less access by the root account on the client.

adduser sgi
# follow adduser prompts - the password is the only important field at this point
# edit /etc/password to change account shell to /bin/mksh
su - sgi
echo 192.168.1.2 root > .rhosts
exit

Prepare SGI disk images:

The images of the SGI media you obtain will probably be in the EFS filesystem, which the linux kernel can read via the efs module. Mount them loopback style into the sgi account home directory:

modprobe efs
cd ~sgi
mkdir o1
mkdir o2
mkdir o3
mkdir o4
mkdir a
mkdir f1
mkdir f2
mkdir df
mkdir dl
mkdir oncnfs
mount IRIX.6.5.15.Overlays.D1.cdr o1 -o loop
mount IRIX.6.5.15.Overlays.D2.cdr o2 -o loop
mount IRIX.6.5.15.Overlays.D3.cdr o3 -o loop
mount IRIX.6.5.15.Overlays.D4.cdr o4 -o loop
mount IRIX.Applications.Feb2002.cdr a -o loop
mount IRIX.6.5.Foundations.CD1.cdr fl -o loop
mount IRIX.6.5.Foundations.CD2.cdr f2 -o loop
mount IRIX.6.5.Dev_Foundations.cdr df -o loop
mount IRIX.6.5.Dev_Libraries.cdr dl -o loop
mount IRIX.ONC3_NFSv3_6.2-6.5.cdr oncnfs -o loop

Configure and run bootp daemon:

tar zxf bootp.tar.gz
cd bootp
# read README and edit bootpd.c accordingly
# you may not need to change bootpd.c if your setup closely matches mine
make
./bootpd |tee bootpd.out

Configure tftp daemon:

The bootp dameon returns a filename to the client. The client downloads the file via tftp. On debian the tftpd package works, but the tftpd-hpa package does not even though one must often use tftp-hpa to netboot newer i386 hardware. Whatever.

Edit /etc/inetd.conf and change the directory at the end of the tftp line to be the account home directory e.g. /home/sgi. The tftp daemon will chroot to this path, so all paths used in tftp exchanges need to be relative to it.

After changes are made, tell inetd to reload its configuration file:

/etc/init.d/openbsd-inetd reload

Using the SGI serial console

See this if you are using the serial console on the SGI, rather than a keyboard and video display, perhaps because you have something like an SGI Challenge S that has no video hardware.

Client installation:

Just after you turn the client on hit the <esc> every second or so until it boots into the PROM. Otherwise it may boot into an existing installation if one exists.

Configure client:

In the PROM select Commmand Monitor. Configure the client IP address by running the command: 

setenv netaddr 192.168.1.2

Boot into fx, the disk partitioner:

Even if your disks do not need repartioning this will test the bootp and tftp setup. For an R4400 SGI you want the bootloader to load o1/stand/fx.ARCS:

boot -f bootp():/o1/stand/fx.ARCS

NOTE: If the server receives the bootp request, as shown by the output of bootpd, but does not seem to be making any tftp requests, be sure you have run the commands in "Tweak network settings" above.

See the references above for tips on what version of fx to use for other CPUs, e.g. use fx.64 instead of fx.ARCS for machines with 64-bit CPUs.

As for how to use fx, search the web for the man page on techpubs.sgi.com. If fx is unable to read or create a disk label / partition table at all on the hard drive, perhaps because it previously had a different OS installed on it, you may need to install the hard drive on another machine that can overwrite the label, such as your linux server. This is a tangential topic that will covered later on another page.

Boot into the installer:

  1. Return from the Command Monitor back to the main PROM menu
  2. Install System Software
  3. Select Remote Directory
  4. Enter the name of the remote host: 192.168.1.1
  5. Enter the remote directory: /o1/dist
  6. Hit <enter> or click Install.

At this point the installer should load via bootp and tftp, then you may be prompted to make fresh filesystems, prompted for the client host name, IP address, and so on. Eventually you should see an Inst> prompt. At this point you can enter sh for a command shell. You can run rsh from this command shell to test access from the client to the server account:

rsh sgi@192.168.1.1

Back at the Inst> prompt, tell the installer where the images are using the normal rcp syntax:

open sgi@192.168.1.1:o1/dist

There will be a number of prompts. I had better luck choosing the Feature branch over the Maintenance branch. When it asks for additional images, enter the rsh address for each additional image root from sgi@192.168.1.1:o2/dist through sgi@192.168.1.1:oncnfs/dist then enter done.

Now run conflicts to check for any dependency conflicts. I had a few conflicts related to java packages. I just chose to not install about 6 - 10 java packages and the conflicts went away.

Once you have no conflicts, run go and an hour or two later you should have a few more sraightforward prompts and be up annd running.

Cleanup:

You should disable any of the services you do not normally run once the installation is done. Stop the bootp server. Edit /etc/inetd.conf, comment out the tftp and rsh lines, and run /etc/init.d/openbsd-inetd reload. Use netstat -a and lsof to check what network ports are open by what processes.

Other issues:

Contact me at maltdodge at google mail with improvements, suggestions, things I messed up / should elaborate on, problems you run into.

I do plan on writing a page explaining how to mount an SGI hard drive on a Linux box and use xfs tools to crudely change the root password if the only issue you are having is that you don't know the root password. This is the procedure I used to get an Indigo2 up and running again. Unfortunately, the support for the version 1 directory structure that these old SGIs used has been removed from the xfs code in the current linux kernels, so you can't just mount the filesystem and edit /etc/shadow. In summary, you can use xfs_db to find the inode number of /etc/shadow and find the byte offset of its data chunk, use dd to copy the relevant 1 kB chunk of data, use the crypt function in perl to generate a new password hash, replace the root password in the chunk of data being very careful not to change the overall size of the chunk, then use dd to write the modified chunk back to disk. Ugly, but it works.