The default tape device /dev/rmt/0 or possibly the device specified by the TAPE environment variable is not currently connected to the system, is not configured, or its hardware symbolic link is broken.
List the files in the /dev/rmt directory to see which tape devices are currently configured. If none are configured, ensure that a tape device is correctly attached to the system, and reboot with the -r option to reconfigure devices.
If tape devices other than /dev/rmt/0 are configured, you could specify one of them after the -f option of tar(1).
This error message from tar(1) indicates that the checksum of the directory and the files it has read from tape does not match the checksum advertised in the header block. Usually this message indicates the wrong blocking factor, although it could indicate corrupt data on tape.
To resolve this problem, make certain that the blocking factor you specify on the command line (after -b) matches the blocking factor originally specified. If in doubt, leave out the block size and let tar(1) determine it automatically. If that remedy does not help, the tape data could be corrupted.
A physical write error has occurred on the tar(1) output file, which is usually a tape, although it could be a diskette or disk file. Look on the system console, where the device driver should provide the actual error condition. The condition might be a write-protected tape, a physical I/O error, an end-of-tape condition, or a file-too-large limitation.
In the case of write-protected tapes, enable the write switch. For physical I/O errors, replace the tape with a new one. For end-of-tape conditions, try using a higher density, if the device supports one, or use cpio(1) or pax(1) for their multi-volume support. When encountering the file-too-large limitations, use the parent shell's limit(1) or ulimit(1) facility to increase the maximum file size.
For more information on tar tapes, see the section on copying UFS files in the System Administration Guide, Volume 1.
This error can occur when an attempt was made to execute a pure-procedure program that is currently open for writing. It also occurs when attempting to open for writing or to remove a pure-procedure program being executed. (This message is obsolete.)
The symbolic name for this error is ETXTBSY, errno=26.
This message appears at the beginning of a cmdtool(1) session after 100,000 characters have scrolled by. Clicking the top rectangle of the scrollbar might display this message. No data were lost, but the user cannot scroll back before this wraparound point.
To increase the maximum size of the Command Tool log file, use cmdtool -M, specifying more than 100,000 bytes.
After configuring an Autoclient (Autoclient 2.1 - Solstice Adminsuite 2.3), particularly on a Solaris 2.6 environment, you might get a similar error message on your Server from /dev/console and/or from /var/adm/messages:
tftpd: nak: Transport endpoint is already connected |
A subsequent boot net by the Autoclient hangs. For example:
Boot Device:... File and Args... |
This error message is difficult to decipher. Also, at this early point in the autoclient's boot, there is a minimum record of the event. To troubleshoot this problem, a snoop of the client, run from another system on the client's subnet, is necessary.
A change was made in the Solaris 2.6 in.tftpd to use sendto(), instead of send(). Because the Solaris 2.5.1 environment uses send() as opposed to sendto(), one workaround would be to copy in.tftpd from a Solaris 2.5.1 to the Solaris 2.6 environment. Another workaround would be to troubleshoot from the server the nonexistent file that it is trying to receive by doing a snoop of the client.
For example (assuming you are using an onboard Ethernet interface):
# snoop autoclient_name |
# snoop ethernet_address_of_autoclient_name |
81911ED4.SUN4C TFTP Error: access violation |
For an AUTOCLIENT: 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. This is a correct entry for a sun4m system:
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 |
For a JUMPSTART client: The Error: access violation from the server to the client might be an indication that the wrong kernel architecture has been specified in the add_install_client command line. On the server, type these commands:
# cd /cdrom/cdrom0/s0 # ./add_install_client host_name correct_architecture |
All other follow the same path of checking the /tftpboot directory.
At boot time the /etc/rcS script runs the fsck(1M) command to check the integrity of file systems marked fsck in /etc/vfstab. If fsck(1M) cannot repair a file system automatically, it interrupts the boot procedure and produces this message. When fsck(1M) gets into this state, it cannot repair file systems without losing one or more files, so it defers this responsibility to you, the administrator. Data corruption has probably already occurred.
First run fsck -n on the file system to see how many and what type of problems exist. Then run fsck(1M) again to repair the file system. If you have a backup of the file system, you can generally answer "y" to all the fsck(1M) questions. It is a good practice to keep a record of all problematic files and inode numbers for later reference. To run fsck(1M) yourself, specify options as recommended by the boot script. For example:
# fsck /dev/rdsk/c0t4d0s0 |
If you do not have a backup, ask an expert to run fsck(1M) for you.
For more information, see the section on checking file system integrity in the System Administration Guide, Volume 1.
This message appears near the beginning of rebooting, immediately after a Boot device: ... message. Then, the system hangs. The problem is conflicting SCSI targets for a non-boot device. Having an external device turned off is unlikely to cause this problem.
For a solution, refer to "Boot device: /iommu/sbus/directory/directory/sd@3,0".
For more information, see the section on halting and booting in the System Administration Guide, Volume 1.
This message means the system is going down immediately, and it is too late to save any changes.
This message is often preceded by messages telling you that the system is going down in 15 minutes, 10 minutes, and so on. When you see these initial broadcast shutdown messages, save all your work, send any email you are working on, and close your files. Fortunately, vi(1) sessions are automatically saved for later recovery, but many other applications have no crash protection mechanism. Data loss is likely.
For more information on shutting down the system, see the System Administration Guide, Volume 1. If you are using AnswerBook online documentation, "halting the system" is a good search string.
This message from the system shutdown(1M) script informs you that the superuser is taking down the system.
Save all changes now or your work will be lost. Write out any files you were changing, send any email messages you were composing, and close your files.
For more information on shutting down the system, see the System Administration Guide, Volume 1. If you are using AnswerBook online documentation, "halting the system" is a good search string.
While using Firewall v2.0, the following sequence happens:
# telnet firewall-machine Trying 192.29.174.60 ... Connected to firewall-machine Escape character is '^]'. CheckPoint FireWall-1 authenticated Telnet server running on firewall-machine Login: testuser This gateway does not support Unix Password. |
Under Network Objects, edit the Gateway object Host Properties Auth Schemes and select UNIX Password. UNIX Password is not checked by default as it is considered an unsecure method of authentication.
This message appears in a pop-up dialog box whenever you start mailtool(1) while another mail reader has the inbox locked. A question follows: Do you wish to ask that mail reader to save the changes? You are given three choices.
If you choose Save Changes, mailtool(1) requests the other mail reader to relinquish its lock and write out any changes it has made to your inbox. If you choose Ignore, mailtool(1) reads your inbox without locking it. If you choose Cancel, mailtool(1) exits.
This problem can occur while booting from the net, and indicates a network connection problem.
Make sure the Ethernet cable is connected to the network. Check that this system has an entry in the NIS ethers(4) map or locally on the boot server. Then check the IP address of the server and the client to make sure they are on the same subnet. Local /etc/hosts files must agree with one another and with the NIS hosts(4) map.
If those conditions are not causing the problem, go to the system's PROM monitor ok prompt and run test net to test the network connection. (On older PROM monitors, use test-net instead.) If the network test fails, check the Ethernet port, card, fuse, and cable, replacing them if necessary. Also check the twisted pair port to make sure it is patched to the correct subnet.
For more information on packets, see SPARC: Installing Solaris Software. If you are using AnswerBook online documentation, "ARP/RARP" is a good search string.
The timer set for a STREAMS ioctl call has expired. The cause of this error is device specific and could indicate either a hardware or software failure, or perhaps a time-out value that is too short for the specific operation. The status of the ioctl(2) operation is indeterminate. This is also returned in the case of _lwp_cond_timedwait(2) or cond_timedwait(3THR).
The symbolic name for this error is ETIME, errno=62.
4.1.3C Sbus cards suffered a system freeze.
An attempt was made to create more than the maximum number of hard links (LINK_MAX, by default 32767) to a file. Because each subdirectory is a link to its parent directory, the same error results from trying to create too many subdirectories.
Check why the file has so many links to it. To get more than the maximum number of hard links, use symbolic links instead.
The symbolic name for this error is EMLINK, errno=31.
A process has too many files open at once. The system imposes a per-process soft limit on open files, OPEN_MAX (usually 64), which can be increased, and a per-process hard limit (usually 1024), which cannot be increased.
You can control the soft limit from the shell. In the C shell, use the limit(1) command to increase the number of descriptors. In the Bourne or Korn shells, use the ulimit -n command to increase the number of file descriptors.
If the window system refuses to start new applications because of this error, increase the open-file limit in your login shell before starting the window system.
The symbolic name for this error is EMFILE, errno=24.
A connect request was made on an already connected transport endpoint; or, a sendto(3XNET) or sendmsg(3XNET) transport endpoint specified a destination when already connected.
The symbolic name for this error is EISCONN, errno=133.
A request to send or receive data was disallowed because the transport endpoint is not connected and (when sending a datagram) no address was supplied.
The symbolic name for this error is ENOTCONN, errno=134.
The Ultra system fails to boot with TRAP 3E. The system sometimes also displays bad magic number errors.
This error is caused by a bad super block on the boot disk. Which, in turn, could have been caused by a SCSI configuration problem.
To fix:
Check the SCSI bus for illegal configuration, bad cables, and duplicate SCSI addresses.
Boot from CD-ROM as single user.
OK boot cdrom -sw |
Attempt to fsck(1M) boot disk. This could fail with a super block error.
# fsck /dev/rdsk/device |
Find the locations of alternate super blocks. BE SURE TO USE AN UPPERCASE -N. For example:
# newfs -N /dev/rdsk/c0t0d0s0 /dev/rdsk/c0t0d0s0: 2048960 sectors in 1348 cylinders of 19 tracks, 80 sectors 1000.5MB in 85 cyl groups (16 c/g, 11.88MB/g, 5696 i/g) super-block backups (for fsck -F ufs -o b=#) at: 32, 24432, 48832, 73232, 97632, 122032, 146432, 170832, 195232, 219632, 244032, 268432, 292832, 317232, 341632, 366032, 390432, 414832, 439232, 463632, 488032, 512432, 536832, 561232, 585632, 610032, 634432, 658832, 683232, 707632, 732032, 756432, 778272, 802672, 827072, 851472, 875872, 900272, 924672, 949072, 973472, 997872, 1022272, 1290672, ... |
Using an alternate super block, run fsck(1M) on the disk. You might have to try more than one alternate super block to make this to work. Pick a couple from the beginning, the middle, and the end.
# fsck -o b=<altblk> /dev/rdsk/c0t0d0s0 |
The boot block is probably bad too. Restore it while you are booted from the CD-ROM.
# /usr/sbin/installboot /usr/platform/architecture/lib/fs/ufs/bootblk /dev/rdsk/c0t0d0s0 |
Reboot the operating environment.
# reboot |