Wednesday, December 4, 2013

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

"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

##############################################################

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.

No comments:

Post a Comment