When using an Adaptec AHA-154x Cx SCSI HBA during installation of the IA release, you might see a message during the MDB device probe that says failed to initialize adapter after the probe has correctly identified the card. There are a variety of reasons for this error, but in all cases the error is because of misconfiguring the card.
To correct the problem, press Ctrl-A during boot to enter the 154x BIOS configuration utility. Choose the Configure/View Host Adapter Settings option, then press the F6 key to return the adapter to its factory default settings.
After doing this, reconfigure the adapter using the instructions contained in the IA Device Configuration Guide or Driver Update Guide, if applicable. It is especially important that the adapter be configured to use DMA 6. Note that it must be changed from the default of DMA 5.
While installing a policy from the GUI (or the command line) the following error message is displayed:
default.W: Security Policy Script generated into default.pf default: Compiled OK. Installing Security Policy default on all.all@lab-netra Failed to Load Security Policy: Invalid argument <-------------- !! Installing Security Policy on localhost(localhost) failed |
If you truss the policy load, you receive the following:
truss -o /tmp/truss -f -vall -rall -wall /etc/fw/bin/fw /etc/fw/conf/default.W |
The following is near the end of the truss:
1226: open("/dev/fw0", O_RDWR|O_NONBLOCK) = 7 1226: ioctl(7, 0xC0C07A18, 0xEFFFBCA0) Err#22 EINVAL |
This problem is caused by someone "plumbing" or configuring a new Ethernet interface after Firewall-1 has already started (that is, plumbing an interface by hand after the system has been booted).
This error can be resolved by configuring the interface to configure automatically at boot time (for example, by creating a /etc/hostname.qe0 file) and rebooting the system.
The following is another solution:
/etc/fw/bin/fwstop # Stop firewall modinfo | grep fw # Get kernel module ID 85 f5e19000 3cc0c 51 1 fw (fw) modunload -i 85 # Unload kernel module /etc/fw/bin/fwstart # Restart firewall |
The policy installs correctly now with the following:
# ./fw load ../conf/default.W default.W: Security Policy Script generated into default.pf default: Compiled OK. |
The user receives this message while trying to boot the Ultra over the network by using the FDDI 5.0 card.
Setenv auto-boot? to false.
Reset the system.
Boot the FDDI card.
When starting OpenWindows from the command line, the following error message is echoed on the Solaris "Welcome" screen: fbconsole: ioctl SRIOCSREDIR: Device Busy
Once inside OpenWindows, the following message is displayed in the background windows and when starting cmdtool -C:
SYSTEM WARNING: Object 0x340f8, Device busy, ioctl SRIOCSREDIR returned -1, attempt to make tty the console failed (Tty package)
OpenWindows was probably started in the background (using the "&"). Exit OpenWindows, and run the command in foreground: /usr/openwin/bin/openwin
If this does not help, then perhaps some daemon or process is "holding" the console. Type the command: fuser /dev/console.
A list of process IDs is returned. Examine these processes to determine if an application has hold of the console (using the ps(1) command helps).
This message appears on the system console to indicate that the floppy driver fd(4) could not read the label on a diskette. Usually this is either because a new diskette has not yet been formatted, or a formatted diskette has become corrupted. This message often appears along with read failed and bad format messages after volcheck(1) has been run.
If you are certain that the diskette contains no data, run fdformat -d to format the diskette in DOS format. (You can also format a diskette in UFS format if you like, although then it cannot be transported to most other systems.) When the diskette is formatted, you can write on it, if it has not been corrupted beyond repair.
Either a file descriptor refers to no open file or a read request was made to a file that is open only for writing.
The symbolic name for this error is EBADFD, errno=81.
The name of an existing file was mentioned in an inappropriate context. For example, establishing a link to an existing file, or overwriting an existing file are not allowed when the csh(1) noclobber option is set.
Look at the names of files in the directory, then try again with a different name or after renaming or removing the existing file.
The symbolic name for this error is EEXIST, errno=17.
This is a programming problem and, in some cases, is unavoidable.
All a user can do is restart the program and hope deadlock does not reoccur.
In the file locking subsystem, two processes tried to modify some lock at the same time. In the multi-threading subsystem, two threads became deadlocked and could not continue. When a program using the threads library encounters this error, it should restart the deadlocked threads.
The symbolic name for this error is EDEADLOCK, errno=56.
The specified file name has too many characters.
If a file name or path name component is too long, devise a shorter name. If the total path name is longer than PATH_MAX characters, first change to an intermediate directory, then specify a shorter path name. Newly created data will be lost unless written to another file with a shorter name.
In a UFS or NFS-mounted UFS file system, the length of a path name component exceeds MAXNAMLEN (255) characters, or the total length of the path name exceeds PATH_MAX (1024) characters. In a System V file system, the length of a path name component exceeds NAME_MAX (14) characters while no-truncation mode is in effect. These values are defined in the /usr/include/limits.h file.
The symbolic name for this error is ENAMETOOLONG, errno=78.
This error message is seen during a login. The login fails with the message No utmpx entry.
Refer to "No utmpx entry".
The fsck(1M) command has just checked a file system, and has determined that the file system is clean. The file system's super block, however, still thinks the file system is "dirty" in some way.
If you believe that the file system is adequately repaired, answer "yes" to mark the file system as clean.
Different "dirty" file system types are listed in /usr/include/sys/fs/ufs_fs.h, and include FSACTIVE, FSBAD, FSFIX, FSLOG, and FSSUSPEND.
For more information on super blocks, see the section on checking file system integrity in the System Administration Guide, Volume 1. If you are using AnswerBook online documentation, "bad super block" is a good search string.
The kernel file table is full, because too many files are open on the system. Temporarily, no more files can be opened. New data created under this condition will probably be lost.
Simply waiting often gives the system time to close files. However, if this message occurs often, reconfigure the kernel to allow more open files. To increase the size of the file table, increase the value of MAXUSERS in the /etc/system file. The default MAXUSERS value is the amount of main memory in Mbytes, minus 2.
The symbolic name for this error is ENFILE, errno=23.
The file size exceeded the limit specified by ulimit(1), or the file size exceeds the maximum supported by the file system. New data created under this condition can probably be lost.
In the C shell, use the limit(1) command to see or set the default file size. In the Bourne or Korn shells, use the ulimit -a command. Even when the shells claim that the file size is unlimited, in fact the system limit is FCHR_MAX (usually 1 Gbyte).
The symbolic name for this error is EFBIG, errno=27.
File Manager issues this message and fails to come up whenever the /tmp/.removable directory is owned by another user and is not in 1777 mode. This can happen, for example, when multiple users share a workstation.
Have the original owner use chmod(1) to change the mode of this file back to 1777, its default creation mode. Rebooting the workstation also resolves this problem.
This is a known problem that was fixed in the Solaris 2.4 release.
During phase 5, fsck(1M) detected that the actual number of free blocks in the file system did not match the super block's free block count. The df(1M) command accesses this free block count when measuring file system capacity.
Generally you can answer "yes" to this question without harming the file system.
For more information on super blocks, see the section on checking file system integrity in the System Administration Guide, Volume 1. If you are using AnswerBook online documentation, "bad super block" is a good search string.
If you have received the following messages from fsck(1M):
CANNOT READ: BLK 196896 CONTINUE? y THE FOLLOWING SECTORS COULD NOT BE READ: 196896 196897 196898 196899 |
DUMP: Warning - cannot read sector 164016 of /dev/vx/rdsk/newdg/vol02 DUMP: Warning - cannot read sector 164017 of /dev/vx/rdsk/newdg/vol02 DUMP: Warning - cannot read sector 164018 of /dev/vx/rdsk/newdg/vol02 |
To check this, follow the example below:
Run the command:
# fstyp -v /dev/vx/rdsk/newdg/vol02 | head -30 | grep ncg |
ncg 25 size 102400 blocks 95983 |
Next, find out the size of the volume. Run the command:
# vxprint -g newdg -vt vol02 |
V NAME USETYPE KSTATE STATE LENGTH READPOL PREFPLEX v vol02 fsgen ENABLED ACTIVE 163840 SELECT |
To resolve this problem, back up the data as best you can, then either create a new volume or newfs this one and restore the data.
This problem can also occur on a DiskSuite metadevice. The difference is that you need to check the size of the metadevice using the metastat command. The metastat command shows the size of the metadevice in sectors, just like the vxprint does.
The fsck(1M) command cannot open the disk device, because although a similar file system exists, the partition specified does not.
Run the mount(1M) or the format(1M) command to see what file systems are configured on the machine. Then run fsck(1M) again on an existing partition.
The fsck(1M) command cannot open the disk device, because the specified file system does not exist.
Run the mount(1M) or the format(1M) command to see what file systems are configured on the machine. Then run fsck(1M) again on an existing file system.
The user received this error while using no naming service. The services file looked fine. The user could FTP as root, but not as a normal user.
The permissions on the /etc/services file were wrong. To correct the problem, the user changed them to read access for everyone (644).
The FW-1 kernel module displays this error message when a new network interface has been added to the FW-1 system while fwd is running.
To resolve this problem, run the following to reinstall the FW kernel and the security policy:
# fw ctl uninstall # fw ctl install # fw fetch localhost |
The console reports FW1: Log message queue is full.
The message log is a queue that keeps all the firewall's event logs until FW-1 finishes processing them. If too many logs arrive, the buffer is full and the message FW-1: log message queue is full appears. It usually happens on loaded systems or firewalls that handle many network connections.
Below are some suggestions to stop this warning message:
Reduce the amount of logging in the security policy.
ACCOUNTING logging is very heavy. Reducing logging from LONG to SHORT also helps.
Increase the internal memory allocated to the FW kernel module. The default amount of memory is 524K. To increase to 1Mbyte, add the statement below to /etc/system and reboot:
set fw:fwhmem=0x100000 |
Set the Excessive Log Grace Period to 0. This is set through Properties -> Logging and Alerting. You must then reinstall the security policy for the change to take affect. The drawback for setting the Excessive Log Grace Period to 0: Your log now includes similar packets received at approximately the same time. When it was not zero, they were hidden (see Managing FireWall-1 Using the OpenLook GUI, p. 104). Thus, no packet disappears from the log, so your log might be a little bit bigger, but apart from that, no problem.
Use Renice fwd for a higher priority. The default priority of the FW daemon is 0 (like most processes). To raise the priority you must give a negative priority, depending on the load on your system. See the man page on nice(1) for more information.
Firewall-1 version 2.1 produces this message when the fwstart command is issued or when fwm is started from the command line.
There are two possible reasons for this:
When a firewall module is installed without a control station on the same machine, the messages are displayed on the console (under UNIX) or in the event log (under WinNT).
The messages might be legitimate. You might find that fwm has not started and you cannot do some crucial tasks. One possible problem: The license might be issued for the wrong host ID.
Make sure the license daemon is running on the server. Then, consider the following cases:
Case one: As a workaround, ignore the present messages and get an upgrade to 2.1c or above.
Case two: To check for a misassigned license, run the command hostid(1). Your hostid is displayed.
Next, run the command fw printlic to see output similar to the following:
This is FireWall-1 Version 2.1 Type Expiration Features id-649f152b never stdlight |
In Firewall-1, the connections encrypted with SKIP are dropped at certain times, specifically near the top of the hour. For example, connections will be dropped from 10:55 to 11:15, then continue working normally until 11:55. These error messages appear on the console in pairs:
fwskip_parse_headers: invalid peer n fw_skip_decrypt: cannot parse headers |
These error messages are referring to the n counter. The n counter is the absolute number of hours in GMT time. It is included in the SKIP calculations as a safeguard against a playback attack. If the 2 hosts or firewalls exchanging encrypted packets are not in sync with respect to GMT time, they have different n counters and these errors appear.
Keep the clocks on the encrypting hosts within one hour of each other, GMT time.