Appendix B. Troubleshooting Installations
Prev |  | Next

## Appendix B. Troubleshooting Installations

This appendix presents information and procedures that you can use to troubleshoot problems that you might encounter during installation.

The appendix begins with a description of the types of error messages that Inst produces, and then describes how to set Inst preferences to control the amount of feedback Inst provides. Most of the rest of the appendix discusses specific errors, arranged in groups according to how and when they are generated. Information or instructions are provided to help in correcting the error condition. A section at the end describes how to contact technical support and what information to have ready.

This appendix contains the following sections:

- “Types of Errors”

- “Resolving Errors”

- “Resolving Conflicts”

- “Resolving Network Problems”

- “Resolving Problems With CDs”

- “Checking Distribution Directories and CDs”

- “Using fx to Restore the Swap Partition”

- “Calling Your Support Organization”

## Types of Errors

Inst reports three types of errors: fatal, error, and warning. They are described in this section.

### Fatal

A fatal message occurs if Inst encounters a severe, unrecoverable error. An example of a fatal error is:

FATAL: mmap of /dev/zero for 4000 pages failed

Inst exits immediately after encountering a fatal error. Fatal errors can be caused by hardware failures or lack of sufficient operating system resources, such as swap space. If a fatal error occurs, you might need to load the miniroot and take corrective action by modifying system configuration files.

### Error

An error message indicates that a command or other function was unable to complete successfully. For example:

Inst> `from /irix5.3` ERROR : The distribution /irix5.3 does not exist.

You may want to retry the operation after taking corrective measures.

### Warning

A warning indicates an unusual condition that Inst is prepared to handle, but which may cause problems later during the installation. For example:

% `inst` WARNING : Starting up as Read Only (no installs or removals)

Inst will start, but in read-only mode.

## Resolving Errors

This section discusses Inst error messages in detail. Error messages, possible reasons for the error, and possible solutions are provided. Errors are grouped according to how they are generated.

Error messages are shown in a typewriter-style font and are followed by indented explanatory text. For example:

Example of an error message

This is text describing the possible causes and solutions to the condition which produced the error.

Variables within the text of the error message (for example, hostnames) are shown in italics.

This section contains the following subsections:

- “Errors Loading the Miniroot”

- “Errors While Starting an Installation Session”

- “Pre-Installation Check Errors”

- “Errors While Installing and Removing Software”

- “Errors On Leaving an Installation Session (RQS Errors)”

### Errors Loading the Miniroot

This section discusses three types of errors that can occur when you are loading the miniroot. The following types are discussed:

- “Errors Loading the Miniroot From Local CD”

- “Errors Loading the Miniroot From Remote Host”

- “Other Errors Loading the Miniroot”

#### Errors Loading the Miniroot From Local CD

`dk<unit> error: unrecognized scsi disk drive` `dksc(0,<unit>,8)sash.<cpu>: Command not found`

If you see one of these errors while you are using a local CD during a miniroot installation, possible causes are

- The `dksc` command was not typed correctly: --m was entered instead of -m.

- No CD is in the CD-ROM caddy.

- No caddy is in the CD-ROM drive (for drives that use a caddy).

- The CD-ROM drive is not ready.

- A workstation with older PROMs that do not recognize CD-ROM drives is being used. An `fx`, `ide` (diagnostics), or `sash` was started and exited normally. Afterwards, the older PROMs do not recognize the CD-ROM drive.

- A previous installation was terminated abnormally.

  Perform the following actions to correct the error:

1. Check to make sure a caddy with a CD is in the drive.

2. Press the `Reset` button on the workstation main unit and begin the installation process again.

3. Follow the procedure in “Verifying That a CD-ROM Drive Is Recognized”.

CD-ROM drive not recognized

If you see this error while using local CD-ROM during an IRIX Installation, a possible cause is that IRIX doesn't recognize that the CD-ROM drive is present.

Perform these actions to correct the problem:

1. Shut down the workstation, verify that the CD-ROM drive is connected and turned on, and start the installation process over again.

2. If shutting down the workstation does not correct the problem, try turning the CD-ROM drive off and then on again.

3. See the section “Resolving Problems With CDs”.

dks0d3s8: Unexpected blank media: ASC=0x64 dks0d3s8: Can't read volume header Error 20 while loading scsi(0)cdrom(3)partition(8)sashARCS

If you see these errors while using a CD distribution source during a miniroot installation, it is possible that the program `cdman`(1) was terminated, which left the CD-ROM drive in audio mode rather than in data mode.

To correct this problem, use the following procedure:

1. Quit Inst.

2. Return to the PROM Monitor.

3. Press the Reset button on the workstation.

4. Begin the installation again.

5. Refer to the section “Resolving Problems With CDs”,” if problems persist.

#### Errors Loading the Miniroot From Remote Host

In addition to the errors discussed in this section, refer to “Network Problem Diagnosis During Miniroot Installation” for a discussion of network problems that may occur during a miniroot installation.

No server for server:path(sash.cpu) Unable to load bootp()server:path(sash.cpu):file not found

or

No server for server:CDdir/dist(sash.cpu) open(bootp)server:CDdir/dist(sash.cpu) failed, errno = 6 Unable to load bootp()server:CDdir/dist(sash.cpu):file not found

``If you see either of these errors during a miniroot installation, the cause might be an incorrect specification of the remote distribution source. To correct the error, enter the `setenv` command again. Specify the full, correct path to the distribution source, and be sure to include the `/sa` at the end of your specification. Then, enter the `boot` command again.

TFTP error: I/O error (code 0) Unable to load bootp()server:path>(sash.cpu): ''bootp()server:path/sa(sash.cpu)'' is not a valid file to boot.

or

TFTP error: Access violation (code 2) bootp()server:path/sa(sash.cpu): invalid Unable to load bootp()server:path/sa(sash.cpu): ''bootp()server:path/sa(sash.cpu)'' is not a valid file to boot.

or

bootp()server:path/sa(sash.cpu): invalid Unable to load bootp()server:path/sa(sash.cpu): ''bootp()server:path/sa(sash.cpu)'' is not a valid file to boot.

If you see any of these errors after specifying a remote distribution during a miniroot installation, the problem might be one of the following:

- You have incorrectly specified server, path, or cpu.

- There is no physical connection between your workstation and the installation server.

- The `inetd.conf` file on the installation server has not been modified to allow `tftp`(1C) access to the CD-ROM mount point directory or distribution directory.

- Routers between your workstation and the installation servers have not had `bootp`(1M) forwarding enabled (located in `/usr/etc/inetd.conf` on IRIX systems).

- A remote distribution directory is corrupted.

- You are trying to use a software distribution that does not include installation tools (the `sa` file).

  To correct the problem, take one or more of these actions:

1. Check server (the installation server name), path (the distribution directory), and cpu (the CPU number) to make sure that you have spelled them correctly and that they exist.

2. Try to load the miniroot using the instructions in Chapter 3; you may see additional error messages that help you determine the cause of the problem.

3. Check the `inetd.conf` file on the installation server. The line containing `tftp` should be modified and `inetd` should be restarted, as explained in “Setting Up an Installation Server”.

4. Check the `inetd.conf` file on each router between the target and installation server systems to verify that it has been modified, as explained in “Setting Up an Installation Server”.

5. Check Ethernet or other network cables and connections on the local and installation servers.

6. Check the netaddr variable on the target to make sure that it is set correctly (see Step 3 on page 180).

7. If possible, check the network connection to the installation server from a different system on the same network (see “Checking Network Connections”).

8. If the target system is a router (has multiple network connections) you might need to change its network connections so that the “normal” network device is connected to the same network as the installation server. Booting the miniroot is not supported over FDDI.

9. If necessary, bring up IRIX on the target system and check the network connection (see “Checking Network Connections”).

10. Check the distribution directory as described in “Checking Distribution Directories and CDs”.

11. Perform any additional procedures that are necessary to identify the problem. See the section “Resolving Network Problems”.

file file not found in server:path/sa; directory contains: ... Unable to load bootp()...

or

File CDdir/dist/sa not found on server server Unable to load bootp()server:CDdir/dist/sa(sash.cpu): no such file or directory

If you see either of these errors during a miniroot installation, possible causes are

- The boot command contains a typing error in the `sash`.cpu, `sash`cpu, or `sashARCS` portion of the command.

- The remote installation server name (server) was mistyped.

- The netaddr variable is not set correctly to your IP address (IPaddress).

- bootp(1M) is not running on the installation server.

  Perform the following checks to debug this error:

1. Examine the last command you entered and look for a spelling or capitalization error, the wrong CPU in the `sash`.cpu portion of the command,`sash.IP12` rather than `sashIP12`, `sash.IP17` rather than `sashIP17`, or any `sash` command with `IP19`, `IP20`, or `IP22` rather than `sashARCS`. Enter the command again with the correct spelling.

2. Check`/var/adm/SYSLOG` on the installation server to see whether it contains `bootp` messages. If `SYSLOG` contains `bootp` messages, `bootp` is running. The likely cause of the problem is that `netaddr` is set incorrectly on the target system.

3. If the installation server has multiple network interfaces, try specifying the hostname for each interface alternately. This sometimes resolves routing problems. To display the hostname for each interface, enter this command:

       % /usr/etc/netstat -i

4. The `Address` column in the output contains hostnames.

5. Perform additional checks, as described in “Resolving Network Problems”.``

Installation tools not found at server:CDdir/dist

or

Installation tools not found at server:path

If you see either of these errors during a miniroot installation from a remote distribution source, the CD or distribution directory that you specified might not contain installation tools. To correct this problem, confirm that the distribution source contains the installation tools (the `sa` file).

bootp()server:path/sa/(sash.cpu) is not in a.out format

If you see this error message after you initiate miniroot loading, it may have one of the following causes:

- There are network problems or network traffic is too heavy to perform the installation.

- You specified an incorrect distribution directory name.

- The file `sa` in the distribution is damaged.

  To resolve this problem, check the network using the procedures in “Resolving Network Problems”, or try again later.

#### Other Errors Loading the Miniroot

Unable to load dksc(cntlr,unit,8)sashcpu: file not found

or

dksc(cntlr,unit,8)sashcpu: invalid Unable to load dksc(cntlr,unit,8)sash.cpu: file not found

or

open(bootp()server:CDdir/dist/sa(sash.cpu)) failed, errno=2 Unable to load bootp()server:CDdir/dist/sa(sash.cpu): file not found

If you see any of these errors during miniroot installation from CD, it may be that you are trying to load the miniroot from a CD that does not contain installation tools.

Switch to a CD that includes installation tools to load the miniroot, then switch back to your original CD.

root and swap are on the same partition. Either the system is misconfigured or a previous installation failed. If you think the miniroot is still valid, you may continue booting using the current miniroot image. If you are unsure about the current state of the miniroot, you can reload a new miniroot image. Finally, you may abort the installation and return to the PROM; in this case you will need to use the `fx' program to correct the disk label information. See the `Software Installation Guide' chapter on Troubleshooting for more information.

Enter `c' to continue booting the currently loaded miniroot. Enter `r' to reload the miniroot. Enter `a' to abort the installation. Enter your selection and press ENTER (c, r, or a)

This error message occurs only with the Indy workstation. If you are not using an Indy workstation but see a similar error, refer to the discussion of the next error. This error (or the next one) occurs when you try to load the miniroot after a power failure or if system restart has occurred during an installation. If you had attempted a system restart instead of loading the miniroot, you would have automatically been placed in the version of Inst that is in the previously-installed miniroot.

Take one of the following corrective actions:

1. Enter c if you want to install software with the currently loaded miniroot.

2. Enter r if you want to reload the miniroot. You might want to do this if, for example, the current version of the miniroot is corrupt, or if you want to load another version of the miniroot.

3. Enter a to abort the installation and to go back to the command monitor. You can do this, for example, if you want to use the `fx` command to correct boot information and boot from the root partition, or if you want to abort the installation and restart the system.

| Note: Entering c and quitting Inst fixes the boot information. You can then restart the system after Inst is loaded without using the `fx` command. If you are familiar with fx and want to use it, refer to the procedure documented in “Using fx to Restore the Swap Partition”.

root and swap are on the same partition. This is most likely because a previous installation was in progress. If so, you may continue the boot into the miniroot. Otherwise the partition info needs to be corrected. Do you wish to continue booting (y or n)

This is the version of the previous error message for systems previous to the Indy. If you see this error after you entered the command to copy the miniroot to the swap partition, it may be that the power failed or the system was reset during installation, and the miniroot is still in the swap partition.

First decide whether you need to return to Inst to complete your installation, or are ready to restart your system. If you need to return to Inst, answer y to the question. The Inst Main Menu should appear, and you can finish your installation. To restart your system and cause it to boot normally from the root partition, enter n and you will be returned to the PROM Monitor where you can choose to start the system.

### Errors While Starting an Installation Session

The error discussions in this section are grouped as follows:

- “Wrong Diskless Modes”

- “Errors Starting Live Installation”

- “Inst Library libinst.so Errors”

- “Errors in the Distribution”

In general, check what Inst is using as the default distribution. You may have to use the `from` command to point it at the desired distribution.

#### Wrong Diskless Modes

ERROR : Unable to start inst: The target appears to be a diskless client tree, since the file /root/var/inst/.client is present. Restart in client- mode using client_inst (1M). If you are certain that you want to run in non-diskless mode, remove the client file /root/var/inst/.client and restart inst.

FATAl ERROR : Unable to start inst: The target appears to be a share tree for diskless client, since the file /var/inst/.share is present. Restart in share-mode using share_inst(1m). If you are certain that you want to run in non-diskless mode, remove the file /var/inst/.share and restart inst.

These messages mean that Inst believes that the target is a diskless client tree, because in a previous installation Inst was invoked in “diskless” mode reserved for the diskless installation tools `share_inst` and `client_inst` (see the share_inst(1M) and client_inst(1M) reference pages).

If the target has been previously created as a diskless tree, then continuing with a normal (non-diskless) installation would severely corrupt the installed software. You should only attempt diskless installations using `share_inst` and `client_inst` (see the share_inst(1M) and client_inst(1M) reference pages).

However, if you are certain that the target is not used for diskless installations, remove the files `/var/inst/.share` and `/var/inst/.client` (or, if in the miniroot, `/root/var/inst/.share` and `/root/var/inst/.client`). Then restart Inst.

If you are performing a miniroot installation, Inst will exit abnormally and prompt you to restart the system (`y`), enter Inst (`n`), or start a shell (`sh`). Choose `sh`:

    Ready to restart the system? (y, n, sh) sh
    # rm /root/var/inst/.share
    # rm /root/var/inst/.client
    # exit

(You use only the `/root` prefix to the path for miniroot installations.) Then return to Inst:

    Ready to restart the system? (y, n, sh) n
    ...
    Inst>

#### Errors Starting Live Installation

These errors occur when starting Inst from IRIX.

Sorry! The system is not set up for non-miniroot installations of all the selected subsystems, since the configuration file /var/inst/inst_special is missing. Try the installation again from the miniroot.

You may not perform a live installation of some subsystems (labeled with b by the `list` command) without the `inst_special` configuration file present. If you are unable to obtain this file from another system, you must perform the installation from the miniroot.

Another inst is currently running

You may not have two copies of Inst running in read/write mode to the same target simultaneously. The second session is run in read-only mode.

Inst determines this by looking for a file called `$rbase/var/inst/inst.lock`. ($rbase is the root directory for the current software installation.) In rare cases, it may be necessary to remove this file by hand.

A previous installation session was not completed successfully.

This error means a previous version of Inst was interrupted or killed before it completed all the actions requested by the user. Information on the state of the last session has been saved in the file `$rbase/var/inst/.checkpoint`. For more information on recovering from the checkpoint file, see “If Inst Is Interrupted”.

#### Inst Library libinst.so Errors

The Inst products`—inst`, `swmgr`, `showfiles` and `showprods`—all link with the `libinst.so` dynamic object. If, when starting one of these programs, an rld error appears regarding `libinst.so`, it is probable that you have an incompatibility between the binary and `libinst.so`. In this situation, it is best to reinstall `eoe.sw.unix` from the miniroot to get the latest versions of these products.

26379:inst: rld: Fatal Error: cannot map soname 'libinst.so' using any of the filenames /usr/lib/libinst.so:/lib/libinst.so:/lib/cmplrs/cc/libinst.so:/usr/lib/cmplrs/cc/libinst.so: -- either the file does not exist or the file is not mappable (with reason indicated in previous msg)

This error message means the `libinst.so` file is missing.

852:swmgr: rld: Error: unresolvable symbol in swmgr: post__15VkDialogManagerFPCcPFP10_WidgetRecPvT2_vN22PvT1P14VkSimpleWindow

This error message indicates that the `libinst.so` file is present but not the right version.

#### Errors in the Distribution

ERROR : No such host: host

This error can appear after executing a command that requires access to a distribution through the network.

The most likely cause is a bad hostname. Check the hostname and use the `from` command to set the correct distribution location.

If the hostname appears correct and there was a delay before the error message appeared, it is possible that your system is experiencing network problems. See the section “Resolving Network Problems” for information on resolving this problem.

ERROR : The distribution dist:/pathname does not exist.

This error occurs when a command attempts to reference the distribution, but the distribution path references a non-existent directory or a product file. For example:

    Inst> from dist:/sgi/baddir
    Connecting to dist ...
    ERROR : The distribution dist:/sgi/baddir does not exist.
    Inst> from dist:/sgi/hacks/badprod
    Connecting to dist ...
    ERROR : The distribution dist:/sgi/hacks/badprod does not exist.
    Inst> from /host/dist/sgi/baddir
    ERROR : The distribution /host/dist/sgi/baddir does not exist.

Determine the correct pathname and use the `from` command to set the correct distribution location.

ERROR : The product `host`:/`path`/sc is bad.

This error occurs if the distribution specified references a file that is not a valid product file. For example:

    Inst> from /usr/tmp/file
    ERROR : The product /usr/tmp/file is bad.

Note that when referencing an individual product, the product file must be used. In the following error, the product was incorrectly specified using the `idb` file:

    Inst> from dist:/sgi/hacks/sc.idb
    Connecting to dist ...
    ERROR : The product dist:/sgi/hacks/sc.idb is bad.

The product `sc` should be specified as follows:

    Inst> from dist:/sgi/hacks/sc
    Connecting to dist ...

ERROR : The distribution host:/path does not contain any products.

This error results when the distribution directory specified does not contain any product files. You must specify the correct distribution directory.

Missing products in listing

If a product `prod` appears in a distribution directory along with its `idb` file (prod`.idb`) and image files (`prod`.image ...), but does not appear in the product listing in Inst, then the product files may be corrupt.

Use `ls` to make sure that the product files are in the distribution directory. Make certain that you are viewing all of the products in the distribution by executing the following commands:

    Inst> view dist
    Current Location : distribution
    Inst> view filter all
    Inst> list

If the product is still not visible, the product was not read in and the product files are probably corrupt. See the section “Checking Distribution Directories and CDs” for more information.

### Pre-Installation Check Errors

When you enter the `go` command, Inst executes the pre-installation check before installing any files. If any errors are detected during this check, Inst lists the problems and returns to the main menu without installing or removing software.

Not enough space on / for the new unix kernel Not enough space on /usr for requickstart overhead (see rqs(1)) Not enough space on /usr for the installation overhead Not enough space on / (additional 85kbytes required)

These errors mean that you need to make more disk space available (in these examples on the `/` and `/usr` filesystems), or select fewer subsystems for installation.

| Note: A live installation usually requires extra temporary disk space. Because some of the files to be upgraded are currently in use, either by the operating system or by running applications, Inst must maintain multiple copies of these files during a live installation and, in some cases, until you reboot the computer.

If you are running a live installation, you may encounter a situation where there is enough available disk space for all the new software, but not enough additional temporary disk space to accomplish the installation. In this situation, try closing some applications, and then giving the “go” command again. If there is still not enough space, you may have to run the installation in the miniroot.

The installation request will install or remove files in the following nfs-mounted filesystems: /filesystem

Please cancel or confirm the request. 1. Cancel the installation request 2. Continue the installation request Please enter a choice [1]:

Inst issues these warnings to protect against accidental installation of files into NFS mounted directories. Normally software installations are made on the local host. If you really want to install across an NFS mount, choose 2, otherwise cancel the installation (1), return to the Main Menu, and use the `keep` command to install fewer subsystems.

| Note: To disable this confirmation, set the preference confirm_nfs_installs to off.

ERROR: Subsystems cannot be installed/removed because they contain files on read-only NFS-mounted filesystems. You may de-select these subsystems for install/remove; or, if you wish to install these subsystems locally, you must first unmount these filesystems, or remove any symbolic links pointing into them (check the pathnames of the Files listed below); or, if you wish to install these subsystems onto the remote filesystems, you must unmount them and then re-mount them as read-write.

Filesystem: /usr/share NFS-mounted, read-only

      Subsystem          File
      insight.sw.data    /usr/share/Insight/lib/addBooklist
      vino.man.pages     /usr/share/catman/a_man/cat7/vino.z

Installations and removals canceled

ERROR: Subsystems cannot be installed/removed because they contain files in write-protected directories. You may de-select these subsystems for install/remove; or, if you wish to continue with the current selections, you must first change the directory permissions using the chmod(1M) command.

      Subsystem           File
      ViewKit_dev.sw.demo /usr/share/src/lib/ViewKit/Utilities/list.c++
      dwb.sw.dwb          /usr/share/lib/tmac/tmac.e

Installations and removals canceled

Any of these messages mean that you lack the appropriate permission to install all the files in the selected products.

This is usually an indication that you are using NFS to share filesystems on a remote host, and some of the subsystems selected for installation install files into those remote filesystems.

Check your selections to make sure you are not installing or removing “shared” software, such as online books or manual pages. Use the `keep` command to de-select those products.

### Errors While Installing and Removing Software

This section contains the following subsections:

- “Disk Space Errors”

- “subcommand and Exitop Errors”

- “Network Timeout Errors”

- “Archive Corrupt Errors”

- “Device Busy Errors”

These errors cause the Error/Interrupt menu to appear automatically (see Figure B-1).

Figure B-1. The Interrupt Menu

If the pre-installation check completes without errors, Inst begins installing and removing files. If an error occurs after this point, Inst stops and presents the interrupt menu. First try to correct the cause of the error, and then choose retry from the interrupt menu.

If this doesn't work, or you are unable to correct the problem, you can choose stop to cancel the installation immediately and return to the main menu.

If you `stop` the installation, the current image in progress (such as `eoe.sw`) will be in an inconsistent state (partially installed/removed). The installation history will not have been updated for these subsystems (`eoe.sw.*`). You are strongly advised to either re-install these products (just select `Go` at the main menu to re-start the installation from the beginning of the partial image) or, for products not marked “required,” remove them completely.

#### Disk Space Errors

Despite efforts to accurately predict the required disk space, Inst may occasionally fail during the installation with an error such as this:

ERROR : An error occurred while Installing new versions of selected product subsystems Write of pathname failed: No space left on device

This produces the Error/Interrupt menu (see above). Use the `shroot` command to enter the shell. Remove or compress unnecessary large files, exit the shell, and retry the operation. If you are unable to locate any expendable files, stop the installation and choose fewer subsystems for installation.

The sequence that follows illustrates how to resolve the previous error by removing and compressing files:

    Interrupt> shroot
    # df
    Filesystem  Type  blocks     use  avail %use Mounted on
    /dev/root    efs 1939714 1939702     12 100% /
    # ls -l /usr/tmp/core.*
    -rw------ 1 guest guest 20971520 Oct 20 01:00 /usr/tmp/core.0
    -rw------ 1 guest guest 0        Oct 20 01:00 /usr/tmp/core.1
    -rw------ 1 guest guest 3145728  Oct 20 01:01 /usr/tmp/core.3
    # rm /usr/tmp/core.0 /usr/tmp/core.1
    # compress /usr/tmp/core.3
    # df
    Filesystem Type   blocks     use avail  %use Mounted on
    /dev/root   efs  1939714 1892566 47148  98%  /
    # exit
    Interrupt> retry
    Installing new versions of selected pv.man subsystems
    Installing new versions of selected pv.sw subsystems

If there is still not enough disk space, consider the possibility that you may not need some large files on your workstation. The list below gives filenames relative to root, but remember that if you are doing a miniroot installation, `/root` must be prepended to each of the filenames if you escape to the shell with `sh`. If you escape to the shell with `shroot` or are using IRIX Installation, use the filenames as given. Look for these large files:

- Kernel core dump files in `/var/adm/crash/vmcore*` and `/var/adm/crash/unix*`.

- Files put into `/lost+found` and `/usr/lost+found` by `fsck`(1M).

- If you have process accounting enabled, the directories `fiscal`, `nite`, and `sum` in `/var/adm/acct` may contain large files.

- `/var/adm/SYSLOG`. If this file is very large, you might want to truncate or remove it. Since it is in use, you must notify the daemon. Use these commands:

  # `rm /var/adm/SYSLOG
  ` # k`illall -HUP syslogd`

- Unnecessary files in `/tmp` and `/usr/tmp`. Note that `/usr/tmp/inst.a*` files are temporary files created by `inst` and should not be removed.

- Core files. You can find all core files in the root and user filesystems with these commands if you are using Miniroot Installation:

  Admin> `shroot
  ` # `/bin/find / /usr -mount -name core -print`

- Large user files that can be temporarily archived to tape. One way to find large files is to use the `sysadm`(1) command if it is installed (`sysadm` is not included in Release 5.0 and later):

  % `/bin/su -
  ` Password:
  # `/usr/bin/sysadm filesize`

Running subcommand `filesize' from menu `filemgmt', FILE MANAGEMENT

Enter full pathname of the directory to search [?, q]: `/usr/people/joe`

Enter the number of large files to be included in list (default 10 largest) [q]: `10`

The largest 10 files in /usr/people/joe:
(report)

You can also use the `find` command to find files that are larger than, for example, 2000 blocks (1 MB):

# `find / -local -size +2000 -print`

- If your site uses NFS, you may be able to NFS mount reference pages installed on another workstation rather than installing them on your workstation when disk space is scarce.

- Replacing your system disk with a larger disk is sometimes an option when you need more disk space in order to install the software you want. NFS mounting remote file systems is also an option when you need more disk space, because Inst installs software onto NFS mounted filesystems if those filesystems are exported read-write from the remote host, and if your permissions (usually those of the superuser) allow write-access to the necessary directories on that host.

#### subcommand and Exitop Errors

As part of the installation procedure, Inst executes subcommands. These are UNIX shell commands that perform special initialization functions specific to each product. For example, some products use subcommands to install a custom icon in the system Icon Catalog. Some subcommands, called exit-commands, or exitops, run at the end of the installation, and sometimes originate from more than one subsystem.

Stderr: Cannot create pathname: No such file or directory ERROR : An error occurred while Installing new versions of selected product subsystems Command “command”

If a subcommand fails during the installation of a specific product, an interrupt menu is also presented. The subcommands that run at the end of the installation, during the “Exit-Commands” phase, may affect multiple subsystems. Inst displays any errors from these “exitops” but does not present the interrupt menu.

If an interrupt menu is presented, try to gauge from the error message the cause and severity of the problem. The error could indicate that the affected product won't function completely or correctly, or that the system might fail to boot. Decide whether to ignore the error and continue, to fix the problem and retry, or stop and return to the Inst main menu.

Consult the release notes of any affected product for further information. For example, the release notes may specify a particular order in which the software subsystems must be installed in order to function properly.

#### Network Timeout Errors

Connecting to host ... host.domain: Interrupted system call Host host is not responding, retrying host.domain: Interrupted system call Host host is not responding, retrying host.domain: Interrupted system call ERROR : Timed-out waiting for host

Inst presents the Error/Interrupt menu. See the section “Resolving Network Problems” to determine the cause of the network failure. You may need to continue the installation at a later time, depending on the availability of that host.

If the network is merely slow, or the server is heavily loaded, use the `set` command to raise the value of the timeout and/or network_retry preferences.

#### Archive Corrupt Errors

File filename not in compressed format Compressed input file is corrupt (internal overflow) Unexpected EOF Can't open archive: archive Archive archive is in an unrecognized format Archive archive is corrupt

Inst is unable to properly extract files from the software distribution, which is compressed in a special format. If you are installing over a network, check the system logs for signs of network errors (see “Resolving Network Problems”).

If you are performing a live installation, you may need to use a newer version of the installation tools; when the distribution format is upgraded, older versions of Inst cannot always read more recent software distributions (new versions of Inst can read older distributions formats, however). Use Inst from the miniroot, preferably the miniroot that accompanies the software upgrade you are trying to install.

#### Device Busy Errors

filesystem: Device Busy

There may be a file open in the named filesystem if you get this error. Quit Inst and then re-invoke it to force it to close the open file.

For example, if you were trying to unmount all filesystems from Inst Admin:

    Admin> umount -a
    </root/usr: Device Busy error messages>
    Admin> return
    Inst> quit
    Ready to restart the system. Restart? { (y)es. (n)o, (sh)ell, (h)elp } n
    Inst> admin
    Admin> umount -a

### Errors On Leaving an Installation Session (RQS Errors)

An error has occurred while requickstarting your system. No loss of functionality occurred.

A requickstart failure simply indicates that some files were not requickstarted. The net effect is that the startup time of the failed binary will be slightly slower than had it been successfully requickstarted. The error message will also provide the name of a log file where there is a detailed explanation of the RQS error(s). See `rqs`(1) for a detailed explanation of requickstart.

Sproc of /usr/etc/rqsread failed

Sproc of /usr/etc/rqsall failed

/usr/etc/rqsread terminated abnormally

/usr/etc/rqsall terminated abnormally

These messages indicate that you probably need to upgrade your system to get newer versions of these files.

/usr/etc/rqsread terminated abnormally due to signal #

/usr/etc/rqsall terminated abnormally due to signal #

These messages indicate that the named process was killed due to a signal. The relevant signal number will be provided so it will be possible to determine the cause of the termination.

## Resolving Conflicts

Installation conflicts occur when there are unsatisfied product dependencies or when incompatible product are selected for installation. If Inst detects conflicts when the user enters the `go` command, the conflicts must be resolved before the installation is carried out. See “Step 6: Resolving Conflicts and Other Errors” for more information on the procedures used to resolve conflicts.

The error you see when a conflict has been detected is:

    Inst> go
    ERROR : Conflicts must be resolved.
    (conflict description and options)

This section is divided into the following subsections:

- “Resolving Different Types of Conflicts”

- “Overriding Conflicts”

| Note: The 10-digit number that appears in the conflict message is the product's version number. You can use the `showprods -n` command to display product version numbers.

### Resolving Different Types of Conflicts

The different types of conflicts discussed here are:

- “Pre-Existing Conflicts”

- “Required Product Conflict”

- “Prerequisite Conflict”

- “Back Prerequisite Conflict”

- “Incompatible Products Conflict”

- “Downgrade Conflict”

#### Pre-Existing Conflicts

Unresolved product dependencies and incompatible installed products may already exists on the target before the current Inst session. These conflicts are known as pre-existing conflicts. For example, the following conflict shows an installed product that depends on another product that is not installed.

- Existing Conflict - swmgr.sw.eoe is installed but is missing prerequisites: 1a. Also remove swmgr.sw.eoe (1021391900) 1b. Install eoe.sw.unix (1010852020 - 2147483647)

Normally, these conflicts are not visible. If they are, you have three options.

1. Resolve the conflicts by using the procedures in “Step 6: Resolving Conflicts and Other Errors”.

2. Choose to ignore pre-existing conflicts by setting the resource show_existing_conflicts to false, and marking something for removal or installation to force a recalculation of the installation rules. Because show_existing_conflicts is a permanent resource, this ignores pre-existing conflicts for future installations as well.

        Inst> set show_existing_conflicts false
        Inst> remove prod1
        Inst> go

3. Choose to ignore conflicts for this installation session. Refer to “Overriding Conflicts”.

#### Required Product Conflict

Required product conflicts occur when a required subsystem is not marked for installation or when a required subsystem is marked for removal.

subsystem is required and must be installed 1a. Also install subsystem (xxxxxxxxxx)

This type of conflict occurs when the distribution contains a required subsystem that is not installed and not marked for install. In this case, the only solution is to install the required subsystem.

subsystem is required and may not be removed - sorry! 1a. Do not remove subsystem (xxxxxxxxxx)

This type of conflict occurs if you mark a required subsystem for removal. In this case, the only solution is to retain the required subsystem.

#### Prerequisite Conflict

This type of conflict occurs when a product is marked for installation and it requires a product that is not already installed or marked for installation.

product cannot be installed because of missing prerequisites: 1a. Do not install product (xxxxxxxxxx) 1b. Install product (xxxxxxxxxx - xxxxxxxxxx)

To resolve the above conflict, you have two options. The first is to not install the product whose requirements are not met. The second is to install the required products. In the above example, the required product is not on the current distribution. You must locate a distribution that contains the required product and install it before continuing with this installation. See “Step 2: Specifying the Source” for further instructions.

#### Back Prerequisite Conflict

This type of conflict occurs when a product is selected for removal, but other products depend on it.

product cannot be removed because other products depend on it. 2a. Do not remove product (xxxxxxxxxx) 2b. Also remove product1 (xxxxxxxxxx) product2 (xxxxxxxxxx)

There are two options for resolving this type of conflict. You can choose not to remove the product, or choose to remove all of the products that depend on it also.

#### Incompatible Products Conflict

This type of conflict occurs when a product is marked for installation and is incompatible with another product that is marked for installation, or with one that is already installed.

product (xxxxxxxxxx) is incompatible with product1 (xxxxxxxxxx) 2a. Do not install product (xxxxxxxxxx) 2b. Do not install product1 (xxxxxxxxxx)

This conflict is the result of selecting two incompatible products for installation. You must not install one.

product (xxxxxxxxxx) is incompatible with product1 (xxxxxxxxxx) 2a. Do not install product (xxxxxxxxxx) 2b. Also remove product1 (xxxxxxxxxx)

This conflict is the result of marking a product for installation that is incompatible with a product that is already installed on the target. To resolve this type of conflict, choose one of the two incompatible products to be on the target.

#### Downgrade Conflict

This type of conflict occurs when a product that is marked for installation is an older version of a product that is already installed.

You have marked product.old (xxxxxxxxxx), which is an older version of product.new (xxxxxxxxxx) 1a. Replace product.new (xxxxxxxxxx) with product.old (xxxxxxxxxx) 1b. Do not install product.old (xxxxxxxxxx) 1c. Set resource neweroverride to value true

The first option replaces the newer, installed version of the product with an older one. The second option retains the newer version of the product on the target. The last sets the resource neweroverride, which allows the installation of older products for newer ones without conflict. Unless there is a valid reason, the newer product should be retained on the target.

### Overriding Conflicts

If installation conflicts cannot be resolved but the installation must be done, the user can override the conflicts and continue with the installation by setting the rulesoverride preference. Overriding conflicts leaves a pre-existing conflict on the target, which can be seen if the show_existing_conflicts preference is set to true.

This procedure is recommended only for extreme cases and for knowledgable users, since it can introduce unfulfilled product dependencies or install incompatible products onto the system.

In the following example, a conflict is “resolved” by setting rulesoverride to true:

product1 cannot be installed because of missing prerequisites: 1a. Do not install product1 (xxxxxxxxxx) 1b. Install product0 (xxxxxxxxxx - xxxxxxxxxx) (not on current distribution)

Inst> set rulesoverride true Inst> go

## Resolving Network Problems

This section discusses how to check network connections from IRIX, and how to diagnose network problems during an Inst session.

### Checking Network Connections

The steps below explain several tests and checks that you can perform from IRIX to verify that your workstation is connected to an installation server. (Note that if you are in Inst, you can access IRIX with the `sh` command.)

1. Test the connection for Inst user access:

       % /usr/bsd/rsh server -l user date

   In the previous command, server is the name of the installation server and user is the user ID you are using for installation. Normally, user is “guest.” If the date isn't returned, you've specified the wrong server, there is a network problem, or user isn't a valid user ID. (See “Configuring an Installation Account” for more information about user.)

2. Test the TCP/IP connection:

   Connections to installation servers are done over Terminal Control Protocol/Internet Protocol (TCP/IP) in a manner similar to `rsh` (see the rsh(1C) reference page). A simple test of this connection can be done by using `ping` (see the ping(1M) reference page:

       % /usr/etc/ping -q -f -s 2048 -c 100 server
       PING <server> (<IPaddress>): 2048 data bytes
       ----<server> PING Statistics----
       100 packets transmitted, 100 packets received, 0% packet loss
       round-trip (ms)  min/avg/max = 0/2/7
       %

   In the previous example, server is the name of the installation server. If you see packet loss, you could have a problem with your network connection. If you receive a message that the host is unknown, verify the name of the host you are trying to contact and be sure you are typing it correctly.

   This network connection test is not possible if you are using Miniroot Installation; if you are, test the connection before beginning the installation, if possible.

3. Check the setting of the netaddr NVRAM variable.

   In some situations, you might have network problems if the IP address of your workstation in its non-volatile random access memory (NVRAM) doesn't match its IP address in `/etc/hosts`. A mismatch can occur when you move a workstation, but it does not cause a problem until you attempt to load the miniroot for a software installation. You can check the IP address in the NVRAM on your workstation while you are using IRIX by giving this command:

       % /etc/nvram netaddr

   From the Command Monitor, you can check the IP address in the NVRAM with this command:

       >> printenv netaddr

   If the four-part number returned from either command doesn't match the IP address in `/etc/hosts` on your workstation, you may be able to change it from IRIX (not all models of workstations support changing NVRAM from IRIX):

       # /etc/nvram netaddr localIPaddress

   Or change it from the Command Monitor:

       >> setenv netaddr localIPaddress

4. Verify that the installation server allows `tftpd` access (required for miniroot installation only).

   “Enabling TFTP Access on an Installation Server” describes the procedure for verifying that the installation server has been modified to allow `tftp` access (see the tftpd(1M) reference page).

   To get more debugging information, add the –l argument to the `tftp` line in `/etc/inetd.conf` and restart `inetd` (see the inetd(1M) reference page). The line should look like this:

       tftp  dgram udp   wait guest /usr/etc/tftpd  tftpd   -l

   Debugging information is written to `/var/adm/SYSLOG`.

5. Verify that routers between your workstation and the installation server forward `bootp` packets (see the bootp(1M) reference page).

   “Enabling BOOTP Forwarding on Routers” describes the procedure for verifying that routers have been modified to allow `bootp` access.

   To get more debugging information, add the –d argument to the `bootp` line in /`etc/inetd.conf` and restart `inetd` (see the inetd(1M) reference page). The line should look like this:

       bootp  dgram  udp  wait root  /usr/etc/bootp bootp -f -d

   Debugging information is written to `/var/adm/SYSLOG`.

For more information on networking, see the IRIX Admin: Networking and Mail and the NFS Administration Guide.

#### Network Problem Diagnosis During an Inst Session

If the network is very slow (usually indicating network problems), Inst may appear to be frozen for long periods (much greater than the timeout time); in reality it may be reading a few bytes at a time, timing out, retrying, then reading a few more bytes. This sort of behavior, as well as any error messages regarding network timeouts or retries, are an indication that it may be desirable to investigate the condition of the network.

Here are some of the common error messages that might occur during a remote installation session:

-- Host `host' is not responding, retrying

The remote host did not respond in a reasonable amount of time; we'll retry a few times before giving up. See the preference “network_retry” for a discussion of how to control the number of retries Inst makes before it gives up.

-- Timed-out waiting for `host'

The remote host has timed out several times in a row. A serious network problem probably needs to be resolved before we can continue. Either resolve the network problem and continue the install, or cancel the install and try again later.

On a very slow network, changing the network timeout (by setting the preference “timeout” to the new timeout in seconds) may be necessary, though in general this is not recommended and will probably not cure a real network problem, but will only increase the length of time before such a problem is reported to the user.

-- Can't set up network connection to host host: reason

You were unable to establish an initial network connection to the remote host for the reason given. See “Checking Network Connections” for a discussion of what to do to test the network.

-- Lost connection to host

The network connection was broken. This probably means that the remote host is down.

-- No such host: host

The host is not listed in the host table. This could mean that the host's name was mistyped, that there's something wrong with the `/etc/hosts` file, or that the NIS or DNS server is down.

-- Couldn't parse ls output from remote host: `ls_output'

Running an `ls` command on the installation server succeeded, but gave output different from what was expected. The only immediate solution is to install a different `ls` program (for example, a POSIX® compatible `ls` program) on the installation server.

-- Failed reading remote directory dir: error_msg

It was not possible to perform an `ls` command on the installation server. The given error string should give some clue as to the reason. Likely reasons:

- Illegal option: The installation server has an `ls` command that takes a different set of arguments from the ones the local `ls` command takes. The only immediate solution is to install a different `ls` program (for example, a POSIX-compatible `ls` program) on the installation server.

- Cannot access ... No such file or directory: The remote directory does not exist

- Cannot access ... Permission denied: The given user does not have sufficient permissions to access the directory.

-- Can't get shell/tcp network port to host host: error_msg

The service “exec” or “shell” was not found on the system. This probably means there's something wrong with the file `/etc/services` or the services map on the NIS server.

#### Network Problem Diagnosis During Miniroot Installation

These messages come from the boot PROM rather than Inst.

-- unable to load bootp()machine:/path/sa(sash.IPXX) -- bootp()machine:/path/sa(sash.IPXX) is not a valid file to boot

To find out if the file exists, enter the following command on the installation server:

    # mkboottape -f /pathname/sa -l |grep sash

In the previous example, pathname is the distribution directory; for example, `sa` may be in `dist:/irix/5.`3.

Chances are the file does exist and this is probably a network problem—trying to `bootp` through too many gateways. Since the `bootp` protocol is not as robust as it could be, it is sometimes unable to find a file on a server if network traffic is heavy. By installing from an NFS mounted file system on a local network, NFS is dealing with the gateways and `bootp` is only going across the local network.

This can also occur when the server is a multi-homed machine.

-- no server for machine:/path/sa(sash.IPXX)

-- unable to load bootp()machine:/path/sa(sash.IPXX): file not found

This could mean that the netaddr variable is set incorrectly. From the command monitor, enter a `printenv netaddr` command and see if the address returned is set to an address on the local subnet (see “Preliminary PROM Monitor Procedure” for information on the netaddr variable).

-- Error 7 while loading network(0)bootp()mach1:/path/sa(sashARCS)

-- UX:csh: ERROR: ./.swindow - Command not found

The previous message might appear when loading from an automounted distribution (for example, `machine:/hosts/`...)

These errors indicate that you need to modify `/etc/inetd.conf` (`/usr/etc/inetd.conf` on pre-5.x systems) on the installation server (mach1 in this example) and remove the “-s /usr/local/boot /usr/etc/boot” from the `tftpd` entry (or alternatively, add the desired pathname to the end of the list of accessible paths after -s). Then restart `inetd`:

    # /etc/killall -HUP inetd

-- panic free'ing mbuf while loading miniroot

This is a problem in the IP12 prom and in the IP20 prom.

Check your Ethernet cable—make sure that it is connected tightly to your machine. If you still see this problem, you can try to load the miniroot from a local machine via an NFS mount. This problem rarely occurs, and only when there is high network traffic.

-- Cannot load network(0)bootp()machine:/path

-- Problem reading file magic id, err 0 cnt0

This can mean network problems, such as a bad router between the current machine and the installation server.

-- Unable to load bootp()machine:/path: `'bootp()machine:/path'' is not a valid file to boot

You are trying to boot from a file that is not a valid `sa` image.

If you're booting from the command monitor, be sure to specify the `sa` file and not just the distribution directory containing the `sa` file.

-- File sash.XXX not found in machine:/path/sa, directory contains (listing)

You specified an unknown or unsupported machine type XXX when selecting the `sash` from which to boot. See “About Miniroot Installations” for more information.

-- No remote connection

This is probably an internal error resulting from trying to access a remote connection which used to be open but is now closed.

-- Unable to locate your password information (user-id UID)

Your current user ID is not a valid account on the system. This unlikely error probably means there's something wrong with the host table (`/etc/hosts`) or with the NIS server.

-- Can't open network connection: no hostname!

No remote hostname was given. You must supply the name of the network host.

## Resolving Problems With CDs

### Checking CD-ROM Drives

To check CD-ROM drives, you must verify that the system recognizes the drive and that the CD you want to use is mounted. These procedures are described in the following sections.

### Verifying That a CD-ROM Drive Is Recognized

The procedure to verify that a CD-ROM drive is recognized depends on your situation:

- If IRIX is running, enter the `hinv` command:

      % hinv

  For each CD-ROM drive, you should see one line of output. For example:

      CDROM: unit 4 on SCSI controller 0

  If you do not see a line of output for a CD-ROM drive, it is not recognized.

- If you are in the miniroot, escape to a shell with the `shroot` command and enter the `hinv` command:

      # hinv

  For each CD-ROM drive, you should see one line of output. For example:

      CDROM: unit 4 on SCSI controller 0

  If you do not see a line of output for a CD-ROM drive, it is not recognized.

- If you are in the Command Monitor, enter the `hinv` command:

      >> hinv

  For each CD-ROM drive, you should see one line of output. Some examples:

      SCSI CDROM: dksc(0,4)
      SCSI CDROM: scsi(0)cdrom(4)
      SCSI Disk: dksc(0,4)

  These examples show the CD-ROM drive on an older workstation. The CD-ROM drive is recognized, but it is shown as a disk. If you do not see a line of output for a CD-ROM drive, it is not recognized.

When a CD-ROM drive is not recognized, it usually because the CD-ROM drive was not powered up properly. If it is an external drive, the CD-ROM drive must be powered on before the workstation main unit is powered on.

The procedure for making the system recognize the CD-ROM drive depends on whether you are running IRIX or the miniroot:

1. If you are running IRIX, exit Inst if it is running, warn other users, shut the workstation down with `shutdown` (see the shutdown(1M) reference page) or use System Shutdown on the System menu, then reboot the workstation to bring up IRIX again.

2. If you are in the miniroot, get back to the PROM Monitor, press the Reset button on the workstation main unit, and then bring up Inst again. If this does not fix the problem, turn the CD-ROM drive off and then on again.

### Verifying That a CD Is Mounted

When using a CD-ROM drive, the CD that contains the software you want to install must be mounted. Mounting is done automatically by Inst when using a local CD-ROM. The user executing Inst must have root privileges in order for it to be able to mount the CD. When using a remote CD-ROM, the mounting is done by the command `cdinstmgr` (see the cdinstmgr(1) reference page). To verify that the CD is mounted, use the `df` command, below (see the df(1) reference page). If you are using a local CD-ROM, escape to a shell. If you are using a remote CD-ROM, enter the command on the installation server.

For example:

    % /bin/df
    Filesystem       Type  blocks     use  avail %use Mounted on
    /dev/root         efs 1939714 1749520 190194  90% /
    /dev/dsk/dks0d4s7 efs  828672  817805  10867  99% /CDROM

Look at the directory name on the right. For a local CD-ROM, you should see `/CDROM`. For a remote CD-ROM, the name `/CDROM` is likely, but another directory name for the mount point (called CDdir in this document) may have been chosen.

If the CD is mounted, list the files it contains to verify that you have the correct CD inserted. If the CD is not mounted and you are using an installation server, verify that `cdinstmgr` is running (see the cdinstmgr(1) reference page).

## Checking Distribution Directories and CDs

To verify that a distribution directory or a mounted CD contains the right files, the workstation that contains the distribution must be running IRIX. Change directories to the distribution directory (`distdir` or`CDdir/dist`) and list the files with `ls`. Files in software distributions have these names:

    mr
    sa
    product
    product.idb
    product.images

The file `sa` is used for miniroot installations only, so it doesn't need to be present if you are doing an IRIX installation. The file `mr` may or may not be present; there is no problem if it is missing. More than one product file, `product`, may be in the directory. Each product requires a file called `product`.idb (installation database) and one or more product.image files. Examples of product files are `eoe` and `maint_nfs`. Common values of images are `man` and `sw`.

If a distribution does not have the correct files, the most likely causes are that the distribution directory was not copied correctly, or that the files in the distribution directory were modified after it was created. Use `distcp -c` to compare the original with the copy (see distcp(1M)) and, if there is a discrepancy, copy the original distribution again.

Copy the distribution directory using `cp -r` (or `rcp -r` for a remote copy) and then use `distcp -c` to compare the original with the copy (see distcp(1M)).

If you suspect that the contents of the files in the distribution directory have been corrupted, try installing from the CD that was used to create the distribution directory.

An additional check is possible for CDs: change directories to `CDdir` and list the files with `ls`. One file and at least two directories should be listed:

    RELEASE.info
    dist
    relnotes

`RELEASE.info` is an ASCII text file that contains release information. `dist` contains the product files, and `relnotes` contains the release notes, which describe the exact contents of each CD. Use `relnotes` to read the release notes (see the relnotes(1) reference page).

## Using fx to Restore the Swap Partition

The following procedure is an example of a use of the `fx` command. The procedure shown corrects the condition described in “Other Errors Loading the Miniroot”, in which you receive the error message `root and swap are on the same partition`. In this procedure, the boot information is modified to cause you to boot from partition 0 (the root partition) instead of partition 1 (the swap partition) where the miniroot currently resides. (This discussion assumes that the 4D1-4.0 or later version of `fx` is used.)

| Caution: The `fx` command is intended for advanced users and should not be used unless you have a definite need for it. Refer to the fx(1) reference page for for complete information on using `fx`.

1. Enter the command monitor (see “Preliminary PROM Monitor Procedure” for details on how to enter the command monitor on your system).

2. Invoke `fx` from the standalone version on your workstation, or from a local or remote CD-ROM. See the `fx`(1M) reference page for complete instructions on invoking `fx`, or use the following procedure.

   - To invoke the standalone copy of fx on your workstation, enter

         >> boot stand/fx --x

   - To invoke `fx` from a CD with installation tools in a CD-ROM drive on your workstation, enter the appropriate command.

     If your CPU type (cpu) is IP4, IP5, or IP6, the command is

         >> boot -f dksc(cntlr,unit,8)sash.cpu dksc(cntlr,unit,7)stand/fx.cpu --x

     If your CPU type is IP7 or IP9, the command is

         >> boot -f dksc(cntlr,unit,8)sash.cpu dksc(cntlr,unit,7)stand/fx.IP5 --x

     If your CPU type is IP12 or IP17, the command is

         >> boot -f dksc(cntlr,unit,8)sashcpu dksc(cntlr,unit,7)stand/fx.cpu --x

     If your CPU type is IP19, IP20, or IP22, the command is

         >> boot -f dksc(cntlr,unit,8)sashARCS dksc(cntlr,unit,7)stand/fx.ARCS --x

     In the previous command, cntlr and unit are the controller and unit numbers of the CD-ROM drive (see “Getting CD-ROM Device Numbers”).

   - To invoke `fx` from a CD with installation tools that is mounted on an installation server named server, enter the appropriate command.

     If your CPU is IP4, IP5, IP6, IP12, or IP17, the command is

         >> boot -f bootp()server:CDdir/stand/fx.cpu --x

     If your CPU type is IP7 or IP9, the command is

         >> boot -f bootp()server:CDdir/stand/fx.IP5 --x

     If your CPU type is IP19, IP20, or IP22, the command is

         >> boot -f bootp()server:CDdir/stand/fx.ARCS --x

     In the previous command, CDdir is the mount point directory for the CD (for example, `/CDROM`) and cpu is the CPU type of your workstation.

3. After `fx` is invoked, messages, prompts, and menus appear. A sample session is shown below. In this sample session, the default system disk device name, controller number, and drive number chosen by `fx` (dksc, 0, and 1 respectively) are used. Unless your workstation is configured in a non-standard way, the defaults chosen by `fx` will be correct and you can respond with `<Enter>` to the prompts.

       Obtaining /stand/fx from server server
       n+n+m entry: p
       fx version 4.0 IP6, Aug 23, 1991
       fx "device-name" = (dksc) <Enter>
       fx: ctlr# = (0) <Enter>
       fx: drive# = (1) <Enter>
       ...opening dksc(0,1,)
       ...controller test...OK
       Scsi drive type == CDC      94171-9         0184
       ----- please choose one (? for help, .. to quit this
                                                     menu)-----
       [exi]t      [d]ebug/      [l]abel/      [a]uto
       [b]adblock/    [exe]rcise/   [r]epartition/      [f]ormat
       fx> label/create/boot

At this point the System Maintenance menu appears, and you can restart your system or restart the installation.

## Calling Your Support Organization

Silicon Graphics, Inc., provides a comprehensive product support maintenance program for its products.

If you are in the United States or Canada and would like support for your Silicon Graphics supported products, contact the Technical Assistance Center at 1-800-800-4SGI. If you are outside these areas, contact the Silicon Graphics subsidiary or authorized distributor in your country.

If you have read the troubleshooting information in this chapter and still need help, have this information available when you call your support organization:

- the serial number of your workstation (required)

- the products that you are trying to install and their release numbers (see the CD label)

- the release numbers of software products that are currently installed (use `showprods,` described in the showprods(1M) reference page)

- the type of software distribution you are using (local or remote CD-ROM, or distribution directory)

- the text of any error messages you have seen

- the hardware configurations of your workstation and any installation server used for installation (model numbers, the size of your system disk, and so on)

Prev | Table of Contents | Next
Appendix A. Inst Quick Reference |  | Index