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 file system it was checking.

Action

If fsck(1M) was checking the root file system, reboot the system immediately to avoid corrupting the / partition. If fsck(1M) was checking a mounted file system, unmount that file system 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 file system 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 file system from backup tapes. Otherwise, it is fine to proceed with fsck(1M).

** Phase 1b-- Rescan For More DUPS

Cause

The fsck(1M) command detected duplicate blocks while checking a file system, so fsck(1M) is rescanning the file system 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.

** Phase 2-- Check Pathnames

Cause

The fsck(1M) command is checking a file system, 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 file system from backup tapes. Otherwise it is fine to proceed with fsck(1M).

** Phase 3-- Check Connectivity

Cause

The fsck(1M) command is checking a file system, 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 file system.

** Phase 4-- Check Reference Counts

Cause

The fsck(1M) command is checking a file system, 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 file system.

** Phase 5-- Check Cyl groups

Cause

The fsck(1M) command is checking a file system, 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 file system.

`@@`

Cause

This message is about how to fix the common @@token sendmail errors. There are instances when you receive email bounce messages because of syntax errors complaining that it does not know how to send email to @@token. Probably a site is NOT running NIS and is generating these errors or is talking to another site that is generating the errors and then passing the email on to your site. This happens because a single token is changed into a null ("") token. As a result, ruleset 3 (S3) changes null tokens into @@token. There are two key issues here. First, you do not want to be the host responsible for generating these errors, and, second, you do not want to pass along any errors that were generated by other hosts.

Action

To fix this problem, modify rules S3 and S22. (You'll only have S22, if using main.cf.) First, so you do not cause these errors, comment out the invert aliases rule in S22:

S22
R$*<@LOCAL>$*      $:$1
#R$-<@$->          $:$>3${Z$1@$2$}   invert aliases
R$*<@$+.$*>$*      $@$1<@$2.$3>$4    already ok
R$+<@$+>$*         $@$1<@$2.$m>$3    tack on our domain
R$+                $@$1<@$w.$m>      tack on our full name

Next, so you do not pass on errors caused by other hosts, modify ruleset S3 from:

S3
# handle "from:<>"   special case
R$*<>$*		$@@        turn into magic token

To:

S3
# handle "from:<>"   special case
R$*<>$*		$@$n       turn into magic token

29a00 illegal instruction

Cause

When trying to boot a client from a boot/jumpstart server to install or 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

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 does not complete before the timer expires, this message appears and reading stops. (Usually this happens 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.

501 MAIL FROM: unrecognized address: @@`hostname`

Cause

A Sun machine running Sendmail 8.6 is used as a mailhost to send mail to the Internet in an environment that has MS Mailexchanger or a cc:Mail gateway. Mail from the MS exchange/cc:Mail gateway for the Internet is relayed to the mailhost, which actually delivers the mail. The mail from the Internet is accepted on the mailhost and forwarded to the MS exchanger/cc:mail gateway. The postmaster on the mailhost sees bounced messages with error messages, such as the following:

The original message was received at Thu, 29 May 1997 12:30:41 -0700 
from artemis [206.189.46.3]
     
   ----- The following addresses had delivery problems -----
<Joe_Smith@cc.test.com>  (unrecoverable error)
     
   ----- Transcript of session follows -----
... while talking to cc:
>>> MAIL From:<hermes>
>>> 501 MAIL FROM: unrecognized address: <hermes> 
554 <Joe_Smith@cc.test.com> Remote protocol error

When analyzed, this mail turns out to be mail that has bounced from the Internet (for any reason) and was on its way back to the MS Exchange/cc:Mail gateway by the mailhost. The MS Exchange/cc:Mail gateway does not want to accept the mail because the "MAIL FROM:" address does not stick to the standards. @@hostname is an illegal SMTP address. Sendmail does not have a restriction on sender's address; however, other SMTP gateways, which need to translate the address to their native address formats, are rather strict in adhering to the SMTP address format and would not accept the address in the @@hostname format.

Another situation: The user with cc:Mail sends mail to the Internet, and, due to one of many possible errors (user not found, host not found, and so forth), the message is sent back to the sender (bounces back). When a message is sent back, its recipient`s address is replaced by the sender's address and the sender's address is erased (contains only "<>"). When the bounced sender's address goes through ruleset 3 and then 11 on the user's mail gateway (as it has to return it to the cc:Mail gateway, which is in the local domain => mailer=ether), it is transformed to @@mail-gateway-name.

Action

Insert the following line in the S11 ruleset after the line starting with R$=D&:

R@       $@mailer_daemon<@$w>         for @@hostname problem

After the insertion, S11 looks like this:

S11
R$*<@$+>$*     $1<@$2>$3                    already ok
R$=D           $@$1<@$w>                    tack on my hostname
R@             $@mailer_daemon<@$w>         for @@hostname problem
R$+            $@$1<@$m>                    tack on my mbox hostname

550 `hostname`... Host unknown

Cause

This sendmail(1M) message indicates that the destination host machine, specified by the portion of the address after the at-sign (@), was not found during domain naming system (DNS) 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 inoperable, rather than unknown. If a DNS record contains an unknown alternate host, and the primary host is inoperable, sendmail(1M) returns a "Host unknown" message from the alternate host. [This is a known sendmail(1M) version 8.6.7 bug.]

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

550 Security server failed to perform requested command

Cause

While using the 3.x FW-1 FTP Security Server, the user sees the following error message when trying to use FTP get or put commands:

550 Security server failed to perform requested command

Action

FW-1's FTP Security Server sends a pwd command prior to any data connection command (such as get, put, ls), since it needs to know the current directory for purposes such as logging, virus inspection, and resources. FW-1 assumes that these commands are blocked whenever the pwd command is blocked. Therefore, do not disable pwd on your FTP server.

550 `username`... User unknown

Cause

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

Action

Check the email address and try again, perhaps with a slightly different spelling. If this does not work, contact the intended recipient and ask for a proper address.

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

Numbers and Symbols

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

Cause

Action

** Phase 1-- Check Blocks and Sizes

Cause

Action

See Also

** Phase 1b-- Rescan For More DUPS

Cause

Action

See Also

** Phase 2-- Check Pathnames

Cause

Action

See Also

** Phase 3-- Check Connectivity

Cause

Action

See Also

** Phase 4-- Check Reference Counts

Cause

Action

See Also

** Phase 5-- Check Cyl groups

Cause

Action

See Also

@@

Cause

Action

29a00 illegal instruction

Cause

Action

451 timeout waiting for input during source

Cause

Action

See Also

501 MAIL FROM: unrecognized address: @@hostname

Cause

Action

550 hostname... Host unknown

Cause

Action

See Also

550 Security server failed to perform requested command

Cause

Action

550 username... User unknown

Cause

Action

See Also

554 hostname... Local configuration error

Cause

Action

Technical Notes

See Also

* FILE SYSTEM WAS MODIFIED *

`@@`

451 timeout waiting for input during `source`

501 MAIL FROM: unrecognized address: @@`hostname`

550 `hostname`... Host unknown

550 `username`... User unknown

554 `hostname`... Local configuration error