This error occurs when a user attempts to use a system call from a package that has not been installed.
The symbolic name for this error is ENOPKG, errno=65.
This error occurs after a vxvm upgrade. In this case, the user had the drivers (vxio and vxspec) for the Solaris 2.5.1 software and not for the Solaris 2.6 software. This condition was verified by using ls -l /kernel/drv/*vx*.
Execute a pkgrm or re-install VXVM 2.4 and re-encapsulate the root.
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.
In addition to stopping the operating system, 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:
Catastrophic hardware failure, such as faulty memory or a crashed disk
Major kernel configuration faults, such as an unstable device driver
Major kernel-tuning errors, such as a too-large value for MAXUSERS
Data corruption, including corruption of the operating system files
Manual intervention needed, as when fsck(1M) expects answers to its queries
To find out why a system crashed, you can look in the /var/adm/message* log files.
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).
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).
The first problem comes from the following jumpstart error:
2ec00 RPC: Can't decode result. whoami RPC call failed with rpc status: 2 panic - boot: Could not mount filesystem. program terminated ok |
Additionally, other users have the same error message, with an additional message:
'Timeout waiting for ARP/RARP packet...' |
To solve the first problem:
Check how the dfstab(4) (/etc/dfs/dfstab on the install image NFS server) looks:
share -F nfs -o ro,anon=o /jumpstart-dir |
Run share(1M) command on the installed image NFS server, to make sure it is shared properly.
Check /etc/bootparams file on the net install server. Look for entries with incorrect boot path.
Make sure that /usr/sbin/rpc.bootparamd is running on the boot server. If necessary, kill and restart it.
Check /etc/ethers on the boot server for duplicate or conflicting entries.
At the prompt, run test net /test-net and/or watch net /watch-net to test the network connectivity.
As a workaround for the second problem, 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 |
rpc files nis hosts files nis ethers files nis bootparams files nis |
You might have to update these files manually if they do not contain information on the client machine you are trying to jumpstart.
Then, remove the client with rm_install_client(1M), remove the contents of tftpboot, and again add the client:
add_install_client -c /jumpstart-dir/profiles 'client name' 'arch' |
The machine is an SS20 with 256 Mbytes of RAM, an FDDI interface, and a single CPU. It is running Online Disksuite for mirroring and striping. The following recommended kernel patches were installed:
102517-03 102436-02 102394-02 102516-06 |
The kernel was rebuilt with a new MAXUSERS value of 96, and this kernel enabled the machine to boot properly.
Information directly related to this situation was not available; however, there was a description of another type of panic that was related to seg_u. In that description, the MAXUSERS value was set too large, causing the kernel to overrun table space. Furthermore, the value of MAXUSERS varies among the different architectures and the different revisions of the OS and is directly related to the amount of physical RAM in the system in an inverse proportion. Further investigation revealed that the value of MAXUSERS was set to 128. Based on the related information, it seems that the panic was due to valloc attempting to define memory space in excess of the value of tmpptes.
Probably the system crashed in the middle of a sync(2) or write(2) operation, and during phase 1, fsck(1M) found that the specified inode was neither allocated nor unallocated.
If any directory entries point to this inode and you answer "yes" to this question, phase 2 might get UNALLOCATED messages. Carefully exit fsck(1M) and run ncheck(1M)--specifying the inode number after the -i option--to determine which file or directory is involved. You might be able to restore this file or directory from another system. fsck(1M) also might copy this file to the lost+found directory in a later phase.
For more information, see the chapter on checking file system integrity in the System Administration Guide, Volume 1.
The following lines are put into /etc/nsswitch.conf:
passwd: compat passwd_compat: nis |
server1% passwd passwd: Changing password for khh server1% |
passwd exits before a password is entered.
In the man page for passwd, you see the following:
If all requirements are met, by default, the passwd(1) command consults /etc/nsswitch.conf to determine which repositories need a password update. It searches the passwd(4) and passwd_compat entries. The sources (repositories) associated with these entries are updated. However, the supported password update configurations are limited to the following five cases. Failure to comply with the configurations prevents users from logging in to the system.
passwd: files passwd: files nis passwd: files nisplus passwd: compat (==> files nis) passwd: compat (==> files nisplus) passwd_compat: nisplus |
The passwd(1) man page does NOT say that you can use the line: passwd_compat: nis. passwd(1) works exactly as described in the man page.
When trying to lock a user account and using nispasswd with the -l option in the Solaris 2.6 release, you get this error: passwd (SYSTEM): System error: repository out of range.
Use passwd -r nisplus -l username instead.
This is the first of three messages that an NIS+ client prints when it cannot locate an NIS+ server on the network.
For details, refer to "hosts.org_dir: NIS+ servers unreachable".
This message appears at login 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.
To gain credentials for secure RPC, users can run keylogin(1) (after login) and type their secret key. To stop this message from appearing at time of login, users can run the chkey -p command and set their network password to be the same as their NIS+ password. If a user does not 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).
On a SunOS system running NIS (YP), the user runs yppasswdd(1M)and the system reports this error. On the NIS Master server, this error is in the messages file from rpc.yppasswdd: password file busy - try again. This error is caused superficially by the existence of a lock file, /var/yp/passwd.ptmp. Removing this file allows yppasswdd to run to completion, but subsequent invocations still fail with the same error message. The root cause is that yppasswdd has the-m option, which says to run make to push the maps out to the slave servers. In this situation, a problem occurred in pushing the maps to a slave server; the push would hang. Thus, the push was never completed, and the lock file was never removed. This was tested by doing the following:
#cd /var/yp #make passwd passwd is up to date #touch passwd #make passwd |
To fix the root cause, find out why the map does not push. In this situation, it was a routing issue; however, the remedy could lie elsewhere.
The user created a disk group, but forgot to make it shared. After it was made a shared disk group, the user attempted to start the second node (which had not been rebooted). pdbadmin start node on second pdb node failed with this repeated message until it finally timed out:
return from cluster_establish is join not allowed now retrying cluster_establish |
You can either reboot the second node or run vxdctl enable.
pdbadmin start node now works.
An attempt was made to access a file in a way forbidden by the protection system.
Check the ownership and protection mode of the file (with a long listing from the ls -l command) to see who is allowed access to the file. Then change the file or directory permissions, as needed.
The symbolic name for this error is EACCES, errno=13.
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.
For details, refer to "Recipient names must be specified".
A protocol error occurred. This error is device specific, but is generally not related to a hardware failure.
The symbolic name for this error is EPROTO, errno=71.
rlogin(1) fails on a machine with the SunOS system installed.
Check the permissions in 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/sbin/in.rlogind |
Check the login line in the /etc/inetd.conf file. It should look like the following:
login stream tcp nowait root /usr/sbin/in.rlogind in.rlogind |
Check /etc/passwd to see if an invalid login shell has been substituted in the entry for the login ID.
The protocol family has not been configured into the system or no implementation for it exists. This is used for the Internet protocols.
The symbolic name for this error is EPFNOSUPPORT, errno=123.
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.)
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.
The symbolic name for this error is EPROTONOSUPPORT, errno=120.
This message indicates either an application programming error, or badly configured protocols.
Make sure that the /etc/protocols file corresponds number-for-number with the NIS protocols(4) map. If it does, ask the vendor or author of the application for an update.
A protocol was specified that does not support the semantics of the socket type requested. This protocol 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.