This message appears when running an old version of the operating system that does not support new hardware or when running an operating system that is not configured for new hardware. It can also be the result of an incorrectly installed DSIMMs or a disk problem.
Upgrade your operating system to a version that supports the new hardware or machine architecture.
For more information on upgrades, see the section describing system and device configuration in the Solaris Transition Guide.
This error is a kind of BAD TRAP that usually causes a system panic. When this message appears after a BAD TRAP message, a system text or data access fault probably occurred. [See the message BAD TRAP for more information.] In the absence of a BAD TRAP message, this message might indicate a user text or data access fault. Data loss is possible, if the problem occurs other than at boot time.
Make sure the machine can reboot, then check the log file /var/adm/messages for hints about what went wrong.
A programming deadlock situation was detected and avoided.
If the system had not detected and avoided a deadlock, a piece of software would have hung. Run the program again. The deadlock might not reoccur.
This error usually relates to file and record locking, but can also apply to mutexes, semaphores, condition variables, and read/write locks.
The symbolic name for this error is EDEADLK, errno=45.
See the section on deadlock handling in the System Interface Guide. See also the section on avoiding deadlock in the Multithreaded Programming Guide.
A required address was omitted from an operation on a transport endpoint. Destination address required.
The symbolic name for this error is EDESTADDRREQ, errno=96.
Solstice backup is reporting destination component full.
This message appears when a manual operation is performed on the jukebox/autochanger (for example, physically unloading the tape drive by means of the buttons on the autochanger, rather than using SBU to unmount the volume). This operation causes SBU to lose track of the status of the media in the autochanger.
The following command should resolve the problem: /usr/sbin/nsr/nsrjb -H.
setuid and setgid shell scripts refuse to run. They return an error message similar to /dev/fd/3: /dev/fd/3: cannot open. (The number following /dev/fd/ is not necessarily 3.) The first line of the script properly starts a shell, and the file system containing the script is not mounted with the nosuid option.
Running truss on the shell script reveals that a call to open(2) is failing with error number 6 (ENXIO):
open("/dev/fd/3", O_RDONLY) Err#6 ENXIO |
setuid and setgid shell scripts use the file descriptors in /dev/fd. The contents of /dev/fd are a file descriptor file system (FDFS) and have no connection with floppy disks!
Ensure that the fdfs is mounted as /dev/fd. Before the machine is next rebooted, the following line should appear in /etc/vfstab, exactly like this (with no initial comment symbol):
fd - /dev/fd fd - no - |
It might be possible to remount /dev/fd without rebooting by running the following as root:
# mount fd /dev/fd |
Some administrators, unaware of what /dev/fd is for, comment out the entry in /etc/vfstab that mounts the FDFS (file descriptor file system). This can go unnoticed until an attempt is made to run a setuid or setgid shell script.
When attempting to eject a CD-ROM on a Ultra 450 system, the eject cdrom command fails, displaying the error message.
This happens when the CD-ROM is on controller 1, not 0. When using the eject(1) command, the CD-ROM "nickname" equates to /dev/rdsk/c0t6d0s2. On an Ultra 450, the CD-ROM equates to /dev/rdsk/c1t6d0s2. Therefore, using cdrom does not work.
Use the following command instead:
# eject cdrom0 |
# eject /dev/rdsk/c1t6d0s2 |
Make sure that the front panel of the system is unobstructed so the CD-ROM tray is not blocked. Otherwise, the eject(1) command appears to hang since the tray is trying to open, but is physically blocked.
An attempt was made to mount a device that was already mounted or to unmount a device containing an active file (such as an open file, a current directory, a mount point, or a running program). This message also occurs when trying to enable accounting that is already enabled.
To unmount a device containing active processes, close all the files under that mount point, quit any programs started from there, and change directories out of that hierarchy. Then try to unmount again.
Mutexes, semaphores, condition variables, and read/write locks set this error condition to indicate that a lock is held.
The symbolic name for this error is EBUSY, errno=16.
If you perform an eject cdrom and then receive the above message, it could be due to a number of problems. Below is a list of things that you can check and do to permit ejection of the CD from the device.
Step A: Ensure that the current directory is not somewhere in the CD:
% cd %eject cdrom |
Step B: As root:
# cd /etc/init.d # ./volmgt stop # eject cdrom |
# ./volmgt start |
Step C: As root:
# fuser /cdrom |
# ./volmgt stop # ps -ef | grep vold |
# eject cdrom |
# cd /vol |
Step D: The last three options are:
Reboot.
If the CD drive is external to the system, try power cycling the drive and pressing the eject button.
If all else fails and the CD-ROM is external, on the right hand side of the eject button is a small hole into which you can insert a small straight device which forces manual ejection of the caddy.
The system cannot automatically clean (preen) this file system because it appears to be set up incorrectly or is having hard-disk problems. This message asks that you run fsck(1M) manually, since data corruption might already have occurred.
Run fsck to clean the file system in question. For proper procedures, refer to "/dev/rdsk/string: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.".
During a boot, the /etc/rcS script runs the fsck(1M) command to check the integrity of file systems marked "fsck" in /etc/vfstab. If fsck(1M) cannot repair a file system automatically, it interrupts the boot procedure and produces this message. When fsck(1M) gets into this state, it cannot repair a file system without losing one or more files, so it wants to defer this responsibility to you, the administrator. Data corruption has probably already occurred.
First run fsck -n on the file system, to see how many and what type of problems exist. Then run fsck(1M) again to repair the file system. If you have a recent backup of the file system, you can generally answer "y" to all the fsck(1M) questions. It is a good idea to keep a record of all problematic files and inode numbers for later reference. To run fsck(1M) yourself, specify options as recommended by the boot script. For example:
# fsck /dev/rdsk/c0t4d0s0 |
If you do not have a backup, ask an expert to run fsck(1M) for you.
For more information on file checking, see the section on checking file system integrity in the System Administration Guide, Volume 1.
The directory operation that was attempted, such as directory removal with rmdir(1), can be performed only on an empty directory.
To remove the directory, first remove all the files that it contains. A quick way to remove a non-empty directory hierarchy is with the rm -r command.
The symbolic name for this error is ENOTEMPTY, errno=93.
The user's disk limit has been exceeded on a user file system, usually because a file was just created or enlarged beyond the limit. This almost always refers to a magnetic disk, and not to an optical disc. Any data created after this condition occurs can be lost.
The user can delete files to bring disk usage under the limit, or the server administrator can use the edquota(1M) command to increase the user's disk limit.
The symbolic name for this error is EDQUOT, errno=49.
When attempting to encapsulate the root disk during vxinstall, the user gets this error message.
The disk was sliced properly for encapsulation; however, the prtvtoc command was non-executable, because the permissions had been changed.
During boot, the system displays disk0 not unique. The error happens before the kernel loads.
There are more than one devalias entries for disk0. Use devalias at the OK prompt to see the entries.
To remove the duplicate, run the following command at the OK prompt:
nvunalias disk0 |
The SUNWfns package was left out of the End User Cluster. If only this cluster is installed and automounter is used, it fails with the above message. libxfn.so is the shared library for the Federated Naming System.
Install package SUNWfns from of the distribution CD.
The SunPCTM 4.1 package and then necessary patches (102924) were added. When trying to run sunpc_install, the user got the above error message. prtconf(1M) shows that the driver is not attached, and modinfo(1M) displays 4 modules.
After removing the package, backing out the patch, and reinstalling, the user still received the same error message.
SunPC had previously been installed on the system. When removing the package with the pkgrm(1M) command, not all components were removed, because pkgrm(1M) is not aware of changes made by the sunpc_install script.
To resolve this problem it is necessary to remove sections in the files pertaining to SunPC: /etc/devlink.tab, /etc/driver_aliases, and /etc/rc2.d/S10storekernname, and then reinstall the package.
/var/mail is mounted onto client machine A, which is running CDE 1.2 (the Solaris 2.6 release), from machine B, a server running the Solaris 2.5.1 release.
OpenWindow's mailtool can read/write mailfiles on the server without any problems. However, CDE's dtmail does not open the mailbox.
The bug's permissions and ownership have to be checked. The mail directory should have the following permissions:
skywalker$ ls -lad /var/mail drwxrwsrwt 3 root mail 512 Feb 10 14:40 /var/mail/ |
-rw------- 1 zvinakis mail 3206838 Feb 19 11:51 /var/mail/zvinakis |
chmod a+t /var/mail chmod g+s /var/mail |
If the permissions (or group) are not correct on the mailbox itself, using "joe" as an example mailbox, type:
chgrp mail /var/mail/joe |
chmod 600 /var/mail/joe |
When using ufsdump(1M) as user sys (UID 3) on a disk drive in an SSA, the ufsdump(1M) command fails with this message.
Six-hundred (600) permissions were created on the SSD "instance path" for a disk drive in an SSA. For a non-root user to read them, there should have been 0640. For example, if you see this:
# ls -lL /dev/rdsk/c2t0d0s1 crw------- 1 root sys 192,241 Jul 10 1996 /dev/rdsk/c2t0d0s1 |
crw-r----- 1 root sys 192,241 Jul 10 1996 /dev/rdsk/c2t0d0s1 |
ssd:* 0640 root sys |
During file system backup, the dump program cannot open the tape drive, because some other process is holding it open.
Find the process that has the tape drive open, and either kill(1) the process or wait for it to finish.
# ps -ef | grep /dev/rmt # kill -9 processID |
During phase 1, fsck(1M) found duplicate blocks or bad blocks associated with the file or directory specified after FILE= whose inode number appears after I= (with other information).
To remove this file or directory, answer "yes." If you have to remove more than a few files in this manner, data can be lost. Therefore, it might be preferable to restore the file system from backup tapes.
For more information on checking file systems, see the section on checking file system integrity in the System Administration Guide, Volume 1.
Upon detecting a block that is already claimed by another inode, fsck(1M) prints the duplicate block number and its containing inode (after I=).
In fsck(1M) phases 2 and 4, you decide whether or not to clear these bad blocks. Before committing to repair with fsck(1M), you could determine which file contains this inode by passing the inode number to the ncheck(1M) command:
# ncheck -iinum filesystem |
For more information, see the chapter on checking file system integrity in the System Administration Guide, Volume 1.