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:
I will use hostname
client and IP
192.168.1.2 for the machine onto which you
are installing IRIX. I will use hostname
192.168.1.1 for the Linux machine hosting
the installation images. The bootp client sends packets to the
broadcast address, so
should be on the same local subnet. An account
will be set up on
server for rsh access
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
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.
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
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
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
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
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:
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.
Just after you turn the client on hit the
second or so until it boots into the PROM. Otherwise it may boot
into an existing installation if one exists.
In the PROM select
Commmand Monitor. Configure the
client IP address by running the command:
setenv netaddr 192.168.1.2
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.
<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
Inst> prompt. At this point you can
sh for a command shell. You can run rsh from
this command shell to test access from the client to the server
Back at the
Inst> prompt, tell the installer
where the images are using the normal rcp syntax:
There will be a number of prompts. I had better luck choosing
Feature branch over the
branch. When it asks for additional images, enter the rsh address
for each additional image root
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
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.
You should disable any of the services you do not normally run
once the installation is done. Stop the bootp
/etc/inetd.conf, comment out the tftp
and rsh lines, and run
netstat -a and
to check what network ports are open by what processes.
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.