Remote, network installation of SGI IRIX 6.5
from a GNU/Linux install server

Last update: Dec 2018 // Previous updates: Mar 2018, Jul 2016, Mar 2016, May 2014, Dec 2011, Apr 2009, Feb 2008 // First created: Apr 2007

Davor Ocelic,,

This is a working, up-to-date guide for performing a network install of the Silicon Graphics IRIX 6.5 operating system onto a SGI MIPS workstation.

A GNU/Linux machine will be used and configured as the remote install server.

So, let's go!

Table of Contents

  1. Introduction
  2. SGI MIPS Workstations
  3. SGI IRIX 6.5 Software
  4. Overall install procedure
  5. GNU/Linux installation server, the configuration
  6. SGI client machine
  7. Post-install steps


To perform a network installation of SGI IRIX 6.5 on a SGI MIPS machine, we will need the following:

SGI MIPS workstations

For obtaining SGI MIPS workstations, check out the following resources:

For basic desktop play, all workstations, including old Indys, Indigos, and O2 are fine.
400MHz Octane and newer machines are even usable for normal computer use, except that there is no "modern" web browser on them.
The latest/last workstation from SGI was SGI Tezro, sold between 2003 and 2006, with CPU configurations ranging from 1x700MHz to 4x1GHz.

You can see various modern SGI/MIPS performance videos on Irinikus' video channel.

SGI IRIX 6.5 software

IRIX release 6.5.30 is the last/newest version and is recommended for SGI Octane and newer workstations.
IRIX release 6.5.22 is the last version working on older workstations (Indy, Indigo2, O2, ...).
It is recommended to use the highest IRIX release supported by your machine to get all the important software patches etc.

Install server - directory structure

On the GNU/Linux server machine, we will need to prepare the toplevel directory in which we will place all IRIX files.
This is true regardless of whether you have the IRIX 6.5 CDs or you want to download the install files from the Internet.

We will create a user named irix and use its home directory /home/irix/ as the toplevel directory for everything.
There are actually a couple steps we will do here as part of the whole procedure. We will:

  1. Install mksh which must be set as the user's shell
  2. Create the user using mksh as its shell
  3. Allow the SGI IRIX 'inst' programs to access this account
  4. Create subdirectory i/ which will hold the IRIX 6.5 files
  5. Make everything in the home directory owned by root and read-only
  6. Add a link from the TFTP root directory to the install files

The following commands will set up the whole thing (don't skip or change anything, everything shown here is required):

apt-get install mksh

adduser --home /home/irix --shell /bin/mksh --system --group --disabled-password --gecos 'SGI IRIX' irix
echo '+ root' > /home/irix/.rhosts
mkdir /home/irix/i
chown -R root:root /home/irix

mkdir -p /srv/tftp
ln -sf /home/irix/i /srv/tftp/i
Please note the line '+ root' above, which we add to /home/irix/.rhosts.
This line will allow IRIX 'inst' clients to connect to this account without a password, as required.
Instead of using a "+" to indicate all machines, you could enter the client's IP specifically, such as
However, the assumption here is that in the case of multiple SGI client machines, you probably do not want to maintain their list of IP addresses in this file, so a "+" is used in our case.

SGI IRIX 6.5 install tarballs

In case you do not have IRIX 6.5 installation CDs, you can download the following tarballs.
I suggest downloading them into directory /home/irix/i/ for common files, and then in subdirectories 30/ and 22/ for IRIX 6.5.30 and 6.5.22 respectively.
(But the directory structure is free-form; you can use any any more developed hierarchy that will suit your needs, for example if you also want to create directories for storing IRIX 6.2 and IRIX 5.3 installation files. Here we are dealing with IRIX 6.5 only, so we will place the files directly under i/, i/30/, and i/22 respectively)

mkdir -p /home/irix/i
cd /home/irix/i

# Always download these for IRIX 6.5, regardless of minor version:
wget -c
wget -c
wget -c
wget -c
wget -c

# Then, for IRIX 6.5.30:
mkdir cd /home/irix/i/30
cd /home/irix/i/30
wget -c
wget -c
wget -c
wget -c
wget -c

# And/or for IRIX 6.5.22:
mkdir cd /home/irix/i/22
cd /home/irix/i/22
wget -c
wget -c
wget -c
wget -c

Unpacking the SGI IRIX tarballs

If you have the above tarballs, simply execute the following in each directory where tarballs have been downloaded. In our example this were directories /home/irix/i/, /home/irix/i/30/ and /home/irix/i/22/:

for p in *.tar.gz; do tar zvxf $p; done

Unpacking the SGI IRIX CDs

If you have IRIX software on CDs, the procedure is just a little bit more involved.

SGI CD-Roms have an EFS filesystem on them and a 512-byte block size.
GNU/Linux of course supports EFS, but typical PC CD-Rom drives usually cannot mount SGI CD-Roms because they do not support the 512-byte block side.

The solution is to dd CD images to disk. That will create .efs image files, which can then be mounted locally from the hard disk using mount -o loop -t efs, avoiding the block size issue.
Once mounted, one can access the files in the images and copy them over.

Here's the procedure that should be done for each CD you have:

cd /home/irix/i/

# Make a raw copy (image) of the CD:
dd if=/dev/cdrom of=efs.img  # (Don't worry about any read errors reported at the end)

# Mount the image from disk:
mkdir -p tmp
mount -o loop -t efs efs.img tmp

# Copy files found in the image to the filesystem:
# NOTE: See below for what to put instead of "IMAGE_NAME"
cp -a tmp IMAGE_NAME

# Done with this CD, clean up:
umount tmp
rm efs.img
IMAGE_NAME: For each CD, this should be replaced with the actual "name" of that CD.
We suggest that you use the same directory names which would be used with the tarball method, which are: apps, capps, developmentlibraries, devf_13, disc1, disc2, disc3, foundation1, foundation1, and onc3nfs.
The directory must not exist before running the cp -a command! If it does, you will end up with files copied to IMAGE_NAME/tmp/ rather than to IMAGE_NAME/ directly.
So if it exists, either first remove it or use rsync -av tmp/ IMAGE_NAME/ instead of cp. In the case of using rsync, make sure that there is an ending "/" in "tmp/", or you will end with the same effective problem as with cp.

Notes: if you have Development Foundation and Development Libraries CDs, make sure they are version 1.3 as that version will match the 7.4.x compiler series you will want to install later.
The tarball links above do contain these versions.

Directory structure

After following the procedure above and copying the files, you should end up having /home/irix/i/ with a series of subdirectories in it.
The output of ls -alR should look like this (if you didn't use tarballs ignore the .tar.gz files):

cd /home/irix/i
ls -alR

drwxr-xr-x 9 root root 49152 May 29 02:55 .
drwxr-xr-x 3 root root 49152 May 29 01:12 ..
drwxr-xr-x 3 root sys   4096 Feb 18  2009 developmentlibraries
drwxr-xr-x 3 root sys   4096 Feb 18  2009 developmentlibraries.tar.gz
drwxr-xr-x 3 root sys   4096 Feb 18  2009 devf_13
drwxr-xr-x 3 root sys   4096 Feb 18  2009 devf_13.tar.gz
drwxr-xr-x 3 root sys   4096 Feb 18  2009 foundation1
drwxr-xr-x 3 root sys   4096 Feb 18  2009 foundation1.tar.gz
drwxr-xr-x 3 root sys   4096 Feb 18  2009 foundation2
drwxr-xr-x 3 root sys   4096 Feb 18  2009 foundation2.tar.gz
drwxr-xr-x 3 root sys   4096 Feb 18  2009 onc3nfs
drwxr-xr-x 3 root sys   4096 Feb 18  2009 onc3nfs.tar.gz

drwxr-xr-x 9 root root 49152 May 29 02:55 .
drwxr-xr-x 3 root root 49152 May 29 01:12 ..
drwxr-xr-x 3 root sys   4096 Feb 18  2009 apps
drwxr-xr-x 3 root sys   4096 Feb 18  2009 apps.tar.gz
drwxr-xr-x 3 root sys   4096 Feb 18  2009 capps
drwxr-xr-x 3 root sys   4096 Feb 18  2009 capps.tar.gz
drwxr-xr-x 3 root sys   4096 Feb 18  2009 disc1
drwxr-xr-x 3 root sys   4096 Feb 18  2009 disc1.tar.gz
drwxr-xr-x 3 root sys   4096 Feb 18  2009 disc2
drwxr-xr-x 3 root sys   4096 Feb 18  2009 disc2.tar.gz
drwxr-xr-x 3 root sys   4096 Feb 18  2009 disc3
drwxr-xr-x 3 root sys   4096 Feb 18  2009 disc3.tar.gz

drwxr-xr-x 9 root root 49152 May 29 02:55 .
drwxr-xr-x 3 root root 49152 May 29 01:12 ..
drwxr-xr-x 3 root sys   4096 Feb 18  2009 apps
drwxr-xr-x 3 root sys   4096 Feb 18  2009 apps.tar.gz
drwxr-xr-x 3 root sys   4096 Feb 18  2009 disc1
drwxr-xr-x 3 root sys   4096 Feb 18  2009 disc1.tar.gz
drwxr-xr-x 3 root sys   4096 Feb 18  2009 disc2
drwxr-xr-x 3 root sys   4096 Feb 18  2009 disc2.tar.gz
drwxr-xr-x 3 root sys   4096 Feb 18  2009 disc3
drwxr-xr-x 3 root sys   4096 Feb 18  2009 disc3.tar.gz

The first files that will be booted remotely from the SGI workstation are the files from the "Installation Tools and Overlays 1" CD, that is, the files from disc1/stand/, file disc1/dist/sa, and files from disc1/dist/miniroot/.
To further confirm that the directory structure is correct and that you have these files, your output when listing them with ls -al should look like this:

cd /home/irix/i
ls -al 30/disc1/dist/sa 30/disc1/dist/miniroot 30/disc1/stand

-rwxr-xr-x 1 root root 20067840 Feb 21 2011 30/disc1/dist/sa

-rwxr-xr-x 1 root root 11753200 Feb 21 2011 unix.IP27
-rwxr-xr-x 1 root root 10804368 Feb 21 2011 unix.IP30
-rwxr-xr-x 1 root root  8330648 Feb 21 2011 unix.IP32
-rwxr-xr-x 1 root root 12819040 Feb 21 2011 unix.IP35

-rwxr-xr-x 1 root root  516752 Feb 21 2011 fx.64
-rwxr-xr-x 1 root root  274940 Feb 21 2011 fx.ARCS
-rwxr-xr-x 1 root root 1598624 Feb 21 2011 ide.IP30
-rwxr-xr-x 1 root root  750032 Feb 21 2011 ide.IP32
-rwxr-xr-x 1 root root  266768 Feb 21 2011 sash64
-rwxr-xr-x 1 root root  343604 Feb 21 2011 sashARCS
(The fx.64 and fx.ARCS are the disk partitioning programs you will use before starting the actual installation.
The extension "64" or no extension indicates a 64-bit variant, and "ARCS" indicates 32-bit.)

Overall install procedure

So, how it's gonna work?

The first contact the SGI workstation will make with the GNU/Linux install server will be using the bootp protocol ("Internet Bootstrap Protocol"). This service will allow the client to configure its own basic settings like name, server name, IP addresses, and the initial boot file.
So on the Linux server we will install and configure bootp.

Then, the SGI client will use the TFTP protocol to download the basic files needed to start the installation program. This will include files such as i/30/disc1/stand/sash*, i/30/disc1/stand/fx*, i/30/disc1/dist/sa, and i/30/disc1/dist/miniroot/unix.IPXX.
For that, we will install and configure tftpd.

And finally, once the installation program ('inst') starts, it will no longer use bootp or tftp, but it will use rsh to connect to the install server and transfer files.
For that, we will install and configure rsh server.

Let's go!

GNU/Linux installation server, the configuration

At this point we need to configure the described server software on the GNU/Linux machine to act as an IRIX install server.

Your choice of GNU/Linux distribution is not particularly important, although this guide shows examples for Debian-based distributions like Debian GNU, Ubuntu, and Devuan GNU+Linux.

If using a different distribution, make sure that you use the exact software packages as listed here, because other seemingly equivalent packages have various subtle differences in behavior, and older SGI clients will not work with them.

Also, before we begin with the configuration, our example network will look like this:

Hostname IP Address Purpose / Function
srv1 GNU/Linux install server
boyd SGI IRIX workstation (being installed)

These machines can be connected via ethernet either directly or via a switch, the choice doesn't matter.

Network configuration

For installing older machines like Indy or Indigo, you might need to run the following to solve any network problems that a MIPS PROM might have when talking to a GNU/Linux server:

echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
echo "2048 32767" > /proc/sys/net/ipv4/ip_local_port_range
Note that the above settings are not retained over a server reboot, so if you want to make them permanent, do so by adding them to the system startup files such as /etc/sysctl.conf, /etc/sysctl.d/local.conf, /etc/, /etc/rc.local or similar file.

Packages and configuration

Now, we will install some specific versions of software, which all exist in Debian so you won't need to download them manually, but they are listed here for completeness or help if you're not using Debian:

So, let's do all the installs and configurations:
apt-get install openbsd-inetd bootp tftp rsh-redone-server rsh-redone-client

# Then edit /etc/inetd.conf and:
# 1. Remove '#' at the beginning of 'bootps' line and add "-d 4" to the end
# 2. Enable 'tftp' if not already enabled and add option -s to it
# 3. Enable 'shell' if not already enabled
bootps         dgram   udp     wait    root    /usr/sbin/bootpd        bootpd -i -t 120 -d 4
tftp            dgram   udp     wait    nobody  /usr/sbin/tcpd  /usr/sbin/in.tftpd -s /srv/tftp
shell           stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rshd

# Then edit /etc/bootptab to add an entry for the SGI client machine:
# Only two fields are needed:
# 1) Intended client machine hostname (must be hostname, not IP). It doesn't matter if the hostname resolves or not.
# 2) IP address the client will connect from (and later have)

# And reload all services
pkill bootpd in.tftpd
pkill in.tftpd
pkill in.rshd
invoke-rc.d openbsd-inetd reload

Monitoring log files on GNU/Linux install server

It is absolutely necessary to be monitoring the logs while trying to connect to the Linux server from SGI clients.

So, make sure you have the following running on Linux:

tail -f /var/log/*log -n0
Make absolutely sure that you are watching the logs because we will now test bootp, tftp, and rsh.

Testing bootp and tftp

Before continuing any further, it is crucial to confirm that the bootp and tftp server we have configured above now indeed work, and are usable from the SGI client.

Historically, the intricacies of the Netkit "bootpd" server and incorrect flavors of tftpd were causing various hurdles here.
However, our configuration gives a minimal, tested setup that should work without problems.

The best way to test the whole thing consists of just two steps:

  1. On the Linux install server, monitor the log files with tail -f /var/log/*log -n0
  2. On the SGI client, try to boot "sash" ("standalone shell"). The complete procedure for that is as follows:
    1. Turn on the SGI machine
    2. Press ESC during "Starting up the system" to bring up menu
    3. Press 5 to go to Command Monitor (PROM shell)
    4. Set the IP address of the client: setenv netaddr
    5. Disable tape (for older systems): setenv notape 1
    6. Boot sash (type it exactly as shown here): bootp():disc1/stand/sash64
(Of course replace sash64 with sashARCS if you are installing a 32-bit system.)

In the PROM shell, for easier typing you can invoke previous command lines (similar to Arrow-Up in Readline) with the key combination Ctrl+p.

Also, before trying to boot sash, you can type "?" to see the list of available commands, and you can play around with commands like "hinv" and "printenv".
There is also "ping", but this command will not work so you can't use it as a test of network connectivity.

When you run that bootp() line, you should see some logs scrolling by on the Linux server, and on the SGI client you should now be in "sash".

If it works, this is absolutely great. You can look around with command "?" if desired, and then press Ctrl+d to exit sash and get back to the PROM monitor.

The rest of this section deals with troubleshooting in case the sash test didn't work. You can skip it and move to the next section if your test was successful!

So, if bootp() of sash didn't work, there could be only 7 causes (and solutions!) to this:

  1. Firewall on the Linux machine is preventing incoming connections.
    Run iptables -L -vn to ensure that the firewall is not getting in the way.
    If you are not seeing "policy ACCEPT", the easiest way to flush everything and allow all connections is to run iptables --flush; iptables -P INPUT ACCEPT; iptables -P OUTPUT ACCEPT
  2. No bootpd or tftpd service is running on the Linux server at all.
    In our setup, bootpd and tftpd are started via inetd, so actually you want to ensure that inetd is running and listening on UDP ports 67 and 69.
    The easiest way to confirm this is to run netstat -nlp |grep :6.
    If inetd is not listed on these ports, re-check all the steps you did above as part of "Bootp configuration" and "TFTP configuration".
  3. There is no network connectivity between client and server.
    An indication of this would be that you checked the previous two points and they are OK, but there are still no any logs scrolling on the Linux server when you run bootp() on the SGI client.
    To fix it, check network hardware connectivity and also try connecting the machines with a cable or different cables directly, to rule problems with the ethernet switch or a particular cable.
    Also, while here, check that both the Linux server and the SGI client have the intended IP addresses.
    This can be checked with ifconfig -a or ip a on Linux, and with printenv netaddr in the SGI PROM.
    To re-set the IPs, this is done again with ifconfig or ip on Linux, and with setenv netaddr ... in the SGI PROM shell.
  4. There are unclear network transfer problems.
    This might happen with older machines if you did not run the configuration lines given above under "Network configuration", or if you rebooted the Linux server and these settings got reverted.
    Re-check the "Network configuration" section and repeat the steps there again.
  5. Bootpd server receives requests, but ignores them.
    This dreaded condition can be confirmed by seeing bootpd log messages such as:
    May 29 19:02:34 srv1 bootpd[3044]: ignoring request for server from client at Ethernet address 01:00:99:13:fd:f8
    This is caused by incorrectly-functioning code in the bootpd server which determines whether it should handle the incoming bootpd request or not.
    You should not run into this problem if you have executed bootp() on the SGI client the way we have shown above ("bootp():disc1/stand/sash64"). Our method purposely does not include the bootpd server name in that line, so that bootpd would unconditionally try to handle this request instead of running the decision function.
  6. There are multiple bootpd servers already present on the network, and the wrong one is trying to handle the request.
    This problem is basically the opposite of the previous one. Instead of too few servers available to handle the request, you have too many :).
    Either remove the other bootpd servers, or specify the bootpd server name in the bootp line on the SGI client, such as: bootp()srv1:disc1/stand/sash64
    HOWEVER, if you specify server name explicitly, three conditions must hold true for the Linux bootpd server to respond as expected:
    1. The name of the server which you specify in bootp() line must be a hostname and not an IP address
    2. The name of that server must be identical to the output of the command "hostname" on the Linux server
    3. And, on the Linux server, this hostname must resolve to its own name, regardless of the actual IP to which it resolves! If you do not have a DNS server running, then the easiest way to achieve this is to add an entry to /etc/hosts on Linux, using any IP address. In our case of an example server named "srv1", this would be done with command echo " srv1" >> /etc/hosts.
      (As mentioned, the IP to which the server hostname resolves is not relevant to bootpd, but you could certainly use the actual network IP of the server to be fully correct.)

  7. Bootp works, but TFTP doesn't find files which are requested.
    There are a couple possible causes here, all simple:
    1. One obvious problem here could be that you typed an incorrect boot filename. This could be verified by looking at the logs scrolling by on Linux, and seeing if the filenames appear correct. Checking the logs in this way will be easy if you are monitoring them with "tail -f /var/log/*log -n0" as we advised above. In case the useful content has scrolled out of the screen, use Shift+PgUp/PgDown to move around, and/or Ctrl+s and Ctrl+q to pause and resume output respectively.
    2. Another problem could be that the SGI system you are trying to install is legitimately not finding the necessary files. This could happen if, for example, you unpacked the IRIX 6.5.30 distribution, but are trying to install an older machine such as Indy or O2, or the files needed for the machine architecture (32bit / 64bit) are not found.
    3. And finally, the files could end up not being found if the TFTP configuration is incorrect, or your bootp request path is incorrect. To verify/fix this, re-check the "TFTP configuration" section above and pay attention specifically to the tftpd option "-s" and the tftp root directory which should be set to "/home/irix/i". Then, make sure that the files are indeed there in /home/irix/i (for that, re-check the section "GNU/Linux installation server, the IRIX installation files"), and make sure that you are not including "/home/irix/i" in your bootp lines. Specifically, if everything was configured as advised, then a bootp request for file "disc1/stand/sash64" will translate to file "/home/irix/i/disc1/stand/sash64" on the Linux server, and you should double check that this file really exists.
  8. Are you seeing any other problem not listed here? Let me know.

Testing rsh

Testing RSH is easy. Since our user's .rhosts file includes a "+ root", this means passwordless logins to this account are available from user root on all machines, including localhost.

(Ideally we would want to check the connection from the SGI client, but since we have already confirmed the network connectivity with the bootp/tftp test, we can simplify here and just try a local passwordless login into the account.)

As root, run the following:

rsh irix@0
If it works, press Ctrl+d of course to log out and get back to your prompt.

If it doesn't work, re-check the user setup, RSH setup, and the system logs that show up when you try to connect.

SGI client machine


Before you start the installation, check if your CGI machine has multiple monitor outputs. If so, make sure that the monitor cable is plugged into the first monitor.
E.g. in the case of a DCD (Dual Channel Display) option for Tezro, this would be the bottom-right DVI port when looking from the back.
Things will work just fine even if you connect the monitor to the other port, but when the installation completes and the system reboots into a graphical login, you will be looking into a secondary/empty screen instead of the login prompt.

Beginning with the installation

So, let's begin:

Invoking the partitioner

Always run fx to set up or verify partitions, but particularly if you are installing over an old IRIX version that used the EFS filesystem (i.e. IRIX 5.x).
If you do not change the old EFS partition type, IRIX 6.5 will honor the EFS setting and require the EFS packages.
EFS packages might not exist in your IRIX 6.5 distribution, and will prevent you from starting the installation.

In the Command Monitor / PROM shell, run:

bootp():i/30/disc1/stand/fx.64 -x
(Remember, .64 for 64-bit, .ARCS for 32-bit)

If invoking the partitioner does not work, refer back to the section "Testing bootp and tftp".
We have tested the install server there by trying to run "sash". This here isn't any different, except that we are booting "fx.64 -x" instead of "sash64".

Partitioning instructions

When fx starts up, it will ask three questions to determine which drive you want to partition:

fx: "device-name" = (dksc)
fx: ctlr# = (0)
fx: drive# = (1)
...opening dksc(0,1,0)
Just press ENTER three times.
If you've got multiple disks, the second disk will be drive# 2 and so on.

fx supports hierarchical menus. To display the current partitioning layout on the disk, you can type "label", "show" and then "partitions".
A shorthand notation for this is "l", "sh", "part". Or even for all at once, you can type "l/sh/part".

If you type "l", "sh", etc. and get deeper into the menu hierarchy, you can go back a level by typing ".." or multiple levels by typing "../.." etc.
If you want to partition another disk, you can type "/.." and 'fx' will exit all menus and present you with the new disk chooser prompt.
If you want to interrupt any current command or prompt, press Ctrl+c.

To partition your main/root disk, choose "[r]epartition/" and "[ro]otdrive", accept "xfs", and type "yes". An alternative way for the same thing is to run "[l]abel", "[c]reate", "[a]ll".
To partition an additional disk, choose "[r]epartition/" and "[o]ptiondrive", accept "xfs", and type "yes".

If you are done partitioning, type "/exi" to exit fx and return to the PROM monitor.

Starting the installation

There are two ways to start the installation:

  1. From the PROM shell
    1. Find out the "IPXX" value appropriate for your SGI machine:
      You can do this by finding your SGI workstation model listed on, then opening its page and searching for mentions of "IP".
      The value you see is the value you want (e.g. "IP30"), except for "IP53" which means "IP35".
    2. Once you have the IPXX value, verify that your IRIX installation files on the Linux server contain file "/home/irix/i/30/disc1/dist/miniroot/unix.IPXX".
    3. Finally, in the SGI PROM press "5" to go to the shell, and then start the installation with:
  2. From the PROM menu (see NOTE below if you use this option)
    1. In the SGI PROM press "2" for "Install system software"
    2. Press "1" for "From remote directory"
    3. Type "srv1" as server name (or your actual hostname of the Linux install server)
    4. Type "i/30/disc1/dist" as path

NOTE FOR OPTION 2: For this method to work, your Linux server must satisfy all 3 requirements listed above in the section "Testing bootp and tftp" under its troubleshooting item #6.

After starting the installation on the SGI, it will create a "miniroot" on the local disk by transferring the installation data from the remote server to it.

If working with a new disk, the installer will ask to format partitions and the block size to use. Use 4096kB block size for disks larger than 4GB, 512B otherwise.

The installer might then ask you:

What is the hostname (system name) of your machine?
What is the network address of ____?
Answer with the same hostname and IP address you have dedicated to this machine in /etc/bootptab on the Linux install server.

Installation, first steps and opening distributions

At this point you should be in the 'inst' prompt.

If you are working with a non-clean disk, you must erase the disk by choosing "13", "11", "y", and "yes" in inst menus.
Also, inside Admin menu ("13"), you can choose options "12" and "13" to re-set the machine hostname and IP, just to be sure that they have the values you want. (Set these fields to the values you have intended for this system in /etc/bootptab on the Linux server.)
Then type ".." to exit Admin mode and go back to regular inst.

Now you need to load the available packages for installation by "opening" the first software distribution.
This is done using command "from" for the first image ("Installation Tools and Overlays 1"), and command "open" for all subsequent/additional images.
Inst might also keep you in a repeating prompt that allows you to easily open previously-used distributions and reduce the amount of typing.

Note that, as we mentioned earlier, the access to the Linux server at this stage is no longer being done via bootp/tftpd. Inst uses rsh.
Therefore, when you specify distributions to open, you need to include both the username and the Linux server's IP.
Also, please note that since TFTP is no longer involved and we are working with RSH, the file paths are no longer automatically prefixed with "/home/irix"; theoretically meaning we should be including /home/irix ourselves now.
However, since we have set the irix user's home directory to "/home/irix", we can continue using "i/30/disc1" and other paths without prefixing them with /home/irix.

Here's how the session would look like from "from" onwards:

from irix@

# The installation will then ask whether you want to install the "Maintenance" (compatibility) or "Feature" (features) stream.
# Choose "Feature" unless you know why you want "Maintenance".

Then open the following additional distributions:


After you have loaded all the distributions, run the following:

keep *
install standard
install prereqs
rem java_dev.*

At this point, you should run conflicts in inst to check if there are any important unresolved dependencies.
If everything went as planned, there should be only one, for java2_plugin.sw.mozilla_freeware, which you remove from installation by typing conflicts 1a

The response from the above should finally be "no conflicts", and then you can type go to start the software installations and quit when they are done.

After the procedure is done and you reboot, you should find yourself in your shiny new IRIX 6.5 installation!

Post-install steps

There are a couple things you could/should do at this point:

Download and install patches from

Familiarize yourself with the SGI user community which now lives at, and introduce yourself in its forum.
Find more files and programs to install from resources listed at

Familiarize yourself with Nekoware, a collection of user-contributed and maintained open source packages for IRIX. Nekochan has been abruptly and without notice shut down by its founder Peter Plank (Nekonoko), but the mirror/archive of Nekoware can be found at

For installing Nekoware, you can either mirror the complete thing yourself, or you can use the script at to automatically list, select, download, and install Nekoware programs and their dependencies. plans to revive the IRIX porting software and replace Nekoware, but this did not meterialize yet in any significant user-visible percentage.

Check out resources at This page contained links to ALL relevant resources that existed on Nekochan wiki. Unfortunately, those links weren't all archived so a lot of links pointing to Nekochan on that page are no longer accessible, but at least it shows you what the topics/things were (so you can try to find a copy), and other links are working.

There is a number of useful or necessary things that should be done on the IRIX system after installation. Instead of listing those steps manually, they were all converted into shell scripts, ready to be downloaded and executed. See: (link to come soon).

Finally, if you have adequate server resources, offer to contribute them to That site currently does not host media files due to cost, which is a huge impediment to a community that arose from once famous computer graphics company.

I hope this is all and works on the first try. Comments/suggestions/feedback welcome.