This comment from the fsck(1M) command tells you that it changed the file system it was checking.
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.
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.
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).
For more information, see the chapter on checking file system integrity in the System Administration Guide, Volume 1.
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.
If fsck(1M) executes this optional phase, you will see additional DUP/BAD messages in phases 2 and 4.
For more information, see the chapter on checking file system integrity in the System Administration Guide, Volume 1.
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.
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).
For more information, see the chapter on checking file system integrity in the System Administration Guide, Volume 1.
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.
You can usually answer "yes" to all these questions without harming the file system.
For more information, see the chapter on checking file system integrity in the System Administration Guide, Volume 1.
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.
You can usually answer "yes" to all these questions without harming the file system.
For more information, see the chapter on checking file system integrity in the System Administration Guide, Volume 1.
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.
You can usually answer "yes" to all these questions without harming the file system.
For more information, see the chapter on checking file system integrity in the System Administration Guide, Volume 1.
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.
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 |
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 |
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 |
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.
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.
For more information about setting the timer, see the section describing the sendmail(1M) configuration options in the System Administration Guide, Volume 3. If you are using AnswerBook online documentation, the term "timeouts" is a good search string.
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 |
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.
Insert the following line in the S11 ruleset after the line starting with R$=D&:
R@ $@mailer_daemon<@$w> for @@hostname problem |
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 |
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.
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.
For information on how sendmail(1M) works, see the System Administration Guide, Volume 3
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 |
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.
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.
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.
For information on how sendmail(1M) works, see the System Administration Guide, Volume 3.
This sendmail(1M) message usually indicates that the local host is trying to send mail to itself.
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.
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.
For information on how sendmail(1M) works, see the System Administration Guide, Volume 3.