Installing IRIX 6.5 Across a Network

This write up was done by Ian Mapleson, and is easily found on SGIDepot, but I moved a copy here.

I already have a page which explains in general terms how to install IRIX 6.5, whereas this page is specifically concerned with installing via a network connection from another IRIX system. Familiarity with a normal installation from a locally attached CDROM is assumed.

Installing across a network may be desirable for a number of reasons, usually speed, convenience (disks/CDROM attached to remote system) or necessity. I’ve done network installs on O2s, Octanes and Indys; in each case, a remote disk file system contained local copies of all the relevant 6.5 media. One can take this concept to an extreme degree, eg. I know of a company which has all the 6.5 installation data on a RAID server, with installations done across a Gbit network – if the target host has a Gbit Ethernet port which can be used for the installation, then installing the OS will happen very quickly. Even using a 100Mbit port is much faster than installing from a local CDROM; this is because a CDROM will sustain maybe 4MB/sec at best, whereas a 100Mbit network connection offers as much as 11MB/sec. Ironically, it can even be faster than using a local disk, eg. a disk attached to an Indy can’t give more than a few MB/sec since Indy uses FastSCSI-2, whereas installing across a 100Mbit link will give up to 8MB/sec sustained.

This discussion uses IRIX 6.5 to demonstrate how to do a network install. Similar procedures apply to 6.2. The various protocols and services used are briefly explained, but not in great detail. This page is more of a straight how-to. Consult the relevant man pages and online books for full details.

The setup used was as follows (the original IP addresses and subdomains I use at home have been replaced with generic examples):

Boot/Installation server: an Octane R10K/195 SI 256MB/9GB with a 9GB FW disk attached externally, IP address 192.0.2.10, host name ‘octane’. The external disk was mounted on /i, the contents of the 6.5 inst tools CD (June 98) was in /i/cds/6.5inst such that the path to the installation tools dist directory was /i/cds/6.5inst/dist, with other CD contents also in /i/cds (6.5F1, 6.5F2, 6.5AppsJun98 and nfs). Note that for the purposes of this discussion, I used an external disk containg the data from the 6.5 CDs since this gives a good speed boost compared to installing from a local CDROM. However, there is no reason why the 6.5 data couldn’t be from the normal 6.5 inst tools CD in a CDROM attached to, or in, the server. In many cases this may be the normal setup, eg. an Indy using an Indigo2 with an internal CDROM as the server; using a disk containing the data merely allows me to demonstrate the speed advantages of doing a network installation.

Client: an Indy R5000SC/180 XL24 256MB/2GB with Presenter1280 adapter, hardware Ethernet address 08006907dce8, IP address 192.0.2.5, host name ‘indy’. Most of this document describes an installation which uses the built-in 10Mbit Ethernet port. A further installation is described which uses a Set Engineering FastEthernet card for Indy, showing how to do a network install by using a 100Mbit option card, ie. similar concepts will apply when installing via something like a PCI Gbit card in Octane/Origin. At present, this isn’t applicable to a Phobos card in Indigo2, but I’m working on a way to do it.

Booting across a network uses bootp, the Internet Bootstrap Protocol. The bootp service allows a client to obtain relevant information from a remote server about itself such as its IP address, the address of the server and the location of an appropriate boot file on the server. After this initial data is obtained, the boot file itself is transferred to the client using tftp, the Internet Trivial File Transfer Protocol. Further installation data transfers are also done using tftp, which is managed on the server by the background daemon tftpd.

In order to use these services, some simple changes and additions need to be made to the system which will act as the boot server. These changes allow the initial boot request to be accepted, with the appropriate data determined from system files and sent back to the client.

The changes to the server configuration are as follows (this is what I did on the Octane).

Unlock the Guest account to allow anonymous access, ie. edit /etc/passwd to remove any password entry for the guest account. Remember to secure the account after the installation is complete. Thanks to David Gerard for pointing this out.

Include an entry for the client in /etc/hosts. Thus, the file on octane conained the following entries in addition to the normal default entries:

   192.0.2.5    indy.somewhere.org     indy
   192.0.2.10   octane.somewhere.org   octane

Include an entry in /etc/ethers which matches the client’s hardware ethernet address to the intended client host name. Use the ‘printenv’ command in Command Monitor on the client to obtain the hardware ethernet address (start the system, press ESC when prompted, press 5 to get the command monitor, enter ‘printenv’). Thus, /etc/ethers on octane contained:

#
# /etc/ethers maps Ethernet addresses to hostnames
#
# The library routine ether_line() uses this file.
#
# The format of a line is:
#
#       x:x:x:x:x:x     hostname
#
# where the first field is the 48-bit Ethernet address
# expressed as 6 hexadecimal bytes.
#
08006907dce8       indy

On some systems, the full address may not be shown in the above format (eg. Origin200), in which case try adding 0800 to the start of the address. You can also obtain the address from the original sticker on the back of the machine, though this may not be correct if the system has been upgraded or parts changed. Or you can use the lmhostid command to show the system ID (bootup fully and login to do this), though the output never includes the initial 0800, so remember to add that. Or you can use the sysinfo command, which gives an output such as this:

69 07 dc e8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

It’s the first four 2-digit pairs that matter, in this case ‘6907dce8’, and as with lmhostid remember to prefix with ‘0800’ to obtain the complete address. Thanks again to David Gerard for suggesting I mention these other ways of obtaining the address.

Next, add an entry to /etc/bootptab on the server to specify the location of the boot file. This is the data bootp uses to decide which is the appropriate boot file to send to the client. The client host name, Ethernet address and IP address are all included. Thus, the following was added to the end of /etc/bootptab file on octane:

indy 1 08:00:69:07:dc:e8 192.0.2.5 /i/cds/6.5inst/dist/miniroot/unix.IP22

Which boot file to use depends on the client system. For an Indy, R4K Indigo or R4K Indigo2, it’s unix.IP22. Enter hinv in Command Monitor on the client to determine which IPxx revision you should specify. One can see the available boot files simply by looking in the dist/miniroot subdirectory on the IRIX 6.5 Installation Tools June 1998 CD. The directory contains these files:

    unix.IP19  unix.IP21  unix.IP25  unix.IP27  unix.IP30
    unix.IP20  unix.IP22  unix.IP26  unix.IP28  unix.IP32

Notice that more recent versions are not included, eg. IP35. This is why you may have to use the contents of a particular 6.5 update boot CD in order to perform the boot action, eg. IRIX 6.5.15 Installation Tools and Overlays 1 of 4, February 2002.

A cautionary note from Malcolm Tobias at this point: if the path name to the source directory is too long, the error message, “no space left in string table” will be given. Thus, if you see this message, either change the source location (move the boot files somewhere else) or, as Malcolm did, use a soft link to allow for a shorter path from elsewhere, but remember to add the soft link path itself to the list of permitted tftp directories in inetd.conf.

The final required change is to the /etc/inetd.conf file, to allow the bootp request and tftp transfers to occur. First make sure the shell line (for rshd) is uncommented, ie. if it looks like this:

# shell stream tcp nowait root /usr/etc/rshd rshd -L

then change it to this:

shell stream tcp nowait root /usr/etc/rshd rshd -L

The other relevant lines from /etc/inetd.conf might normally look like this (just the two relevant lines are shown here – in reality, there is a line between these two which refers to dhcp_bootp, but that isn’t important and so isn’t shown):

# bootp dgram udp wait root /usr/etc/bootp bootp tftp dgram udp wait guest /usr/etc/tftpd tftpd -s /usr/local/boot /usr/etc/boot

Change these lines so that they look as follows (essentially, the bootp service is activated, while the removal of everything from ‘-s’ onwards on the tftp line means tftp requests can access any world-readable directory):

bootp dgram udp wait root /usr/etc/bootp bootp tftp dgram udp wait guest /usr/etc/tftpd tftpd

The above change to tftp allows access to any directory, which is fine for closed networks like the one I was using. However, if the server system is on a wider network and/or connected to the Internet, then one should definitely be more specific as to which directories/files can be accessed. Thus, a more secure way of configuring tftp is to restrict the access to just the distribution directory, eg. the tftp line in my case would be:

tftp dgram udp wait guest /usr/etc/tftpd tftpd -s /usr/local/boot /i/cds/6.5inst/dist

or more likely this in order to allow access to the other CD data too:

tftp dgram udp wait guest /usr/etc/tftpd tftpd -s /usr/local/boot /i/cds

If the data is on locally attached CDROM on the server system, then it might look like this:

tftp dgram udp wait guest /usr/etc/tftpd tftpd -s /usr/local/boot /CDROM/dist

Either way, enter the following to restart inetd and so effect the changes:

   /etc/killall -HUP inetd

For more information on the details of configuring inetd, tftpd and bootp, consult the relevant man pages and also read sections 9.4 to 9.6 in the ‘IRIX Admin: System Configuration and Operation’ online book, as well as Chapter 2 in ‘IRIX Admin: Software Installation and Licensing’. Of course, one can always change the services back again once the installation is finished.

Assuming the server is ready, this is the procedure for beginning the installation:

Start the client system, enter the maintenance menu, select the Command Monitor and use setenv to set the client’s IP address. On the Indy, I entered:

   setenv netaddr 192.0.2.5

The first step is to boot into fx to repartition the system disk. Notice there’s no need here to boot first into sash.

   boot -f bootp()192.0.2.10:/i/cds/6.5inst/stand/fx.ARCS --x

Observe the format of the boot command:

   boot -f bootp()server host:boot-path

Use fx in the usual way to repartition the disk (see my main 6.5 page for details). Once done, exit fx (enter ‘/exit’) and wait for the system to go back to the System Maintenance menu. As a quick reminder, a typical use of fx would be:

Press Enter a couple of times to select the default system disk on SCSI controller 0, ID 1, lun 0;
Enter ‘r’ (repartition);
Enter ‘ro’ (root drive option);
Press Enter to confirm XFS;
Enter ‘yes’ to confirm the request, then ‘..’ to move up one menu level;
Enter ‘l’ to create a new disk label;
Enter ‘sy’ to sync the disk (write out the new label);
Enter ‘/exit’ to quit fx and go back to the maintenance menu.

Now press 2 (Install System Software). Click on ‘Remote Directory’, or press 2 again instead which does the same thing. You will see this question:

    Enter the name of the remote host:

Type the IP address of the installation server and press Enter (in my case this was 192.0.2.10). Another question appears:

    Enter the remote directory:

The directory to specify is the equivalent of the dist directory on the installation tools CDROM. This is because the mr (miniroot) file is contained in the dist directory, along with the miniroot subdirectory which contains the various IPxx-specific kernels. In my case, the relevant directory was /i/cds/6.5inst/dist (if the boot server is using data from a local CDROM, then it would be just /CDROM/dist). Once Enter is pressed, the information will change to show ‘remote directory’ as the default installation source, with the details given.

Now press Enter to begin obtaining the installation tools (press it again if confirmation questions are asked). The progress bar one normally sees appears.

When the installation tools are loaded, two further relevant questions are asked, requesting the client’s network address and net mask. If there is an old installation on the disk, the system might use whatever can be found in /etc/sys_id on the disk when deciding on which host name to ask about. If there’s nothing valid on the disk, then it will use the default name IRIS. In my case, there was an old installation which would be overwritten, so it picked up the old name ‘indy’ (from previous tests) and said:

    What is the network address of indy?

I entered 192.0.2.5. The next question was:

    What is the netmask for 192.0.2.5?
    Press Enter for the IP class default [0xffffff00]:

I just pressed Enter, which is the most common action at this point. The system responds with:

    Starting network with hostname: indy, at ip address 192.0.2.5

Now the inst program activates, beginning with a message like this:

    Default distribution to install from: 192.0.2.10:/i/cds/6.5inst/dist

One is now at the normal Inst prompt and the rest of the installation is thus very similar to a normal 6.5 installation, except one must always remember to include the installation server’s IP address followed by a colon at the start of each remote source directory.

First though, one must clear the disk to make sure the file system is clean. If the disk is 4GB or larger, then enter 13 to select the Admin menu, enter 11 to select mkfs, then enter y and confirm the action of making a new file system on the disk. This will use a 4096 block size. Enter ‘..’ to return to the Inst menu.

If the disk is smaller than 4GB, then using the Admin menu to mkfs the disk will result in an inefficient block size being used (it will still work, but 4096 is rather large for a disk as small as 2GB). Thus, instead of using the Admin menu, enter into a shell and do it manually like this:

Enter ‘sh’ at the Inst prompt to go into a shell.
Unmount the system disk from the miniroot file system by entering: umount /root/hw umount /root
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
Now remount the system disk and go back into the Inst program: mount /dev/dsk/dks0d1s0 /root <CTRL+D>

The system disk now has a clean file system, ready for installation. Enter ‘1’ to begin the process. The remote installation tools directory specified earlier should be offered as a default; press Enter to select it – in my case, this was 192.0.2.10:/i/cds/6.5inst/dist. Some information about 6.5 will be shown and then a question about a 6.5 install script; enter ‘2’ to ignore the script. The rest of the data will be read and then the Inst prompt will appear again.

Now enter further remote installation directories as required. The best thing to do in my opinion is to do a base 6.5 install plus the NFS software to get the system up and running, and then use NFS service to install further items from the server. Thus, I entered the following extra directories, which refer to the CDs called, “IRIX 6.5 Foundation 1, June 1998”, “IRIX 6.5 Foundation 2, June 1998”, “IRIX 6.5 Applications, June 1998” and “Network FIle System (NFS) V3, June 1998”. For the NFS CD, I cheated slightly by only copying the contents of the dist/6.5 subdirectory so that only data for 6.5 was present. If you did a straight dump of the NFS CD, then the path would have dist/6.5 on the end aswell.

    /i/cds/6.5F1/dist
    /i/cds/6.5F2/dist
    /i/cds/6.5AppsJun98/dist
    /i/cds/nfs

NOTE: as mentioned earlier, if you are installing onto hardware which requires a later version of 6.5 in order to operate correctly, eg. support for later CPUs, graphics or other option such as a Gbit card, then you should boot using the data from an appropriate update inst tools CD, eg. IRIX 6.5.15 Installation Tools and Overlays 1 of 4, February 2002. If you do this, then you should read in the other relevant update CDs as well as the original foundation and apps CDs.

Having entered all required directories, enter ‘done’ to return to the Inst prompt. Now enter the following to begin the main installation:

    keep *
    install standard
    install prereqs
    go

Normally this will just start the installation straight away. Sometimes though, an error concerning one or more conflicts may be given – these almost always refer to applications such as Netscape. If this happens, it’s usually the first option given in each case that will resolve the conflict, ie. don’t install the offending item. So, just enter ‘conflicts 1a’ (etc.) to deselect the unwanted items and then enter ‘go’ once again to begin the installation.

Handy tip: while the installation is underway, remember that eventually, after the exit commands have completed, the Inst prompt will appear again, at which point one enters ‘quit’ to quit the installation. This starts the rqsall procedure, after which a question appears asking whether one would like to restart the system, to which one normally answers yes by entering ‘y’. However, the system will remember any keyboard presses that are made after the installation has started, so instead of waiting around for these questions to be asked, just enter ‘quit’ and ‘y’ now so that, when the questions appear, the answers will already be in the keyboard buffer and thus accepted immediately. This means you can just leave the installation alone, and come back later to find the system fully rebooted to the login menu. Note that the installation will have created the usual default setup where the host name is IRIS.

Once the installation has finished, login as root, edit /etc/hosts to include relevant entries for the server host and intended client host name (eg. the entries for octane and indy in this example), edit /etc/sys_id to be the new client host name and then reboot. Login once more and then setup NFS to install further items. I make a local /i directory, mount the remote /i on the local /i, run up swmgr and then use product selections files to automatically select all other required items for installation.

Summary: installing across a network sounds daunting and can be a little intimidating if you haven’t done it before, but it’s actually pretty easy and is often more convenient if one has all relevant data copied to disk – no more annoying switching of CDROMs!

Installing Using a Set Engineering 10/100 Option Card in Indy

The above procedure is how to do a network install using the Ethernet port which comes as-standard with a system, but I also did a faster Indy network installation by using a Set Engineering FastEthernet card. Unlike the Phobos 10/100 cards available for Indy, the drivers for the Set Engineering card are already included in the 6.5 base CD. This means that once the installation tools have been read in, the Inst program will ask which Ethernet port one wishes to use as the primary interface. One selects the appropriate gfe port (which I assume stands for GIO Fast Ethernet) and proceeds from there. The steps are very similar to those given above, with just a couple of differences, some extra messages, etc. This is how it works, and should be very similar (or even identical) to installing on, for example, an Octane/Origin/Onyx system which has a Gbit card; remember that it’s likely the 6.5 boot data on the server host would, as mentioned earlier, have to be from an appropriate 6.5 update CD, such as the 6.5.15 inst tools and overlays 1 of 4, in order to provide support for the Gbit card. The PCI Gbit card for Origin/etc. says it needs IRIX 6.5.9 or later.

Begin in the same way as before, booting across the network using the built-in port – 10Mbit in the case of Indy. Note that the following description may not be relevant on some systems since newer PROMs can handle multiple network interfaces, allowing one to a the following slightly different boot format for selecting which interface to boot over, eg. for one interface it might be:

    boot -f network(0)boot -f bootp()192.0.2.10:/CDROM/dist

while for the other interface:

    boot -f network(1)boot -f bootp()192.0.2.10:/CDROM/dist

Thanks to Matthew Finbow <mfinbow@btinternet.com> for this informatin.

Assuming you’re using a system whose PROM does not offer the above method of selecting an alternative interface (this would apply to Indy and Indigo2, for example), then the differences to installing over only the built-in interface begin when the installation tools have been read in. If you have installed the 10/100 card in the left-hand slot in the Indy (the slot nearest the RAM sockets), then this is what you will see, shown inbetween the usual IRIX copyright message and the information concerning the root mount point:

    gfe1: missing
    gfe0: GIO 100BaseTX Fast Ethernet
    xpi0: missing from slot 1
    <etc>

The 10/100 card will be detected as gfe0 if the card has been installed on the left side of the Indy. If it’s installed on right side then it will be detected as gfe1. Since certain video options must use the left slot, it’s probably better to install the 10/100 card in the right slot. In my case, I had to do this because my Indy has a Presenter1280 adapter card installed which must use the left slot (the Presenter1280 card connects to all three expansion sockets in the left slot). Thus, I saw messages showing the 10/100 card as being gfe1:

    gfe1: GIO 100BaseTX Fast Ethernet
    gfe0: missing
    xpi0: missing from slot 0
    <etc>

Thus, my description of this procedure will say gfe1, but remember it may be gfe0 instead if the 10/100 card is in the left hand slot.

At this point, the installation tools asks the all-important question:

    What network interface would you like to configure?
    Press Enter for builtin interface [ec0]:

After switching the network cable to the new 100Mbit port, I entered ‘gfe1’.

Now the questions are as before. The system requests an IP address for the host, and a netmask. I entered 192.0.2.5 and pressed Enter for the default netmask. The system displayed the following (I had blanked the disk this time, so it used the default host name of IRIS):

    Starting network with hostname: IRIS, at ip address 192.0.2.5

NOTE: for reasons unknown – probably just the way the hardware initialises the 10/100 port – it takes a few seconds for the 100Mbit connection to come alive. As a result, a link fail error message often appears, but then the Inst prompt is shown and moments later a further message appears saying the gfe1 link is ok. Thus, don’t worry if you see a message about a link failure; the link will come alive after a short delay.

From here onwards, the procedure is the same. You can confirm that the new link is working correctly by entering ‘sh’ to obtain a shell and then using ifconfig to show the port status (it should say 100Mbit half-duplex, assuming the network hardware supports 100Mbit connections). You can do a bandwidth test by using the ttcp command, eg. I entered this on the Indy while in the shell:

    ttcp -n 10000 -r -s

and this on the Octane:

    ttcp -n 10000 -t -s 192.0.2.5

The results from the Octane showed the bandwidth to be very respectable, in my case about 7MB/sec:

    # ttcp -n 10000 -t -s 192.0.2.5
    ttcp-t: buflen=8192, nbuf=10000, align=16384/0, port=5001  tcp  -> 192.0.2.5
    ttcp-t: socket
    ttcp-t: connect
    ttcp-t: 81920000 bytes in 11.12 real seconds = 7197.23 KB/sec +++
    ttcp-t: 10000 I/O calls, msec/call = 1.14, calls/sec = 899.65
    ttcp-t: 0.0user 0.2sys 0:11real 2% 32maxrss 0+0pf 5034+28csw

That’s more or less it. Once the main installation has finished, and assuming you have installed NFS, just use NFS to install further items across the network, or use installation sources such as the following in Software Manager to install further items (create a file /.rhosts on the server containing the client’s host name in order to allow this to work):

    root@192.0.2.10:/i/cds/6.5inst/dist

Remember to change /etc/config/netif.options so that gfe1 (or whatever is relevant) is used as the primary Ethernet port. Typically, one would change these lines:

    : if1name=
    : if1addr=$HOSTNAME

to this, ie. uncomment and insert appropriate interface name:

    if1name=gfe1
    if1addr=$HOSTNAME

It’s also wise to set if_num to reflect the number of interfaces which will be used. If you don’t want to use the built-in interface at all, then just uncomment the if_num line and set it to 1, ie. change this:

    : if_num=

to this:

    if_num=1

Use the network command to make any changes take effect, ie. enter:

    /etc/init.d/network stop
    /etc/init.d/network start

or just reboot the system.

Feedback on this page is most welcome!

Cheers! 🙂

Ian.

SerenityConnection

Just a little bit of this and that about technology