test

Solaris Common Messages and Troubleshooting Guide

"P"

Package not installed

Cause

This error occurs when users attempt to use a system call from a package which has not been installed.

Technical Notes

The symbolic name for this error is ENOPKG, errno=65.

panic -boot: Could not mount filesystem

Cause

The primary problem is that jumpstart gives the following error: 


2ec00 RPC: Can't decode result.
whoami RPC call failed with rpc status: 2
panic - boot: Could not mount filesystem.
program terminated
ok
Normally this is a result of the bootparams not being able to get to the install image.

The second problem is that other users have had the same error message, with the additional message: 


'Timeout waiting for ARP/RARP packet...'

Action

To solve the first problem:

1. Check how the dfstab(4) (/etc/dfs/dfstab on the install image NFS server) looks: 


share -F nfs -o ro,anon=o /jumpstart-dir

2. Run share(1M) command on the installed image NFS server, to make sure it is shared properly.

3. Check /etc/bootparams file on the net install server. Look for entries with incorrect boot path.

4. Make sure that /usr/sbin/rpc.bootparamd is running on the boot server. If necessary, kill and restart it.

5. Check /etc/ethers on the boot server for duplicate or conflicting entries

6. At OK prompt, run test net /test-net and/or watch net /watch-net to test the network connectivity

A workaround for the second problem is to check the nsswitch.conf(4) file. If some of the entries point to NIS such as: 


rpc		nis	files
hosts		nis	files
ethers		nis	files
bootparams	files   nis
change all of these entries to files first: 

rpc		files 	nis
hosts		files 	nis
ethers		files	nis
bootparams	files	nis
Note - You may have to manually update these files if they do not contain info on the client machine you are trying to jumpstart.

Then remove the client with rm_install_client(1M), remove the contents of tftpboot, and re-add the client: 


add_install_client -c /jumpstart-dir/profiles  'client name'  'arch'

panic: mutex_adaptive_exit

Cause

CD-ROM boot gets error:panic: mutex_adaptive_exit Documented above under message "panic_mutex". Same SRDB ID.

Panic

Cause

A system panics and crashes when a program exercises an operating system bug. Although the crash might seem unfriendly to a user, the sudden stop actually safeguards the system and its data from further corruption.

Along with bringing the operating system to a stop, the panic routine copies the memory contents in use to a dump device, recording critical information about the current state of the CPU from which the panic routine was called.

Because the primary swap device is usually the default dump device, the primary swap device should be large enough to hold a complete image of memory. The system tries to reboot after the memory image is saved.

If the system does not reboot successfully, consider these possibilities:

1. Catastrophic hardware failure, such as faulty memory or a crashed disk;

2. Major kernel configuration faults, such as a buggy device driver;

3. Major kernel tuning errors, such as a too-large value for maxusers;

4. Data corruption, including corruption of the operating system files;

5. Manual intervention is needed, as when fsck(1M) expects answers to its queries.

Action

To find out why a system crashed, you can

1. Look in the /var/adm/message* log files;

Action

Of these methods, using savecore(1M) is the most informative. The savecore(1M) command transfers the system crash dump image generated by the panic routine from the dump device to a file system. The image can then be analyzed with a debugger such as adb(1).

See Also

Correctly setting up savecore(1M) and interpreting its results can be difficult. For more information about debugging system panics, refer to Panic! UNIX System Crash Dump Analysis by Chris Drake and Kimberley Brown (ISBN 0-13-149386-8).

PARTIALLY ALLOCATED INODE I=int CLEAR?

Cause

During phase 1, fsck(1M) found that the specified inode was neither allocated nor unallocated. The reason is probably that the system crashed in the middle of a sync(2) or write(2) operation.

Action

Should you answer yes to this question, "UNALLOCATED" messages might result during phase 2, if any directory entries point to this inode. If you are being careful, exit fsck(1M) and run ncheck(1M) (specifying the inode number after the -i option) to determine which file or directory is involved here. You might be able restore this file or directory from another system. It is also possible that fsck(1M) will copy this file to the lost+found directory in a later phase.

See Also

For more information, see the chapter on checking filesystem integrity in the System Administration Guide, Volume I.

passwd: Changing password for string

Cause

If you put the following lines into /etc/nsswitch.conf 

 passwd:     compat
passwd_compat:     nis
Then when you run passwd, it fails as follows: 

server1% passwd
passwd:  Changing password for khh
server1%
NOTE: passwd exits before you get the opportunity to enter a password.

Action

If you read the man page for passwd very carefully, you will see the following:

If all requirements are met, by default, the passwd command will consult /etc/nsswitch.conf to determine in which repositories to perform password update. It searches the passwd(4) and passwd_compat entries. The sources (repositories) associated with these entries will be updated. However, the password update configurations supported are limited to the following 5 cases. Failure to comply with the configurations will prevent users from logging onto the system. 

   o passwd: files
   o passwd: files nis
   o passwd: files nisplus
   o passwd: compat (==> files nis)
   o passwd: compat (==> files nisplus)
      passwd_compat: nisplus

NOTE: It does *not* say that you can use the line: passwd_compat: nis. If you conform exactly to what's written in the man page, then passwd(1) works.

passwd.org_dir: NIS+ servers unreachable

Cause

This is the first of three messages that an NIS+ client prints when it cannot locate an NIS+ server on the network.

Action

See the message "hosts.org_dir: NIS+ servers unreachable" for details.

Password does not decrypt secret key for unix.uid@string

Cause

This message appears at login time when a user's password is not identical to the user's keylogin(1) network password. When a system is running NIS+, the login program first performs UNIX authentication, and then attempts a keylogin(1) for secure RPC authentication.

Action

To gain credentials for secure RPC, users can run keylogin(1) (after login) and type in their secret key. To stop this message from appearing at login time, users can run the chkey -p command and set their network password to be the same as their NIS+ password. If a user doesn't remember the network password, the system administrator should delete and re-create the user's credentials table entry so the user can establish a new network password with chkey(1).

Permission denied

Cause

An attempt was made to access a file in a way forbidden by the protection system.

Action

Check the ownership and protection mode of the file (with a long listing from the ls -l command) to see who is allowed to access the file. Then change the file or directory permissions as needed.

Technical Notes

The symbolic name for this error is EACCES, errno=13.

Please specify a recipient.

Cause

With mailtool(1), this message comes up in a dialog box whenever a user tries to deliver a message with no address in the To: field.

Action

See the message "Recipient names must be specified" for details.

Protocol error

Cause

Some protocol error occurred. This error is device specific, but is generally not related to a hardware failure.

Technical Notes

The symbolic name for this error is EPROTO, errno=71.

protocol error, string closed connection

Cause

rlogin(1) fails on SunOS machine.

Action

1. Check the permissions on in.rlogind on the machine you are trying to connect to. The permissions should look like this: 


-rwxr-xr-x  1 root     staff       16384 Jan 20  1994 /usr/etc/in.rlogind

2. Check the login line in the /etc/inetd.conf file. It should look like the following: 


login	stream	tcp	nowait	root	/usr/etc/in.rlogind	in.rlogind

3. Check /etc/passwd to see if an invalid login shell has been substituted in the entry for the login id.

Protocol family not supported

Cause

The protocol family has not been configured into the system or no implementation for it exists. Used for the Internet protocols.

Technical Notes

The symbolic name for this error is EPFNOSUPPORT, errno=123.

Protocol not supported

Cause

The requested networking protocol has not been configured into the system, or no implementation for it exists. (A protocol is a formal description of the messages to be exchanged and the rules to be followed when systems exchange information.)

Action

Verify that the protocol is in the /etc/inet/protocols file and in the NIS protocols map, if applicable. If the protocol is not listed, and you want to permit its use, configure the protocol as documented or as required.

Technical Notes

The symbolic name for this error is EPROTONOSUPPORT, errno=120.

Protocol wrong type for socket

Cause

This message indicates either an application programming error, or badly configured protocols.

Action

Make sure that the /etc/protocols file corresponds number-for-number with the NIS protocols(4) map. It it does, ask the vendor or author of the application for an update.

Technical Notes

A protocol was specified that does not support the semantics of the socket type requested. This amounts to a request for an unsupported type of socket. Look at the source code that made this socket request and check that it requested one of the types specified in /usr/include/sys/socket.h.

The symbolic name for this error is EPROTOTYPE, errno=98.