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 and instructions are provided to help correct 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 that 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 text describes the possible causes and solutions to the condition that 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”

- “Preinstallation Check Errors”

- “Errors While Installing and Removing Software”

- “Errors 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 From a CD”

#### 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.

- There is no CD in the CD-ROM caddy.

- There is no caddy 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. Afterward, the older PROMs did 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 does not 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 Installations” for a discussion of network problems that may occur during a miniroot installation.

Cannot load network (0) bootp() server:path --could not connect to server

If you see this message, the cause is probably a conflict between the target's IP address setting in the PROM and the address listed in the `hosts` file for the network. To correct this problem, use the following procedure:

1. Quit Inst.

2. Return to the Maintenance menu (see steps 1 through 4 of “The Software Installation Procedure” in Chapter 4).

3. Start the command monitor from the System Maintenance menu. After your entry, the command monitor prompt (>>) is displayed.

4. Enter the `printenv` command to display the PROM setting for `netaddr`.

   Find the value of the `netaddr (`network address) variable in the `printenv` output. If this value is different from the IP address that you obtained in “Getting the Target's Name and Address” in Chapter 2, it must be reset.

5. Reset the netddr variable to the value that you obtained from the `ping` command. Use this command to set the new PROM IP address:

       >> setenv netaddr ping_IPaddress

No server for server:path(sashARCS)

Unable to load bootp()server:path(sashARCS):file not found

or

No server for server:CDdir/dist(sashARCS)

open(bootp)server:CDdir/dist(sashARCS) failed, errno = 6

Unable to load bootp()server:CDdir/dist(sashARCS):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>(sashARCS): ''bootp()server:path/sa(sashARCS)'' is not a valid file to boot.

or

TFTP error: Access violation (code 2)

bootp()server:path/sa(sashARCS): invalid

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

or

bootp()server:path/sa(sashARCS): invalid

Unable to load bootp()server:path/sa(sashARCS): ''bootp()server:path/sa(sashARCS)'' 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 `/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” in Chapter 2.

  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” in Chapter 2.

  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 in “Checking Network Connections”).

  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(sashARCS): 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 `sashARCS`, `sash` cpu, or `sash64` 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 that you entered and look for a spelling or capitalization error. 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/(sashARCS) 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 From a CD

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)sashARCS: file not found

or

open(bootp()server:CDdir/dist/sa(sashARCS)) failed, errno=2

Unable to load bootp()server:CDdir/dist/sa(sashARCS): 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.

#### Questionable Miniroot Image: IRIX 6.3 and Earlier

| Note: The following error message occurs only during installations of IRIX 6.3 or earlier. If you are installing IRIX 6.4 or later, refer to “Questionable Miniroot Image: IRIX 6.4”.

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 occurs on personal workstation (such as O2 and Indy systems) when you try to load the miniroot after a power failure or if a system restart is performed during the installation. If you attempted a system restart instead of loading the miniroot after the interruption occurred, you were automatically placed in the version of Inst that is part of the previously installed miniroot.

Take one of the following actions to correct the condition:

1. Enter c if you want to install software with the currently loaded miniroot. Entering c and quitting Inst fixes the boot information. You can then restart the system after Inst is loaded without using the `fx` utility.

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 are running IRIX 6.2 or earlier and you want to use the `fx` command. Also use this selection on IRIX 6.3 systems if you want to abort the installation and restart the system.

   | Note: If you are running IRIX 6.2 or earlier and want to use fx to correct boot information and boot from the root partition, refer to the procedure documented in “Using fx to Restore the Swap Partition”.

#### Questionable Miniroot Image: IRIX 6.4

| Note: The following error messages occur only during installations of IRIX 6.4 or later. If the target is running IRIX 6.3 or earlier and you see a similar error, refer to “Questionable Miniroot Image: IRIX 6.3 and Earlier”.

It appears that a miniroot install failed. 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.

You may abort the installation and return to the menu, or you can

fix (reset to normal) the miniroot install state.

See the `Software Installation Guide' chapter on Troubleshooting for

more information.

Enter `c' to continue booting the old miniroot with no state fixup.

Enter `f' to fix miniroot install state, and try again.

Enter `r' to reload the miniroot.

Enter `a' to abort (cancel) the installation.

Enter your selection and press ENTER (c, f, r, or a)

This error is posted when you try to reboot the miniroot after a power failure or a system reset interrupted the miniroot load process, risking the integrity of the miniroot.

You can safely choose c if you were using the miniroot normally when the interruption occurred or if you unintentionally exited the miniroot. Do not use c if the interruption occurred while the miniroot copy was in progess and the process did not conclude with a posting of the `Inst>` prompt. In this case, assume that the miniroot image is compromised and select either f to fix, r to reload the miniroot, or a to abort the installation. The f selection is also appropriate if you deliberately reset the system while using the miniroot and you want the system to boot normally.

The r selection performs the entire miniroot load process from the beginning, removing any effects of the previous load attempt. If you need to preserve the load state to demonstrate the error condition to others (such as your support organization), chose a to abort the installation. Unlike f or r, the a choice makes no changes in the system state; it simply returns control to the PROM monitor.

It appears that a miniroot install failed. Either the system is

misconfigured or a previous installation failed.

You may continue booting without fixing the state.

You may abort the installation and return to the menu, or you can

fix (reset to normal) the miniroot install state.

See the `Software Installation Guide' chapter on Troubleshooting for

more information.

Enter `c' to continue with no state fixup.

Enter `f' to fix miniroot install state, and try again.

Enter `a' to abort and return to menu.

Enter your selection and press ENTER (c, f, or a)

This error is posted if you perform a system reset after a power failure or a previous system reset interrupted the miniroot load process, risking the integrity of the miniroot.

You can safely choose c if you were using the miniroot normally when the interruption occurred or if you unintentionally exited the miniroot. Do not use c if the interruption occurred while the miniroot copy was in progess and the process did not conclude with a posting of the `Inst>` prompt. In this case, choose f to fix the miniroot image or a to abort the copy and return to the Inst menu.

### Errors While Starting an Installation Session

The error discussions in this section are grouped as follows:

- “Wrong Diskless Modes”

- “Errors Starting Live Installations”

- “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 (nondiskless) 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 Installations

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” in Chapter 4.

#### 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.base` 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 that 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”.

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 nonexistent 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 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.

### Preinstallation Check Errors

When you enter the `go` command, Inst executes the preinstallation 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 by removing files (in these examples on the `/` and `/usr` filesystems), or select fewer subsystems for installation.

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 the installation and, in some cases, it must maintain the files until you reboot the computer.

If you are performing a live installation, there might be enough available disk space for all the new software but not enough additional temporary disk space to complete the installation. In this situation, try closing some applications and then entering the `go` command again. If there is still not enough space, you may have to run the installation in the miniroot.

You can save the selections that you have already made by creating a selections file; when you finish removing software, load the file to reapply your selections. Use this sequence of commands during either a live or a miniroot installation:

Inst> `admin save` filename
Inst> `keep *`
Inst> `remove` subsystem subsystem ...
Inst> `admin load` filename

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 that 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 reference pages. Use the `keep` command to deselect those products.

### Errors While Installing and Removing Software

This section contains the following subsections:

- “Disk Space Errors”

- “Subcommand and Exitop Errors”

- “Network Time-out 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 preinstallation 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 does not 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 reinstall these products (select `go` at the main menu to restart 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 performing a live 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. Because it is in use, you must notify the daemon. Use these commands:

      # rm /var/adm/SYSLOG
      # killall -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 performing a 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, 2,000 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 filesystems 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 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 will not 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 to 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 Time-out 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 reinvoke 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 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 by 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” in Chapter 4 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:

- “Preexisting Conflicts”

- “Required Product Conflict”

- “Prerequisite Conflict”

- “Back Prerequisite Conflict”

- “Incompatible Products Conflict”

- “Downgrade Conflict”

#### Preexisting Conflicts

Unresolved product dependencies and incompatible installed products may already exists on the target before the current Inst session. These conflicts are known as preexisting 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” in Chapter 4.

2. Choose to ignore preexisting 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 installation. 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 missing. 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” in Chapter 4 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 remove all the products that depend on it.

#### 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. Install only 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, you can override the conflicts and continue with the installation by setting the rulesoverride preference. Overriding conflicts leaves a preexisting conflict on the target, which can be seen if the show_existing_conflicts preference is set to true. This action is recommended only for extreme cases and for knowledgable users because it can introduce unfulfilled product dependencies or install incompatible products on the system.

| Note: Resolve all conflicts possible before using the rulesoverride feature.

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

Inst> set rulesoverride false

## 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 is not returned, you have specified the wrong server, there is a network problem, or user is not a valid user ID. (See “Configuring an Installation Account” in Chapter 2 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 performing a 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 nonvolatile random-access memory (NVRAM) does not 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 does not 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” in Chapter 2 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” in Chapter 2 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 slow (usually indicating network problems), Inst may appear to be frozen for long periods (much greater than the time-out 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 time-outs or retries, is 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 will 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 installation or cancel the install and try again later.

On a slow network, changing the network time-out (by setting the preference “timeout” to the new time-out 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 hostname was mistyped, that there is 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 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 that there is something wrong with the file `/etc/services` or the services map on the NIS server.

#### Network Problem Diagnosis During Miniroot Installations

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/6.`3.

Chances are that the file does exist and that this is probably a network problem—trying to `bootp` through too many gateways. Because 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 multihomed 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 step 3 of “Checking Network Connections” for more information).

-- 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 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 are booting from the command monitor, be sure to specify the `sa` file, not just the distribution directory containing the `sa` file.

-- No remote connection

This is probably an internal error resulting from trying to access a remote connection that 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 is 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 is 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 must be done separately on the remote server. 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.

## 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 does not 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 the `distcp`(1M) reference page) 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 the `distcp`(1M) reference page).

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 corrects the condition described in “Questionable Miniroot Image: IRIX 6.3 and Earlier”, in which you receive the error message `root and swap are on the same partition`. Use this procedure on systems running IRIX 6.2 or earlier IRIX versions. The procedure modifies the boot information to cause the system to boot from partition 0 (the root partition) instead of partition 1 (the swap partition) where the miniroot currently resides. (This discussion assumes that you are using the 4D1-4.0 or later version of `fx`.)

| 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 complete information on using `fx`.

1. Enter the command monitor.

   Follow steps 1 through 4 of “Loading From a Local CD” in Chapter 3 to display the System Maintenance menu, then select `Enter Command Monitor`.

   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 this command:

         >> 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” in Chapter 2).

   - To invoke `fx` from a CD with installation tools mounted on an installation server named server, enter this command:

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

     In the previous command, CDdi r is the mount point directory for the CD (for example, `/CDROM`).

2. Run `fx` to restore the boot file to the root partition. The sample session below shows the `fx` defaults for system disk device name, controller number, and drive number. Unless your system configuration is not standard, the `fx` defaults are 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 IP22, 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

SGI 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 SGI supported products, contact the Technical Assistance Center at 1-800-800-4SGI. If you are outside these areas, contact the SGI 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 ins tallation (model numbers, the size of your system disk, and so on)

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