test

Solaris Common Messages and Troubleshooting Guide

"D"

data access exception

Cause

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.

Action

Upgrade your operating system to a version that supports the new hardware or machine architecture.

See Also

For more information on upgrades, see the section describing system and device configuration in the Solaris Transition Guide.

Data fault

Cause

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.

Action

Make sure the machine can reboot, then check the log file /var/adm/messages for hints about what went wrong.

Deadlock situation detected/avoided

Cause

A programming deadlock situation was detected and avoided.

Action

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.

Technical Notes

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 Also

See the section on deadlock handling in the System Interface Guide. See also the section on avoiding deadlock in the Multithreaded Programming Guide.

Destination address required

Cause

A required address was omitted from an operation on a transport endpoint. Destination address required.

Technical Notes

The symbolic name for this error is EDESTADDRREQ, errno=96.

destination component full

Cause

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.

Action

The following command should resolve the problem: /usr/sbin/nsr/nsrjb -H.

/dev/fd/int: /dev/fd/int: cannot open

Cause

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

Action

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
Otherwise, to make setuid/setgid shell scripts available, the machine must be rebooted after editing /etc/vfstab as detailed above.

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.

/dev/rdsk/c0t6d0s2: No such file or directory

Cause

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.

Action

Use the following command instead: 


# eject cdrom0
If volume manager /usr/sbin/vold is not running, you can use the following: 

# eject /dev/rdsk/c1t6d0s2

Note -

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.

Device busy

Cause

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.

Action

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.

Technical Notes

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.

device busy

Cause

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.

Action

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
If this works, then try:

# ./volmgt start
If this does not work, go to step C.

Step C: As root: 


# fuser /cdrom
Kill any processes you feel you have already terminated. A note of caution: If this is an NFS-mounted CD-ROM and there are other users who access this drive, make sure you know what process you are killing and why. 

# ./volmgt stop
#  ps -ef | grep vold
If vold still is running, kill the process. 

#  eject cdrom
If this does not work, then: 

#  cd /vol
Make sure that dev, dsk, rdsk, rmt are in the directory. If not, probably your /vol directory is corrupt and a reboot might be needed for proper rebuild.

Step D: The last three options are:

  1. Reboot.

  2. If the CD drive is external to the system, try power cycling the drive and pressing the eject button.

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

/dev/rdsk/string: CAN'T CHECK FILE SYSTEM.

Cause

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.

Action

Run fsck to clean the file system in question. For proper procedures, refer to "/dev/rdsk/string: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.".

/dev/rdsk/string: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.

Cause

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.

Action

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
Usually the files lost during fsck(1M) repair are those that were created just before a crash or power outage, and they cannot be recovered. If you lose important files, you can recover them from backup tapes.

If you do not have a backup, ask an expert to run fsck(1M) for you.

See Also

For more information on file checking, see the section on checking file system integrity in the System Administration Guide, Volume 1.

Directory not empty

Cause

The directory operation that was attempted, such as directory removal with rmdir(1), can be performed only on an empty directory.

Action

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.

Technical Notes

The symbolic name for this error is ENOTEMPTY, errno=93.

Disc quota exceeded

Cause

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.

Action

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.

Technical Notes

The symbolic name for this error is EDQUOT, errno=49.

disk does not appear to be prepared for encapsulation

Cause

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.

diskN not unique

Cause

During boot, the system displays disk0 not unique. The error happens before the kernel loads.

Action

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
and reset the system.

dlopen (libxfn.so) failed

Cause

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.

Action

Install package SUNWfns from of the distribution CD.

driver is already installed

Cause

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.

Action

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.

dtmail: cannot open mailfile on 2.5.1 /var/mail server

Cause

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

Action

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/
while the mailbox itself should look something like this:

-rw-------   1 zvinakis mail     3206838 Feb 19 11:51 /var/mail/zvinakis
If the directory's permissions are not set properly, issue these commands on the mail server: 

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
To change the permissions, type: 

chmod 600 /var/mail/joe

DUMP: Cannot open dump device `/dev/rdsk/c2t0d0s1': Permission denied

Cause

When using ufsdump(1M) as user sys (UID 3) on a disk drive in an SSA, the ufsdump(1M) command fails with this message.

Action

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
Change it to this: 

crw-r-----   1 root     sys      192,241 Jul 10  1996 /dev/rdsk/c2t0d0s1
You might also want to add the following line: 

ssd:* 0640 root sys
to the /etc/minor_perm file, so subsequently added arrays do not have the same problem.

dumptm: Cannot open `/dev/rmt/string': Device busy

Cause

During file system backup, the dump program cannot open the tape drive, because some other process is holding it open.

Action

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

DUP/BAD I=i OWNER=o MODE=m SIZE=s MTIME=t FILE=f REMOVE?

Cause

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

Action

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.

See Also

For more information on checking file systems, see the section on checking file system integrity in the System Administration Guide, Volume 1.

int DUP I=int

Cause

Upon detecting a block that is already claimed by another inode, fsck(1M) prints the duplicate block number and its containing inode (after I=).

Action

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

See Also

For more information, see the chapter on checking file system integrity in the System Administration Guide, Volume 1.