This comment from the fsck(1M) command tells you that it changed the filesystem it was checking.
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.
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.
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).
For more information, see the chapter on checking filesystem integrity in the System Administration Guide, Volume I.
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.
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 filesystem integrity in the System Administration Guide, Volume I.
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.
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).
For more information, see the chapter on checking filesystem integrity in the System Administration Guide, Volume I.
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.
You can usually answer yes to all these questions without harming the filesystem.
For more information, see the chapter on checking filesystem integrity in the System Administration Guide, Volume I.
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.
You can usually answer yes to all these questions without harming the filesystem.
For more information, see the chapter on checking filesystem integrity in the System Administration Guide, Volume I.
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.
You can usually answer yes to all these questions without harming the filesystem.
For more information, see the chapter on checking filesystem integrity in the System Administration Guide, Volume I.
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 |
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 |
C753002F -> inetboot.axil4m.Solaris_2.5.1 C753002F.AXIL4M -> inetboot.axil4m.Solaris_2.5.1 |
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.
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 Mail Administration Guide. If you are using the AnswerBook, the term "timeouts" is a good search string.
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.
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.
¤ This is a known sendmail(1M) version 8.6.7 bug.
For information on how sendmail(1M) works, see the Mail Administration Guide.
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.
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.
For information on how sendmail(1M) works, see the Mail Administration Guide.
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 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.
For information on how sendmail(1M) works, see the Mail Administration Guide.