test

Solaris Common Messages and Troubleshooting Guide

"D"

data access exception

Cause

This message can result from running an old version of the operating system that does not support new hardware, or by running an operating system that is not configured for new hardware. It can also result from incorrectly installed DSIMMs or from a disk problem.

Action

Upgrade your operating system to a version that supports the new hardware or machine architecture. For example, upgrading a SPARCstation 2 (with sun4c kernel architecture) to a SPARCstation 20 (with sun4m kernel architecture) requires an operating system upgrade or reconfiguration.

See Also

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

Data fault

Cause

This 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.¤ 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.

¤ See the message "BAD TRAP" for more information.

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

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

Cause

setuid and setgid shell scripts refuse to run - they simply 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 filesystem 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 Filesystem (fdfs) on Solaris 2 and have no connection with floppy disks!

Ensure that the fdfs is mounted as /dev/fd. The following line should appear in /etc/vfstab exactly like this (with NO initial comment symbol): 


fd		-		/dev/fd		fd	-	no	-
before the machine is next rebooted.

It may be possible to remount /dev/fd without rebooting by running the following as root: 


# mount fd /dev/fd
If this fails the machine must be rebooted after editing /etc/vfstab as detailed above, before setuid/setgid shell scripts are available.

Some administrators, unaware of what /dev/fd is for, comment out the entry in /etc/vfstab that mounts the fdfs (File Descriptor filesystem). This may 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 is because the CD-ROM is on controller 1 not 0. For the eject(1) command, the cdrom "nickname" equates to /dev/rdsk/c0t6d0s2. On an Ultra 450, the CD-ROM is /dev/rdsk/c1t6d0s2. So, 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: 

# eject /dev/rdsk/c1t6d0s2

Note: Make sure that the front panel of the system is unobstructed so that 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

You eject cdrom and you receive the message device busy. This could be the result of a number of problems. Below is a list of things that you can check and do to allow ejection of the cd from the device.

Action

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 

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

Step C: As root 


# fuser /cdrom
Kill any processes that you feel that you have already terminated. A note of caution: If this is a nfs-mounted cdrom 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 exists kill the process. 

#  eject cdrom
If this does not work: 

#  cd /vol
Make sure that dev, dsk, rdsk, rmt are in the directory. If not, most possibly your /vol directory is corrupt and a reboot may 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 cdrom 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 filesystem 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 filesystem in question. See the message "/dev/rdsk/int: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY" for proper procedures.

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

Cause

At boot time the /etc/rcS script runs the fsck(1M) command to check the integrity of filesystems marked "fsck" in /etc/vfstab. If fsck(1M) cannot repair a filesystem automatically, it interrupts the boot procedure and produces this message. When fsck(1M) gets into this state, it cannot repair a filesystem 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 filesystem, to see how many and what type of problems exist. Then run fsck(1M) again to repair the filesystem. If you have a recent backup of the filesystem, you can generally answer "y" to all the fsck(1M) questions. It's 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 these 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 don't 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 filesystem integrity in the System Administration Guide, Volume I.

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.

diskN not unique

Cause

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

Action

There are more than 1 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.

Disc quota exceeded

Cause

The user's disk limit has been exceeded on a user filesystem, 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 will 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.

driver is already installed

Cause

Added the Sunpc 4.1 package and then necessary patches (102924). When trying to run sunpc_install, got the error message. prtconf(1M) shows the driver is not attached, and modinfo(1M) displays 4 modules.

Tried to remove the package and back out the patch. Then reinstalled, but still received the same error.

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 pertaining to Sunpc in the files: /etc/devlink.tab, /etc/driver_aliases, and /etc/rc2.d/S10storekernname, and then reinstall the package.

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 a SSA, the ufsdump(1M) command fails with the message.

Action

The permissions on the ssd 'instance path' for disk in an SSA are created with 600 permissions. They should be 0640 for a non-root user to be able to read them. For example, 


# ls -lL /dev/rdsk/c2t0d0s1
crw-------   1 root     sys      192,241 Jul 10  1996 /dev/rdsk/c2t0d0s1
Change it so it reads: 

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 filesystem 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 end up removing more than a few files in this manner, data loss will result, so it might be preferable to restore the filesystem from backup tapes.

See Also

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

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 will 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 filesystem integrity in the System Administration Guide, Volume I.