Installing IRIX 6.5

This document explains how to install IRIX 6.5 in a manner which should be applicable to most IRIX systems. I have installed IRIX 6.5 on Indy, Indigo2, O2, Octane, Challenge, Onyx, Onyx2 and Origin systems.

The procedure for installing IRIX 6.5 is not quite the same as installing IRIX 6.2. SGI improved the way the installation is handled, aswell as how updates are dealt with. If you're someone who has to deal with installing IRIX 6.5, this page should help alleviate some of the more common concerns. Installing 6.5 is, in my opinion, actually very easy. I've done it literally hundreds of times now. However, I do not cover advanced post-installation topics such as configuring the Unified Name Service Daemon, and I do not yet have any experience of installing 6.5 on certain systems such as Personal IRIS, Crimson, SkyWriter, POWER Series, Onyx300/Origin300, Onyx3000/Origin3000 and the new Fuel system. Don't rely on my advice alone if you're dealing with systems that I have not used; read any instruction booklets provided too.

The instructions given here assume a typical setup: an IRIX system with the root disk on SCSI controller 0, ID 1, and a locally attached CDROM on SCSI controller 1, ID 4. This would be typical of an O2 or Indigo2 installation, for example. An Indigo2 with an internal CDROM, or an Indy with an external CDROM, would have the CDROM on SCSI controller 0.

My philosophy for installing 6.5 is, when possible, to install the original June 1998 base CD set first, get the system up and running, login, run swmgr and then start installing all the extra items. Some poeple prefer to install as many CDs as possible in the first instance, but I don't like doing it that way. Using swmgr to install the numerous other CDs later is definitely easier in my opinion.

If necessary, make a complete backup of the system disk, just in case anything goes wrong. This isn't relevant of course if the disk is empty, eg. a new disk. Details on how to backup the system disk can be found on my Disk and Filesystem Administration page.

If you are upgrading from an older OS such as 6.2, 6.3 or 6.4, I recommend reading through the release notes before installing 6.5. There are various changes which you may need to be aware of. Note that IRIX 6.5 cannot be used with Crimson systems!

The OS installation is done by a program called inst, which is on the CD entitled, "IRIX 6.5 Installation Tools, June 1998". This must be loaded and read first from miniroot. Normally, one uses the fx and mkfs programs to prepare the disk ready for installation.

Clearing Old Data Prior to Installation

One can use another IRIX system to do this, but do not use a non-6.5 system. This is because the volume header information is not quite the same in 6.2 compared to 6.5. Also, if you use a much later version of 6.5, eg. 6.5.15, then the older 6.5 boot kernel on the CD will not be able to mount a disk which has been fx'd using the fx program from the running IRIX system. I guess some changes were made to fx later on that introduced some minor incompatibilities. It doesn't matter if you intend to boot from the corresponding later Installation Tools and Overlays CD for the main installation, but it does matter if you intend to boot using the original June 1998 Installation Tools CD. Thus, it's better to use the boot version of fx from the CD you're going to use to repartition the disk, unless you happen to have a running IRIX system that has just 6.5 with no updates.

Thus, the normal way to clear any old data and begin the installation is as follows:

Boot up the system, press ESC to obtain the Command Monitor. At this point, an extract from the IRIX online manual, "System Configuration and Operation", is useful to explain what is happening here:

The command monitor has been designed to keep it independent of operating systems and as small as possible. Therefore, the command monitor cannot directly boot files residing in IRIX or other operating system file trees. However, the command monitor provides a two-level boot mechanism that lets it load an intermediary program that understands filesystems; this program can then find and load the desired boot file. The program is called the standalone shell, and is referred to as sash. sash is a reconfigured and expanded version of the command monitor program, and includes the modules needed to handle operating system file structures. It also has enhanced knowledge about devices. After the system software is installed, a copy of sash is located in the volume header of the first disk. The header contains a very simple file structure that the command monitor understands. You can also boot sash from tape or across the network.

Thus, the idea is to boot into sash on the CDROM and from there into fx, the main IRIX disk utility program.

Enter hinv if necessary to confirm the SCSI controller number and SCSI ID number of the CDROM. Enter the following command to boot from the CD (make sure the 'Installation Tools' CD is in the CDROM drive):

    boot -f dksc(X,Y,8)sashARCS dksc(X,Y,7)stand/fx.ARCS --x

where X is the SCSI controller number, and Y is the SCSI ID of the CDROM drive. According to the fx man page, the above command applies to systems with the 32bit ARCS PROM, namely Indigo, R4K Indigo2, Indy, Onyx, Challenge and O2.

For systems with the 64bit ARCS PROM - POWER Challenge, POWER Onyx, POWER Indigo2, Indigo2 10000, Origin, Onyx2, Octane, and all newer systems - use this command:

boot -f dksc(X,Y,8)sash64 dksc(X,Y,7)stand/fx.64 --x

although note that some systems may show the device as cdrom(x,y,z) rather than dksc(x,y,z). I found this to be the case on my Origin200 and so the command I used was as follows (the CDROM was on SCSI controller 1, ID 6):

boot -f cdrom(1,6,8)sash64 cdrom(1,6,7)stand/fx.64 --x

In some cases, often IRIS Indigo for unknown reasons, one may have to boot in two stages, first into the sash and then into fx. I suspect this may happen because the CDROM doesn't quite responding as expected on older hardware. Either way, just split the boot command sequence into two steps if required, eg. the typical sequence might be:

    boot -f dksc(X,Y,8)sashARCS
    boot -f dksc(X,Y,7)stand/fx.ARCS --x

You will now be in the fx program. Press enter until you see the main menu (I'm assuming that controller 0, ID 1 will indeed be your root disk). Enter 'r' for repartition, 'ro' for root drive option, press Enter to confirm XFS, enter 'yes' to confirm the request, '..' to change menus up one level, 'l' to create a new disk label, 'sy' to sync the disk (write out the new label), and finally '/exit' to quit fx.

The system will return to the System Maintenance menu. Select Install System Software (or press 2) and choose the appropriate icon for the attached CDROM. After reading in the installation tools, some IRIX copyright information will be shown.

At this point, if the disk is completely new, or if an older type file system is on the disk (eg. an old 6.2 installation), then the system will automatically detect that there is no valid file system. A message will appear, asking whether you would like to create a new file system. Answer yes and follow the instructions, choosing a block size of 4096 if your disk is 4GB or larger - otherwise choose a block size of 512. A new file system will be created.

A README file will be displayed (press Q to stop it paging if necessary) and then a question appears, asking whether you would like to run the available 6.5 install script. Answer in the negative by entering '2' for 'Ignore'. The rest of the README will be displayed and then the inst prompt appears. If the system has already created a new file system as described above, then you can skip the next section on manually erasing the disk within the inst program; go to Reading the CDs.

Erasing the Disk Within the Inst Program

There are two ways of doing this, either using the Admin menu, or by going into a shell. If your disk is 4GB or larger, then use the Admin menu as follows:

1. Enter 13 at the Inst prompt to select the Admin menu,

2. Enter 11 to select mkfs,

3. Enter y and confirm the action of making a new file system on the disk. This will use a 4096 block size.

4. Enter '..' to return to the Inst menu.

1. Enter 'sh' at the Inst prompt to go into a shell.

2. Unmount the system disk from the miniroot file system by entering:

       umount /root/hw
       umount /root
   

   An older installation on the disk may have attempted to mount other file systems. If so, unmount them before unmounting /root (enter 'mount' on its own to see the current mounted file systems).

3. Use mkfs to make a new file system (this assumes the normal system disk location as controller 0, ID 1):

       mkfs -b size=512 /dev/dsk/dks0d1s0
   

4. Now remount the system disk and go back to the Inst prompt (CTRL+D here means hold down the CTRL key and then press D):

       mount /dev/dsk/dks0d1s0 /root
       <CTRL+D>
   

There are minor variations on the above procedures. If you have any queries, please email me.

You should now be at the inst prompt once again, with a clean disk ready to install onto.

Reading the CDs

It is at this point that one can commence the installation process, which begins with reading in the base set of four IRIX CDs. Enter 1 and then enter the following to read in the installation tools CD:

   /CDROM/dist

   keep *
   install standard
   install prereqs

When I first wrote this page, I used the results of installing IRIX 6.5 on different systems as a simple benchmark, and to show how a faster CDROM is not as important as a faster CPU. At the time, I ran a network of 19 Indys and a ChallengeS at the University of Central Lancashire (UCLAN) in Preston. My results were initially based on installing onto those systems, and onto Indigo2s/O2s at home. Since I don't work at UCLAN anymore, I decided to rewrite this benchmark section and just list the results with much less introduction, etc. See my SGI General Performance Comparisons page for a complete discussion on these results.

The installation test times given here do not include the 'human' element of the installation procedure, eg. switching CDROMs, typing in commands, etc. When using my stopwatch to time the installations, I halted the stopwatch whenever a prompt appeared and restarted the stopwatch once the required input was entered and the procedure again underway.

Here is a complete table of installation times which includes results from other system configurations, plus details of intermediate stages (you may need to widen your browser window to see all of this table at once):

Key: Read Inst Tools = From the moment the progress bar appears to when the screen changes (eg. goes black) after the data has been fully read.

                               ******** Sub-Task Completion Times ********
                               (16%) (51%)  (86%)  (91%)  (94%)   (100%)
                   CD   Read   Pre-                       Inst    End of  End of
                   ROM  Inst   inst  F 1    Apps   F 2    Tools    Exit   rqsall
                        Tools  Ends  Ends   Ends   Ends   Ends     Coms   ELF libs

O2 R5000SC/200:    32   0:42   0:54  06:31  15:07  16:46  17:45   22:52   0:34:06
O2 R5000SC/200:    12   0:46   0:54  06:58  16:04  18:05  19:20   24:08   0:35:28
I2 R4400SC/250:    32   0:47   1:11  06:45  15:17  16:57  17:55   23:12   0:36:05
I2 R4400SC/250:     2   1:16   1:11  09:18  21:06  23:28  24:38   29:57   0:42:31
Indy R4400SC/200:  32   0:42   1:26  08:32  19:42  21:40  22:50   29:41   0:45:24
Indy R4400SC/200:   2   1:16   1:26  11:11  25:49  28:29  29:58   36:53   0:52:35
Indy R4600PC/133:  32   0:44   1:45  11:48  28:26  31:28  33:07   46:11   1:08:45
Indy R4600PC/133:   2   1:16   1:45  14:10  33:37  37:12  39:00   52:05   1:14:39
Indy R4600PC/100:  32   0:35   2:04  12:36  30:18  33:36  35:20   48:28   1:12:11
Indy R4600PC/100:   2   1:16   2:04  15:01  35:33  39:32  41:28   54:54   1:18:36

The Indigo2 result is very interesting. It shows that a faster main CPU definitely helps during software installations, by quite a significant margin, but not during the reading of the installation tools when one is using a slow CDROM. The Indigo2 had a much slower CDROM compared to the O2, yet it only took 22% longer to install the 'Basic Set' of CDs. If the process was solely or mainly limited by CDROM speed, one would expect to see the Indigo2 take at least 100% longer. The times are certainly in stark contrast to the R4600PC/133 Indy results. Note that the post-installation requickstart procedure does not involve the CDROM, so again the 250MHz R4400SC with its 2MB L2 cache is much faster.

When I do software installations, whenever I can I always swap in a faster CPU, assuming I have a compatible CPU available, eg. for installing onto an R4600PC/133 Indy, I'd temporarily put in an R4K/200 CPU instead. This greatly speeds up the installation, and obviously a faster CDROM helps too, but remember to use a compatible CPU, eg. for installing an R4600PC/133, I couldn't swap in an R5000SC/180 since the libraries are not the same. Similarly, one could not put in an R10K/195 in place of an R4K/150 in an Indigo2. What matters is the IP number of the target CPU (in this context, the word IP has nothing to do with network addresses), as shown by hinv, eg. an R4K machine is usually IP22, while an R10K Indigo2 is an IP28. If the faster CPU one would like to swap in for the installation has the same IP number, then it should work ok.

Note that there is not and never was an R5000SC/200 CPU for Indy.

As stated earlier, please see my performance comparisons page for a complete analysis of the installation times.