test

Solaris Common Messages and Troubleshooting Guide

"B"

Bad address

Cause

The system encountered a hardware fault in attempting to access a parameter of a programming function.

Action

Check the address to see if it resulted from supplying the wrong device or option to a command. If that is not the problem, contact the vendor or author of the program for an update.

Technical Notes

This error could occur any time a function that takes a pointer argument is passed an invalid address. Because processors differ in their ability to detect bad addresses, on some architectures, passing bad addresses can result in undefined behaviors.

The symbolic name for this error is EFAULT, errno=14.

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

Cause

While checking inode link counts during phase 4, fsck(1M) found a file (or directory) that either does not exist or exists somewhere else.

Action

To clear the inode of its reference to this file or directory, answer "yes." With the -p (preen) option, fsck(1M) automatically clears bad or duplicate file references. Answering "yes" to this question seldom causes a problem.

Bad file number

Cause

Generally this message is a program error, not a usage error.

Action

Contact the vendor or author of the program for an update.

Technical Notes

Either a file descriptor refers to no open file, or a read(2)--or a write(2)--request is made to a file that is open only for writing or reading.

The symbolic name for this error is EBADF, errno=9.

block no. BAD I=inode no.

Cause

Upon detecting an out-of-range block, fsck(1M) prints the bad 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 -i inum filesystem

See Also

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

BAD_MESSAGE (error code 100) from X.400

Cause

In this situation, X.400 software had been working without problems. Suddenly, the message exchanges failed in ma_start_delivery(). It was returning an error code of 100 (BAD_MESSAGE).

The ma_start_delivery() call fails when trying to exchange a file of more than 900 bytes.

Action

X.400 was restarted with the wrong umask. To fix, set the umask to 0022 and restart the software.

bad module/chip at: position

Cause

This message from the memory management system often appears with parity errors and indicates a bad memory module or chip at the position listed. Data loss is possible, if the problem occurs other than at boot time.

Action

Replace the memory module or chip at the indicated position. Refer to the vendor's hardware manual for help finding this location.

Bad request descriptor

Cause

This message is apparently only used in NIS+ to indicate corrupted or missing tables.

Technical Notes

The symbolic name for this error is EBADR, errno=51.

BAD SUPER BLOCK: string

Cause

This message from fsck(1M) indicates that a file system's super block is damaged beyond repair and must be replaced. At boot time (with the -p option) this message is prefaced by the file system's device name. After this message comes the actual damage recognized (see Action). Unfortunately, fsck(1M) does not print the number of the damaged super block.

Action

The most common cause of this error is overlapping disk partitions. Do not immediately rerun fsck(1M) as suggested by the lines that display after the error message. First, make sure that you have a recent backup of the file system involved; if not, try to back up the file system now using ufsdump(1M). Then, run the format(1M) command, select the disk involved, and print out the partition information. 


# format
: N
> partition
> print
Note whether the overlap occurs at the beginning or end of the file system involved. Then, run newfs(1M) with the -N option to print out the file system parameters, including the location of backup super blocks. 

# newfs -N /dev/dsk/device
Select a super block from a non-overlapping area of the disk, but note that in most cases you have only one chance to select the proper replacement super block, which fsck(1M) soon propagates to all the cylinders. If you select the wrong replacement super block, data corruption will probably occur, and you will have to restore from backup tapes. After you select a new super block, provide fsck(1M) with the new master super block number: 

# fsck -o b=NNNN /dev/dsk/device

Technical Notes

Specific reasons for a damaged super block include: a wrong magic number, an out-of-range number of cylinder groups (NCG) or cylinders per group (CPG), the wrong number of cylinders, a preposterously large super block size, and trashed values in super block. These reasons are generally not meaningful, because a corrupt super block is usually extremely corrupt.

See Also

For more information on bad super blocks, see the sections on restoring bad super blocks in the System Administration Guide, Volume 1. If you are using AnswerBook online documentation, "super block" is a good search string.

BAD TRAP

Cause

A bad trap can indicate faulty hardware or a mismatch between hardware and its configuration information. Data loss is possible if the problem occurs other than at boot time.

Action

If you recently installed new hardware, verify that the software was correctly configured. Check the kernel traceback displayed on the console to see which device generated the trap. If the configuration files are correct, you probably have to replace the device.

In some cases, the bad trap message indicates a bad or down-rev CPU.

Technical Notes

A hardware processor trap occurred, and the kernel trap handler was unable to restore the system state. This message is a fatal error that usually precedes a panic, after which the system performs a sync, dump, and reboot. The following conditions can cause a bad trap: a system text or data access fault, a system data alignment error, or certain kinds of user software traps.

/bin/sh: file: too big

Cause

This Bourne shell message indicates a classic "no memory" error. While trying to load the program specified after the first colon, the shell noticed that the system ran out of virtual memory (swap space).

Action

For information on reconfiguring your system to add more swap space, refer to "Not enough space".

Block device required

Cause

A raw (character special) device was specified where a block device was required, such as during a call to the mount(1M) command.

Action

To see which block devices are available, use ls -l to look in /devices. Then specify a block device instead of a character device. Block device modes start with a b, whereas raw character device modes start with a c.

Technical Notes

The symbolic name of this error is ENOTBLK, errno=15.

Boot device: /iommu/sbus/directory/directory/sd@3,0

Cause

This message always appears at the beginning of rebooting. If there is a problem, the system hangs, and no other messages appear. This condition is caused by conflicting SCSI targets for the boot device, which is almost always target 3.

Action

The boot device is usually the machine's internal disk drive, target 3. Make sure that external and secondary disk drives are targeted to 1, 2, or 0, and do not conflict with each other. Also make sure that the tape drives are targeted to 4 or 5, and CD drives to 6, avoiding any conflict with each other or with the disk drives. You can set a device's target number using push-button switches or a dial on the back near the SCSI cables. If the targeting of the internal disk drive is in question, check it by powering off the machine, removing all external drives, turning the power on, and running the probe-scsi-all or probe-scsi command from the PROM monitor.

Broadcast Message from root (pts/int) on server [date]

Cause

This message from the wall(1M) command is transmitted to all users logged into a system. You could see it during a rlogin(1) or telnet(1) session, or on terminals connected to a timesharing system.

Action

Carefully read the broadcast message. Often this broadcast is followed by a shutdown warning.

For details about system shutdown, refer to "The system will be shut down in int minutes".

See Also

For more information on bringing down the system, see the section on halting the system in the System Administration Guide, Volume 1. If you are using AnswerBook online documentation, "halting the system" is a good search string.

Broken pipe

Cause

This condition is often normal, and the message is merely informational (as when piping many lines to the head(1) program). The condition occurs when a write on a pipe does not find a reading process. This usually generates a signal to the executing program, but this message displays when the program ignores the signal.

Action

Check the process at the end of the pipe to see why it exited.

Technical Notes

The symbolic name of this error is EPIPE, errno=32.

Bus Error

Cause

A process has received a signal indicating that it attempted to perform I/O to a device that is restricted or that does not exist. This message is usually accompanied by a core dump, except on read-only file systems.

Action

Use a debugger to examine the core file and determine what program fault or system problem led to the bus error. If possible, check the program's output files for data corruption that might have occurred before the bus error.

Technical Notes

Bus errors can result from either a programming error or device corruption on your system. Some common causes of bus errors are: invalid file descriptors, unreasonable I/O requests, bad memory allocation, misaligned data structures, compiler bugs, and corrupt boot blocks.