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:
Inst reports three types of errors: fatal, error, and warning. They are described in this section.
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.
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.
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:
This section discusses three types of errors that can occur when you are loading the miniroot. The following types are discussed:
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:
Check to make sure a caddy with a CD is in the drive.
Press the Reset button on the workstation main unit and begin the installation process again.
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:
Shut down the workstation, verify that the CD-ROM drive is connected and turned on, and start the installation process over again.
If shutting down the workstation does not correct the problem, try turning the CD-ROM drive off and then on again.
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:
Quit Inst.
Return to the PROM Monitor.
Press the Reset button on the workstation.
Begin the installation again.
Refer to the section “Resolving Problems With CDs” if problems persist.
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:
Quit Inst.
Return to the Maintenance menu (see steps 1 through 4 of “The Software Installation Procedure” in Chapter 4).
Start the command monitor from the System Maintenance menu. After your entry, the command monitor prompt (>>) is displayed.
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.
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:
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.
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.
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.
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.
Check Ethernet or other network cables and connections on the local and installation servers.
Check the netaddr variable on the target to make sure that it is set correctly (see Step 3 in “Checking Network Connections”).
If possible, check the network connection to the installation server from a different system on the same network (see “Checking Network Connections”).
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.
If necessary, bring up IRIX on the target system and check the network connection (see “Checking Network Connections”).
Check the distribution directory as described in “Checking Distribution Directories and CDs”.
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, sashcpu, or sash64 portion of the command.
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:
Examine the last command that you entered and look for a spelling or capitalization error. Enter the command again with the correct spelling.
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.
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
The Address column in the output contains hostnames.
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.
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.
 | 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:
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.
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.
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”.
| 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.
The error discussions in this section are grouped as follows:
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.
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> |
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.
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.
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.
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.
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.
This section contains the following subsections:
These errors cause the Error/Interrupt menu to appear automatically (see Figure B-1).
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.
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.
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.
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.
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.
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
|
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.
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:
-
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.
The different types of conflicts discussed here are:
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.
Resolve the conflicts by using the procedures in “Step 6: Resolving Conflicts” in Chapter 4.
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
Choose to ignore conflicts for this installation session. Refer to “Overriding Conflicts”.
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.
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.
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.
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.
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.
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
This section discusses how to check network connections from IRIX and how to diagnose network problems during an Inst session.
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.)
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.)
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):
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.
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
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.
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.
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.
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.
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.
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:
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.
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.
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.
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).
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. |
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, CDdir is the mount point directory for the CD (for example, /CDROM).
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.
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)