test

Solaris Common Messages and Troubleshooting Guide

Numbers and Symbols

***** FILE SYSTEM WAS MODIFIED *****

Cause

This comment from the fsck(1M) command tells you that it changed the filesystem it was checking.

Action

If fsck(1M) was checking the root filesystem, reboot the system immediately to avoid corrupting the / partition. If fsck(1M) was checking a mounted filesystem, unmount that filesystem and run fsck(1M) again, so that work done by fsck(1M) is not undone when in-memory file tables are written out to disk.

** Phase 1-- Check Blocks and Sizes

Cause

The fsck(1M) command is checking the filesystem shown in the messages that are displayed before this one. The first phase checks the inode list, finds bad or duplicate blocks, and verifies the inode size and format.

Action

If more than a dozen errors occur during this important phase, you might want to restore the filesystem from backup tapes. Otherwise it is fine to proceed with fsck(1M).

See Also

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

** Phase 1b-- Rescan For More DUPS

Cause

The fsck(1M) command detected duplicate blocks while checking a filesystem, so fsck(1M) is rescanning the filesystem to find the inode that originally claimed that block.

Action

If fsck(1M) executes this optional phase, you will see additional DUP/BAD messages in phases 2 and 4.

See Also

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

** Phase 2-- Check Pathnames

Cause

The fsck(1M) command is checking a filesystem, and fsck(1M) is now removing directory entries pointing to bad inodes that were discovered in phases 1 and 1b. This phase might ask you to remove files, salvage directories, fix inodes, reallocate blocks, and so on.

Action

If more than a dozen errors occur during this important phase, you might want to restore the filesystem from backup tapes. Otherwise it is fine to proceed with fsck(1M).

See Also

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

** Phase 3-- Check Connectivity

Cause

The fsck(1M) command is checking a filesystem, and fsck(1M) is now verifying the integrity of directories. You might be asked to adjust, create, expand, reallocate, or reconnect directories.

Action

You can usually answer yes to all these questions without harming the filesystem.

See Also

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

** Phase 4-- Check Reference Counts

Cause

The fsck(1M) command is checking a filesystem, and fsck(1M) is now checking link count information obtained in phases 2 and 3. You might be asked to clear or adjust link counts.

Action

You can usually answer yes to all these questions without harming the filesystem.

See Also

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

** Phase 5-- Check Cyl groups

Cause

The fsck(1M) command is checking a filesystem, and fsck(1M) is now checking the free-block and used-inode maps. You might be asked to salvage free blocks or summary information.

Action

You can usually answer yes to all these questions without harming the filesystem.

See Also

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

29a00 illegal instruction

Cause

When trying to boot a client from a boot/jumpstart server to install/upgrade a workstation, it fails with the following message: 


boot net - install
Rebooting with command: net - install
Boot device: /iommu/sbus/ledma@f, 400010/le@f, 8c0000 File and args: -
install
29a00  Illegal Instruction
(0) ok

Action

The problem lies in the /tftpboot directory of the boot server. Confirm that the HOSTID and HOSTID.ARCH files are linked to the correct inetboot file for your architecture. The following is an example of how a symbolic link should look: 


# cd /tftpboot
# ls -l 81971904*
81971904 -> inetboot.sun4m.Solaris_2.4
81971904.SUN4M -> inetboot.sun4m.Solaris_2.4
The following is an example of an incorrect entry for a sun4m system: 

C753002F -> inetboot.axil4m.Solaris_2.5.1
C753002F.AXIL4M -> inetboot.axil4m.Solaris_2.5.1
If the entries are not correct, remove the entry for the particular client in this directory, using rm_install_client or rm_client commands, and re-add the client with the add_install_client(1M) or add_client command or through Solstice giving the correct architecture.

451 timeout waiting for input during source

Cause

When sendmail(1M) reads from anything that might time out, such as an SMTP connection, it sets a timer to the value of the r processing option before reading begins. If the read doesn't complete before the timer expires, this message appears and reading stops. (Usually this is during RCPT.) The mail message is then queued for later delivery.

Action

If you see this message often, increase the value of the r processing option in the /etc/mail/sendmail.cf file. If the timer is already set to a large number, look for hardware problems such as poor network cabling or connections.

See Also

For more information about setting the timer, see the section describing the sendmail(1M) configuration options in the Mail Administration Guide. If you are using the AnswerBook, the term "timeouts" is a good search string.

550 hostname... Host unknown

Cause

This sendmail(1M) message indicates that the destination host machine, specified by the address portion after the @ (at-sign), was not found during DNS (Domain Naming System) lookup.

Action

Use the nslookup(1M) command to verify that the destination host exists in that or other domains, perhaps with a slightly different spelling. Failing that, contact the intended recipient and ask for a proper address.

Sometimes this return message indicates that the intended host is down, rather than unknown. If a DNS record contains an unknown alternate host, and the primary host is down, sendmail(1M) returns a "Host unknown" message from the alternate host.¤

For uucp(1C) mail addresses, the "Host unknown" message probably means that the destination hostname is not listed in the /etc/uucp/Systems file.

Technical Notes

¤ This is a known sendmail(1M) version 8.6.7 bug.

See Also

For information on how sendmail(1M) works, see the Mail Administration Guide.

550 username... User unknown

Cause

This sendmail(1M) message indicates that the intended recipient, specified by the address portion before the @ (at-sign), could not be located on the destination host machine.

Action

Check the e-mail address and try again, perhaps with a slightly different spelling. If this doesn't work, contact the intended recipient and ask for a proper address.

See Also

For information on how sendmail(1M) works, see the Mail Administration Guide.

554 hostname... Local configuration error

Cause

This sendmail(1M) message usually indicates that the local host is trying to send mail to itself.

Action

Check the value of the $j macro in the /etc/mail/sendmail.cf file to ensure that this value is a fully-qualified domain name.

Technical Notes

When the sending system provides its hostname to the receiving system (in the SMTP HELO command), the receiving system compares its name to the sender's name. If these are the same, the receiving system issues this error message and closes the connection. The name provided in the HELO command is the value of the $j macro.

See Also

For information on how sendmail(1M) works, see the Mail Administration Guide.