This chapter contains notes about issues and known problems with the base operating system and, whenever possible, provides solutions or workarounds to those problems.
The following topics are discussed:
The following notes apply to commands and utilities.
The
make
command will not recognize escaped comment symbols as
literal characters in a Makefile.
Comment lines that begin with a
#
(number sign)
and all text following
this symbol up to the end of
the line are considered part of a comment.
This is also true even if the symbol is preceded with a backslash
(\).
The following notes describe problems that may occur when using commands and utilities under certain security settings.
Programs cannot reliably inspect the permission bits in the
stat
structure and determine the access that will be granted to a particular
user. On local file systems, read-only mounts and Access Control Lists
(ACLs) can both modify
the access that will be allowed. On remote file systems, in addition to
read-only mounts and ACLs, there may be additional controls
that can alter the permitted access such as:
Programs that copy files to update them, rather than updating them in place,
often do not preserve ACLs. Some programs that have this problem are
gzip,
compress,
and
emacs.
The best solution for programs that need to make access decisions is for the
program to use the
access()
call to determine what access will be granted.
Note that even this may not work as the access protections of the file
could be changed between the
access()
call and the
read,
write,
or
execute
operation.
For programs that copy files, the following command will copy a file while preserving ACLs and any other extended attribute (property list):
#
cp -p
See the
acl(4)
and
proplist(4)
reference pages for more information.
The
pax,
tar,
and
cpio
archive tools might not restore ACLs on files in the manner you
think that they should be restored. Always check the ACLs on your
files after saving and restoring them with any of these tools.
By default, the Emacs editor will rename the original file and save the new file as a copy under the original name. If the original file had an Access Control List (ACL) it will now apply to the backup file. If the directory had a default ACL, the new file (original file name) will now have the default ACL instead of the original ACL. If the directory did not have a default ACL, the new file will be protected only by the file permission bits.
The Emacs editor has some user-preference variables that you can set to control which file will retain the original ACL. The relevant Emacs variables are:
backup-by-copying
backup-by-copying-when-mismatch
backup-by-copying-when-linked
Compaq ships the Emacs software as it is received from the source.
The following command line options do not work as documented in the
emacs(1)
reference page:
-cr,
-geometry,
-i,
-ib,
-iconic,
-iconname,
-in,
-internal borderwidth,
-mc,
-T,
and
-title.
In some cases, a workaround is available by using an appropriate X resource.
If Oracle8 running on Tru64 UNIX hangs, look for the following console message:
malloc_wait:X : no space in map.
If this message is present add the following to
/etc/sysconfigtab:
generic: kmem-percent=XXX
In this example,
XXX
is the size of the kernel malloc map. By default,
XXX
is set to 25 percent of physical memory. Increase this parameter to 50
and reboot the system. If Oracle8 continues to hang, increase this parameter
up to 100.
The output format of the
ipcs
command has been modified. The
KEY
field now presents the value in hexadecimal format instead of decimal.
This change is compatible with other UNIX implementations and conforms to the
upcoming X/Open UNIX 98 standard.
The following notes apply to
sendmail.
The
sendmail
program has been upgraded to Version 8.8.8 as the default version for
Tru64 UNIX. The current version, Version 5.65, is still available for use.
The new version, known as V8, has become the de facto standard in the industry,
especially for ISPs. Some of the features and enhancements provided with this
new version include masquerading, virtual domains, relay control, and spam
blocking. For more
information, see the sendmail book by O'Reilly and Associates, or the
sendmail Installation and Operations Guide,
or the
sendmail(8)
and
sendmail.cf(4)
reference pages. The
sendmail Installation and Operations Guide
is included in PDF format on the Supplementary Documents bookshelf of the
online Tru64 UNIX documentation.
You can configure
sendmail
using the
mailconfig
or
mailsetup
applications.
During an update installation, the system will attempt to update your existing
sendmail.cf
file to comply with this new version. This updated
sendmail.cf
is compatible with both new and old version of
sendmail.
To continue using the previous version of
sendmail,
invoke the following command as root:
/sbin/init.d/sendmail select old
This will change all links related to
sendmail
to point to the version previous to Version 8.0.
Once you are ready to use the new version, you can switch back by invoking the
following command:
/sbin/init.d/sendmail select v8.8.8
When the system is first booted, after a full installation,
the
sendmail
software is automatically configured. This takes a noticable amount of time,
and no status message is displayed until the following warning
message is displayed as a result of starting
sendmail:
warning: local host name(hostname) is not qualified; fix $j in config file.
This means the system does not have a qualified name. This is because neither
bind
nor
mail
has been configured. The
sendmail
program will continue to operate.
The
sendmail
program gives the following warning message when it is started and its
alias database is updated:
WARNING: writable directory /var/adm/sendmail
When
sendmail
initializes the alias database, it checks the modes on system directories and
files to determine if they have been compromised.
Because the permission on the
/var
directory is 775,
the
sendmail
program gives a warning message because it expects the permission on
/var
to be set as follows:
chmod go-w /var
When a user sends mail to
<user>@localhost,
the
sendmail
utility resolves it as
<user>@localhost.<domain name>.
As a result, if you do not have a system
localhost
in your domain, your mail will bounce back.
Instead of sending mail to
<user>@localhost,
send it to
<user>
only.
The
h
option to the
tar
command, which expands symbolic links to real files and
directories in the archive, does not work as documented. Do not use the
h
option. This problem will be fixed in a future release.
If you must use the
h
option, use the version of the
tar
command installed in
/usr/opt/obsolete
from the
OSFOBSOLETE440
optional subset.
The following notes apply to the Netscape Communicator.
Netscape Communicator dumps core when
the application posts a file selection dialog
(XmFileSelectionBox).
Typically, this occurs when you are running the application in the
Common Desktop Environment (CDE) and select the
Save As option in the File pulldown menu
of the Navigator browser. It can also occur
when you select a link to download a
file or save an attachment to a mail message
in the Messenger Mailbox component.
To avoid this problem, invoke Netscape using the
/usr/bin/X11/netscape
script.
As long as this script is used to start Netscape
Communicator, the application will display the
file selection dialog within CDE without core
dumping. Use the
-xrm '*nsMotifFSBCdeMode: True'
command-line option if you are starting Netscape
Communicator using some other means.
For more information, see the Communicator on UNIX release notes at the Netscape Web site:
http://home.netscape.com/eng/mozilla/4.0/relnotes/unix-4.0.html
Clicking on a
mailto:
HTML link in a web page displayed with Netscape Communicator's
Navigator web browser causes Communicator to core dump.
This is a known problem scheduled to be fixed in a future release.
The workaround is to start the Mailbox Messenger component from the Messenger
option in the Communicator pulldown menu before selecting the
mailto:
link.
Deleting multiple mail messages in Netscape Communicator's Messenger Mailbox component sometimes causes Communicator Version 4.5 to core dump. Usually, it requires several multiple deletions of mail to make Communicator core dump. If Communicator does not core dump immediately, deleted messages might reappear in the mail folder from which they were deleted.
Netscape Communicator intermittently dumps core and returns the following error in the terminal window from which it is started:
Memory Fault - (core dumped)
This core dump occurs with different hardware and software configurations and under different circumstances. Sometimes it hangs for a time, taking most of the CPU time, then it crashes. At other times, its process has to be killed and the application restarted. Numerous problems of this nature have been reported. None are resolved at this time and no workaround is available. In all cases, the behavior cannot be reproduced consistently.
After upgrading to Netscape Communicator Version 4.5 from a previous version of Communicator, an IMAP mail user cannot move messages to the Trash folder in the Messenger component. All Delete options in the user interface are insensitive (greyed-out). Setting the Move it to trash folder option in the IMAP mail server preferences window does not work. This behavior is the result of a new feature in Netscape Communicator Version 4.5 that might require user customization after upgrading to this version.
Starting with Netscape Communicator Version 4.5, the Namespace extension to the standard IMAP protocol is used to locate the users folders on the IMAP mail server. This feature will not work if you are using an older IMAP server that does not support the Namespace extension to the protocol. Use the following procedure to customize Netscape Communicator to be able to locate a user's Trash folder on an old IMAP server:
Namespace: "INBOX."
You should be able to move messages to the Trash folder and all the Delete options should now be sensitive (dark letters). Because IMAP mail server configurations differ (including the location of the user's folders on the server), check with your IMAP mail server administrator if the above procedure fails to resolve the problem.
When you select a link to a PostScript file in the Navigator component of Communicator, it might return the following error:
sh: /usr/bin/X11/showps: not found
The
showps
helper application has been retired from Tru64 UNIX as a result of
licensing changes to Adobe Display PostScript. The user may have customized the
PostScript Document MIME type to use the showps helper application in
$HOME/.mailcap
and
$HOME/.mime.types
files.
To resolve this problem, you must obtain a new PostScript viewer and reconfigure
the helper application for the PostScript Document MIME
type in Communicator. Use the Edit option in
the Edit-Preferences-Navigator-Applications
pulldown menu of Communicator to edit your PostScript Document helper
application and replace
/usr/bin/X11/showps
with the path to your new PostScript viewer.
Netscape Communicator crashes when scrolling Web pages in Navigator or when
editing bookmarks on a system with Open3D installed and a PowerStorm
4D5T graphics option after upgrading from Version 4.0D or later of the
operating system. In general, Communicator and some other applications
become unstable on this system configuration. The workaround is to set shells
DISPLAY
variable
to
local:0
before starting Netscape Communicator. Another option is to display Netscape
Communicator remotely from another system without Open3D installed on it.
Netscape Communicator Version 4.5 has a form handling problem when running under the Asian locales, such as Japanese or Chinese. The input data field is cleared after the data is submitted. Web applications that use the input field value might not work properly. A workaround is to start Communicator in C locale, for example:
%
setenv LANG C
%
netscape
Do not specify the current directory "." character as the location argument for
setld,
as shown in in the following example:
%
cd /mnt/ALPHA/BASE
%
setld -l .
Instead, use the directory path as the location argument, for example:
%
setld -l /mnt/ALPHA/BASE
The following sections apply to restrictions on using the SysMan applications.
The following notes apply to Account Manager,
dxaccounts.
When copying user accounts via cut and paste or drag and drop, the Allow Duplicate UIDs option in the General Preferences dialog box will be honored. For example, when making a copy of user account that has a UID of 200, if the Allow Duplicate UIDs check box is off (the default), the resulting copy will have a unique UID automatically generated. If the Allow Duplicate UIDs check box is on, then the copy will have an identical UID. The same rules apply to copying groups.
The Account Manager has the following restrictions on both base security and enhanced security (C2) systems:
Workaround: Delete the original icon after the copy has been completed.
Workaround: Use the
usermod
or
groupmod
commands to set a starting value within the range:
usermod -D -x next_uid=xxx
usermod -D -x next_gid=xxx
Suppose the minimum UID is 100 and the maximum UID is 10000. Then the following line would cause the Account Manager to start generating UIDs from 5000:
usermod -D -x next_uid=5000
johndoe
from 200 to 201, the files and subdirectories under his home directory
will still belong to UID 200. Furthermore, if
johndoe
does not own his home directory, the ownership of that directory will
not change either.
Workaround: Use the
chown
command to change the directory and files, if applicable.
Workaround: Use the copy/paste feature to copy users, groups, or templates from Account Manager A to B.
Workarounds: Account manager correctly allows two or
more system administrators to work on the same password files
simultaneously. The proper file locking will occur and
new accounts can be added or modified. However, the
local groups file,
/etc/group,
and the NIS groups file,
/var/yp/src/group,
are written out after each group modification.
Therefore, the last system administrator to make a change
in a group's view window would overwrite any prior changes
from a different system administrator. For this reason,
running multiple, concurrent Account Manager
instances is not recommended.
Warning: DtComboBoxWidget: Unable to find item to select
Workaround: None. You can safely ignore these messages.
Leading and trailing white space is not stripped from text entry areas. This could lead to confusion, for example, if a field on the Find dialog box contains a space character before the desired search string. The search string would not match because of the spurious space character.
The following problems apply to Account Manager when running on enhanced security systems:
Workaround: Change the template lock setting on the Create/Modify Template dialog screen after selecting the template by double clicking on the template icon in the Template view icon box.
Workaround: Set passwords through
/usr/tcb/bin/dxchpwd
or the
/usr/bin/passwd
command when the C1Crypt
Encryption type is chosen.
Workaround: Set the C1Crypt Encryption type for the user from the Create/Modify User dialog.
Workaround: Set passwords through
/usr/tcb/bin/dxchpwd
or
the
/usr/bin/passwd
command if the
minimum/maximum password length limitation is
necessary.
Workaround: To delete a user account you must do the following:
/etc/passwd
and
/etc/group
files
to remove references to the user.
#
/usr/tcb/bin/edauth -r <user name>
Workaround: Use the following command to remove the dangling protected password database entry:
#
/usr/tcb/bin/edauth -r <user name>
Workaround: Restart Account Manager to restore the former template icon. Use the Delete Toolbar icon or the Edit->Delete... option from the Template view to delete the undesired template
Workaround: Modify the copied user's account and change the template from the default to the desired template. Note that the template reference is maintained if the user is dropped within the same view.
Workaround: Only the drag and drop method of template assignment has this problem. You can use the Create/Modify dialog box to change a single user's template or use the Modify Selected dialog box to change templates for several selected users. Both methods correctly propagate the template's lock field.
template %2
instead of the template's name.
Workaround: None.
Workaround: Restart Account Manager and then delete the template.
Workaround: Manually remake the NIS maps or perform an Account Manager function (for example, Account Modification) that will trigger the maps to be remade. To manually remake the maps do the following:
#
cd /var/yp
#
make all
The following problems apply to configuring BIND servers with the BIND configuration graphical user interface.
Workaround: Edit the
/etc/namedb/named.boot
file to remove the zone entry that needs to be deleted.
Workaround: If the Forwarder is not needed, you can edit the
/etc/namedb/named.boot
file to remove the Forwarder entry after you Commit to the
setup in the BIND configuration interface.
/etc/namedb/named.boot
file will be deleted if the Zones
button is not clicked first.
Workaround: Whenever you modify your BIND setup using the BIND configuration interface, click on the Zones button before you Commit to any changes.
Workaround: The address can be modified by editing the secondary
domain entry in the
/etc/namedb/named.boot
file.
The
dxshutdown
application does not create the
/etc/nologin
file as described in the documentation.
This means that users will be able to log in to a machine
that is being shut down up until the actual time of the shut down.
Note that this behavior differs from that of the
shutdown
command that creates the
/etc/nologin
file at 5 minutes prior to the shutdown.
The following notes apply to system administration.
Certain software license PAKs include expiration dates that currently limit the ability to run software when the date is set well into the future (into the year 2000). While most customers do not have PAKs with expiration dates, those who do (such as CSLG, ASAP, or Partner PAK Program members) may benefit from the following enhancements.
The
lmf
utility and supporting code have been enhanced to allow customers with
expiring software license PAKs to set the system date beyond the
expiration dates within a specific time window to allow Year 2000
(Y2K) testing.
Also, a test PAK,
00Y2K-TESTING,
is available for use with Version 4.0D and higher of the operating
system. If
you have expiring license PAKs, you can install this test PAK,
allowing your PAKs to operate beyond their expiration dates between
the dates of December 1, 1999 and March 2, 2000. The test PAK allows
you to conduct Y2K testing within the specified time window.
For information about obtaining the
00Y2K-TESTING
PAK and other Y2K issues, see the
Tru64 UNIX Year 2000 Readiness
white paper, available in HTML format on the
Tru64 UNIX 4.0F Documentation, Volume 1
CD-ROM. This document is also available on the Tru64 UNIX
web page at the following URL:
http://www.unix.digital.com/unix/year2000/whitepaper.html
Once you obtain and install the
00Y2K-TESTING
PAK and set the system date forward for Y2K testing,
you must execute the following command from the root account the first
time run level 3 (also referred to as "init 3" or "multiuser mode")
is entered after each system boot:
#
/usr/sbin/lmf reset
This will ensure that all software licenses are loaded while the system date is set within the Y2K testing window. You need to execute this command only once within run level 3 between each system boot. You can toggle the system between run level 1 and run level 3 after the first execution of the command in run level 3. You will only be required to execute the command again after rebooting the system.
For Tru64 UNIX Version 4.0F and its software supplements, the supported version of the EISA Configuration Utility (ECU) is Version 1.10 or higher. If your system is configured with an EISA bus, you should update the ECU to this supported version.
Consult the Open3D Software Product Description (SPD) before installing Open3D to ensure that this layered product is supported on your system.
Installing Open3D on systems not supported by the Open3D layered product can leave your system in an unusable state.
The behavior of the
open
call to a tape device has changed. You can no longer use
write
mode to open a write protected tape. The attempt to open the tape
will fail, returning the following message:
EACCES (permission denied).
If an application is written so that it attempts to
open the tape device with
O_RDWR
when the intention is only to read
the tape, the open attempt will fail. Applications should be changed to open the
device with
O_RDONLY.
For applications that cannot be changed, use the
following command to obtain the previous behaviour of the open call:
#
sysconfig -r cam_tape open_behaviour=0
The Tru64 UNIX Server Extensions includes
Dataless Management Services (DMS)
support for installing and
operating systems in a dataless configuration. A server system maintains
the
root,
/usr,
and
/var
file systems for all client systems. The server maintains one copy of root
for each client. The
/usr
file system is exported read-only and is shared by all clients registered to the
environment. Each client has their own
/var
file system. Dataless clients access the file systems maintained on the
server utilizing NFS.
A dataless environment should be considered in the following scenarios:
root,
usr
and
var
file systems are resident on the server.
You should consider the following limitations when deciding to implement a dataless environment:
/usr
file system and all client
specific data is contained in a
/clients
file system on the server. As
clients are added to the dataless environment, the demands on these file
systems on the server increase and may surpass the capabilities of the
server.
During an alternate root installation of base operating system subsets, such as
is done using the
dmu
utility to set up a Dataless Management
Services environment, the file access dates on some of the files in the host
server's file system may be changed to correspond to those from the subset's
file inventory. When the release installed into the alternate root is
different from that installed on the host system, these changed dates appear
invalid since they may be newer (or older) than the actual file dates from the
host system's installation kit.
This occurs when the
pax
utility is invoked by the
setld
utility to copy symbolic links from the kit subsets, and the
symbolic links target absolute paths that correspond to actual files in the
host system's file system. The
pax
utility attempts to adjust the dates for the symbolic
link, but the file system actually adjusts the dates for the target of
the symbolic link.
The changed dates have no operational impact on the host system. The content
of the affected files has not been changed. However, because the dates have
changed, the behavior of utilities that examine file dates (such as the
find
command or archivers) may be affected.
The following notes apply to the use of enhanced security features.
The following restrictions apply to distributing enhanced security profiles via NIS:
rpc.yppasswdd
daemon must respond and update the last successful and last
unsuccessful login fields in the
prpasswd
NIS map.
yppush
operation initiated from the
rpc.yppasswdd
daemon. (Most successful logins do not require a
yppush
operation, but login failures and password changes do.)
The login process will not continue or terminate until both of these steps are completed.
The more NIS slave servers that are present in a given NIS domain, the
more time
rpc.yppasswdd
takes to complete these steps. Also, nearly-simultaneous login
attempts are processed sequentially by the NIS master, each waiting on
a possible
yppush
for the previous attempt to succeed. Therefore, if several
simultaneous attempts arrive at once, some may timeout and require you
to log in again. You can alleviate this problem to some extent by
using the
-p
option of
yppush.
One way to do this is to modify the
/var/yp/Makefile
file and change the
YPPUSH=
line. The following example allows up to 6 simultaneous transfers to
NIS slave servers (the default number is 4):
YPPUSH=$(YPDIR)/yppush -p 6
prpasswd
map, the more likely the time limit is to expire during a login
attempt, causing that attempt to fail. Simultaneous or
nearly-simultaneous login attempts will fail if the NIS master server
does not respond quickly enough to the pending login processes. If the
total time taken on the NIS master for the following commands exceeds
25 seconds, then there will be circumstances under which only one user
will succeed in logging in at a time:
#
cd /var/yp
#
make passwd prpasswd PRPWDPUSHONLY=1 NOPUSH='"'
You can decrease the time required for map transfers if you use the
btree
format to store the maps on all of your NIS servers.
With successful logins, the
rpc.yppasswdd
daemon will defer pushing the maps if the login notification comes
from a Version 4.0D client. Therefore, the
yppush
operation is only completed when an older client initiates the
operation or when it is necessary to clear a failed login count.
prpasswd
information may be able to use NFS to share the
/tcb/files
and
/var/tcb/files
directories instead. This requires you to export the directories with
root access to the participating nodes (with
-root=0
or
-root=client1:client2:client3
as appropriate). It also requires you to enable NFS locking to ensure
that no database corruption occurs. For more information, see the
exports(4)
reference page.
In previous releases of the operating system, NIS slaves that were listed in
the
ypservers
NIS map on the NIS master but that did not already have a copy of the
prpasswd
and
prpasswd_nonsecure
NIS maps may not have succeeded in transferring those maps during the
yppush
operation. This problem has been fixed for Version 4.0D and higher.
Because the user profile and
tty
information is now stored in database files, the previous recovery
method of editing the files while in single-user mode is no longer
available. However, as long as the
/usr
(and, if separate,
/var)
file systems are mounted, you can use the
edauth
utility in single-user mode
to edit extended profiles and ttys database entries.
If the
/etc/passwd
file is somehow lost, but the extended profiles are still available,
then you can use a command sequence as in the following example to
recover some of the missing data (the "\" characters indicate line
continuation):
#
bcheckrc
#
/tcb/bin/convuser -dn | /usr/bin/xargs /tcb/bin/edauth -g | \ sed '/:u_id#/!d;s/.*:u_name=//;s/:u_id#/:*:/;s/:u_.*$/:/' \ >psw.missing
This will create a
psw.missing
file containing entries like the following:
root:*:0:
Primary group information, finger information, home directory, and login shell are not recorded in the extended profile. You must recover the data for those fields by other means.
The Enhanced Security routines
pw_idtoname,
pw_nametoid,
gr_idtoname,
and
gr_nametoid
(described in
pw_mapping(3))
previously used the
/etc/auth/system/pw_id_map
and
/etc/auth/system/gr_id_map
files to find the required information for mapping names to numeric
identifiers, and vice versa. The disk space required by those files
imposed a limit on how many accounts a system could support.
The Enhanced Security routines no longer use the
pw_id_map
and
gr_id_map
files. If you are running Tru64 UNIX Version 4.0D or later and
still have those files, it is recommended that you remove them to
recover the space occupied on the
root
paritition.
The
useradd
command correctly honors the default administrative
lock value found in the
/.sysman/Account_defaults file.
If
Account_defaults
does not exist, the internal default for
useradd
is to create locked accounts. Use the
administrative_lock_applied
extended command line option to override the default. In the
following example,
useradd
creates a locked account for
foo
regardless of the default value for administrative lock:
useradd -x administrative_lock_applied=1 foo
For base security, a locked account has the text
Nologin
in the password field in the
/etc/passwd
file. If an account is unlocked and has no password, that account has
no value in the password field. The account is open and accessible to
anyone. A warning is displayed if an unlocked account with no
password is created.
For enhanced security, all accounts have an asterisk
(*)
in the password field in
/etc/passwd,
but the lock flag in the protected password database is correctly
set to reflect the lock status. As with base security, an unlocked
account with no password is accessible to anyone.
The
usermod
command correctly sets the lock flags for enhanced security when the
administrative_lock_applied
option is given on the command line. If
usermod
is used to unlock a locked account with no password, a warning is
displayed.
The
userdel
command will retire, instead of remove, accounts on a system running
enhanced security.
By default, extended UIDs are not enabled in the kernel. To enable this
feature, use
sysconfig
or the
dxkerneltuner
interface to set the value of the variable
enable_extended_uids
to
1
(enabled).
If you choose to do this, please note the following:
enable_extended_uids
can be set dynamically, you cannot disable it dynamically.
To disable
enable_extended_uids,
set the boot time value to
0
(disabled) and reboot your system.
Insight Manager Agents for Tru64 UNIX include SNMP-based subagents and Web Based Enterprise Management (WBEM) capabilities to present SNMP data in a format viewable by a Web browser. It provides a rich view of the data using HTML 2.0 and JavaScript in the form of Web pages.
Insight Manager is installed automatically
when you install the operating system's mandatory subsets.
They are
OSFCLINET440,
which includes the Compaq Mibs and SNMP subagent,
and
OSFIMXE440,
which includes the Insight Manager subagents.
For further information on these subsets, see the
Installation Guide.
The Insight Manager daemons are started as part of the
init 3
startup process. The Compaq SNMP subagent (
/usr/sbin/cpq_mibs)
is initialized and started or stopped as part of the
snmpd
startup script:
#
/sbin/init.d/snmpd start
or
#
/sbin/init.d/snmpd stop
The WBEM daemon is started and stopped from a new script called
insightd:
#
/sbin/init.d/insightd start
or
#
/sbin/init.d/insightd stop
The Compaq Insight Manager Agents provide access to device management data over the industry-standard HTTP protocol. This lets you view management data from a Web browser, either locally or remotely.
Use the following URL to view data locally:
http://127.0.0.1:2301/
Use this URL if localhost is configured:
http://localhost:2301/
Use this URL to view data remotely:
http://machine:2301/
In this example,
machine
is the IP address or host name under DNS.
The Insight Manager Device home page provides a single service icon entry called Compaq Insight Management Agents. Clicking on this icon displays the device pages of the target system. The home page also presents three hyperlinks:
The Options link provides various Agent configuration options.
The Devices link provides auto-discovery of other Insight Manager Agents and Insight Manager XE Servers running on the local network, allowing direct access to their 2301 ports.
The Compaq Insight Manager Agents page consists of three frames, as follows.
The upper left frame displays a conditions legend and the following links:
| Menu Item | Description |
| Agent Help | Use this link for online help. |
| Summary | Use this link to navigate back to the Summary Page. |
| Device Home | Use this link to return to the Device home page. |
| Options | Use this link to navigate to the Options Page and set options for Display Mode, Help Icons, and AutoRefresh intervals. |
The lower left frame is a navigational frame that provides links to various system components grouped under Configuration, Mass Storage, NIC (Networking), Utilization, and Recovery. Clicking on the system component links displays component-specific data in the main pane window.
Not all the components are instrumented in this first release of the Insight Manager Agents; more will be made available in future releases. The following table shows data availability in Tru64 UNIX Version 4.0F.
| Configuration | |||
| System Info | Yes | ||
| System Board | Yes | ||
| Software Version Info | N/A | ||
| Mass Storage | |||
| File System Space Usage | Yes | ||
| Diskette Drives | Yes | ||
| SCSI Controllers | Yes | ||
| Device Information | Yes | ||
| Device Statistics | N/A | ||
| Bus Information | N/A | ||
| NIC | |||
| Virtual NIC | N/A | ||
| Network Controllers | N/A | ||
| Utilization | |||
| File System Utilization | Yes | ||
| Recovery | |||
| Reboot | N/A | ||
| Power On Messages | N/A | ||
| Environment | N/A | ||
| Power Supply | N/A |
Note
CPU Cache and Memory module information are available only in AlphaServers supporting FRU V4 configuration tables, specifically: AlphaServers 1000, 1200, 4100, and 8400.
The minimum browser requirements include support for tables, frames, Java, JavaScript, and the Java Development Kit (JDK) 1.1. Additional browsers, or the browsers mentioned, used with different operating systems, might not work correctly, depending upon their specific implementations of the required browser technologies.
The requirements are TCP/IP and one of the following browsers:
| Operating System | Browser Requirements |
| Windows 95/98 or NT Version 3.51/4.0 |
Microsoft Internet Explorer 4.0
Version 4.72.2106.8 or above
Netscape Navigator Version 4.04 or above |
| Tru64 UNIX Version 4.0F and higher | Netscape Communicator 4.5 or higher |
| DIGITAL UNIX Version 3.2C and higher | Netscape Communicator 4.06 or higher |
Important: You must turn on the following options so that the Server Agents work properly:
Enable Java Enable JavaScript Accept all cookies or Accept cookies originating from the same server as the page being viewed
In this release, you can access anonymously the device web page without logging in. If needed, the Insight Manager administrator can set user privileges.
There are only three predefined users (user, operator, and administrator) and passwords.
There are three types of data: Default (read only), Sets (read/write),
and Reboot (read/write). The
WEBAGENT.INI
configuration file specifies the level of user that has access to data.
Refer to the Agent Help link in the online help for further information on setting security and on the default user, operator, and adminsitrator passwords.
To change the default passwords:
Login Account: anonymous.
The Account Login page is displayed.
changed
link in the text:
The Password for a login account may be changed at any time by an Account Administrator.
Another Account Login page is displayed. This page gives the appropriate instructions.
In this release, the Web-enabled Compaq Server Management Agents do not provide SNMP sets for system parameters, or reboot capability.
In Tru64 UNIX, the user access configuration file is located in
/usr/share/sysman/web/im/webagent/WEBAGENT.INI.
In a dataless environment, you will need
to copy that file to the local directory
/var/im/webagent
if you need to change its configuration setting.
The following problems exist in current version of the Insight Manager:
http://machine:2301),
this version of Insight Manager does
not generate traps. Thus, alerts are not generated.
http://machine:2301/cpqdev.htm)
may show inconsistent
or incorrect data on some platforms, as active discovery
is not fully functional.
blocksize
* 1,000,000.
This will be changed to the defined calculation
of
blocksize
* 1,048,576 in a future release.
cpq_mibs
daemon will fail to initialize on this platform. This problem will be fixed
in the first available patch kit.
On systems which display a large number of console messages at system
initialization (typically, systems configured with a large number of
devices), some of the messages may be missing from the
/var/adm/messages
file. This problem can be corrected by increasing the size of the kernel's
message buffer.
Use either of the following procedures to change the buffer size. You must
be
root
to make the change.
To change the buffer size using graphical administration tools, use the following steps:
dxkerneltuner
application.
generic
subsystem.
msgbuf_size
attribute to the new value.
To change the buffer size from the command line, use the following steps:
/tmp/msgbufsize,
containing the following lines, but replacing the 32768 with the size
appropriate to your system:
generic: msgbuf_size = 32768
%
sysconfigdb -f /tmp/msgbufsize -m
If a different entry was already present in the database,
sysconfigdb
will display a warning message to advise you of the change in size.
The increase will take effect at the next system reboot. After rebooting, you can verify the change by entering the following command:
%
sysconfig -q generic | grep msgbuf_size
Note
The default size of the message buffer is 4 KB, and the example above sets it to 32 KB. Since the space used by the buffer is not returned for general use after initialization, you should set the size only high enough to correct the problem.
A print job to a Version 4.0F system (from any other version of Tru64 UNIX) might cause the print queue on the receiving system to become disabled.
This occurs when the lock file is not present in the spool directory for the queue when the remote host receives the job. This condition exists if the print queue was newly created, or if the contents of the spool directory were manually purged (which would delete the lock file).
When a remote job is received, the print daemon creates a lock file
with a protection mode that signifies that the queue is
disabled. The initial job completes, but any subsequent jobs submitted to
the same queue do not print because the queue is in the disabled state.
When the queue is disabled by this condition, the protection modes on the
spool directory lock file are displayed by the
ls -l
command as:
-rwxr-xr--
Normally the lock file should have these protection modes set:
-rw-r--r--
To restart the queue, enter the
lpc up
queuename
command, to clear the disabled condition and restart the queue.
To avoid the problem, create the lock file by submitting any job on the local host to the queue, or by entering the following command:
#
touch
spooldirpath
lock
The
lpstat
command fails if the
PRINTER
environment variable is not set and the command is issued with the
following syntax:
#
lpstat -u
username
The command fails with the following message:
lpstat: lp: unknown printer
If the
PRINTER
variable is set, the command returns queue information for the
queue specified by
PRINTER.
The Disk Configuration application creates the correct
ls /dev/alias
files. It should also show
the
alias
in the Alias Name: field in the Disk Configuration: Configure
Partitions box after naming it in the previous session, but it does not.
Use the
ls /dev/alias[a - h]
command to verify and use the disk alias.
The preliminary support for the native DVD file system in
Version 4.0F, called DVDFS, is not fully functional. Attempts to invoke
the DVDFS file system result in an error message of
function not supported.
When mounting DVD media that contains an ISO-9660 directory structure (which
may be present on DVD-ROM disks formatted according to ECMA-167 that include
the bridge format), any attempts to mount specifying
-t dvdfs
will use the CDFS file system (
-t cdfs)
automatically. When the on-disk format does not contain an ISO-9660 directory
structure, this mount will fail. Only DVD-ROM disks that include an
ISO-9660 directory structure are supported in Version 4.0F.
For both CD-ROM media and DVD-ROM media that contains an ISO-9660 directory
structure, Compaq recommends use of the
-t cdfs
option, as well as the
-o noversion
or
-o rrip
option where appropriate.
Refer to
mount(8)
for a description of these options.
The following notes apply to network and communications software.
The following restrictions apply when using IP switching over ATM:
atmsig
command to start UNI signaling on a driver used for IP switching.
/etc/atm.conf
file,
and not through the
atmsetup
utility.
In Version 4.0F, many syslog messages for routine ATM events are not displayed by default. The messages which show the duration of virtual connections (VC accounting messages) must be explicitly enabled.
The general verbosity of ATM messages can be controlled by setting the
global_message_level
parameter associated with the
atm
module in the
sysconfigtab
file. For example:
sysconfig -r atm global_message_level=2
Values for this parameter are:
Message levels can be set for individual ATM components to tailor the amount
of information displayed. Refer to
sys_attrs_atm(5)
for more information.
In Tru64 UNIX Version 4.0F, once you configure your interfaces using
netsetup,
view the
/etc/hosts
file and make sure that the hostname and the IP address of your system has been
added to this file. If not, then you need to add this information in the
/etc/hosts
file. Edit the
/etc/hosts
file as a root, and add the following line:
<system's ip address> <system's hostname> <any aliases for the system>
Example:
16.60.266.6 example.domain.com example example-alias2
where:
16.60.266.6
= IP address of your system.
example.domain.com
= fully qualified hostname of your system.
example,
example-alias2
= aliases for your system.
Refer to the
hosts(4)
reference page for further information regarding the
/etc/hosts
file.
The Common Desktop Environment (CDE) provides facilities and features for applications to communicate in a networked environment. After the network is configured and enabled, these features become available each time a new desktop session is started. After a desktop session has started, the current session has a static dependency on the state of the network configuration. Network and system administrators should be very cautious about dynamic changes to the network configuration while in a network-aware desktop session.
Prior to making any dynamic network changes, such as
changing the state of your network adapter to off or
changing your primary network address, add the following entry to the
/.dtprofile
file:
export DTNONETWORK=true
The system administrator must then log out and back in as root for the change to take effect. This change removes the dependency on the state of the network. Failure to do this may result in a session hanging after clicking on a CDE icon, such as the screen lock or Exit icons.
After all network changes are completed, remove the
export DTNONETWORK=true
entry from the
/.dtprofile
file.
Tru64 UNIX now provides support for detecting the physical loss of network connectivity, and subsequent automatic switchover to a working network interface. This feature is called Redundant Array of Independent Network adapters (NetRAIN).
NetRAIN uses two or more network interfaces to provide redundancy. Although only one interface at a time is actually used for communication, all interfaces are monitored to ensure that traffic is flowing on each. If the interface currently being used should suffer a loss of connectivity, NetRAIN will switch network traffic to the next working interface. All the context of the previous interface is maintained: hardware address, multicast addresses, and so on.
NetRAIN is configured through extensions to the
ifconfig
command. It also features a programming
interface via
ioctl()
for manual program control.
NetRAIN supports the following network adapters:
TruCluster Software users should consult the Software Product Descriptions (SPDs) for TruCluster Software for a list of network interfaces supported by that product.
For more details about NetRAIN, see the
Network Administration
guide and the
nr(7)
and
ifconfig(8)
reference pages.
The method for configuring a NetRAIN interface will be improved in a future release of the operating system. If you configure a NetRAIN set in Version 4.0F, or did so in a previous releases of the operating system, you will need migrate your set to the new configuration at that time.
If you configure a NetRAIN set in the
inet.local
file as documented in the
Network Administration
guide, and the NetRAIN interface is the
only network interface configured on your system, network services
will fail to start automatically at boot time. To work around this
problem, configure your NetRAIN interface in the
rc.config
file as follows:
ifconfig
line in the
inet.local
file that starts the NetRAIN interface. It should look
similar to the following:
ifconfig nr0 18.240.32.40 netmask 255.255.255.0 add fta0,fta1
#
rcmgr set NETDEV_0 nr0
ifconfig
parameters that are used to initialize the NetRAIN interface
(the "\" character indicates line continuation):
#
rcmgr set IFCONFIG_0 nr0 18.240.32.40 netmask \
255.255.255.0 add fta0,fta1
#
rcmgr set NUM_NETCONFIG=1
Note that network services will not start if
NUM_NETCONFIG
is set to 0.
If you need to deconfigure the interface for any reason, use the
rcmgr
utility to delete the appropriate
NETDEV_0
and
IFCONFIG_0
entries and update the
NUM_NETCONFIG
variable to 0. Then reboot your system. See the
rcmgr(8)
reference page for more information.
If you plan to add a non-NetRAIN interface to your system in
the future, you will need to deconfigure the NetRAIN set in the
rc.config
file and reconfigure it in the
inet.local
file as documented in the
Network Administration
guide. If you do not make this change
before adding the new interface, the Common Desktop Environment (CDE)
Network Configuration application
(
netconfig)
and the
netsetup
utility might yield unpredicable results.
This problem will be addressed in a future release of the operating system. If you configure a NetRAIN set, you will need to migrate your set to a new configuration at that time.
By default, the
latsetup
utility attempts to configure LAT for
operation over all network interfaces on a system.
If you have configured a NetRAIN virtual interface on your system, and
the
latsetup
utility attempts to run LAT over any of the physical
network adapters that comprise the NetRAIN set, the
latstartup
command will hang.
To prevent this problem, configure LAT to run over specific network interfaces on the system as documented in Section 5.7 of the Network Administration guide. Run LAT over an interface that is not part of the NetRAIN set.
While using the default NetRAIN settings on a Tru64 UNIX server, Microsoft Windows NT clients reset their TCP/IP connections before the server is able to complete the failover to another interface. There are two possible solutions:
TcpTimedWaitDelay
and
TcpMaxDataRetransmissions
NT TCP parameters as follows:
TcpTimedWaitDelay= 30//The maximum retransmission timer. TcpMaxDataRetransmissions=20//The maximum number of retransmissions.
nr_max_retries
and
netrain_timeout
kernel attributes using the
sysconfig -r
command or
dxkerneltuner.
For example, you can set the attributes as follows:
nr_max_retries=1 //The default is 4 netrain_timeout=100 //The default is 1000
Alternatively, you can set the
nrmaxretry
and
nrtmoisr
values, respectively, when you issue the
ifconfig
command to create the NetRAIN set.
See
sys_attrs_netrain(5)
and
ifconfig(8)
for information on NetRAIN parameters.
Regardless of the solution you choose, if the host system's network interface cards (NICs) are connected to a layer 2 switch or bridge that is running a Spanning Tree algorithm, the Spanning Tree configuration parameters on the switch/bridge might dictate the failover time. In this case, the actual behavior of the TCP retry might depend on the switch implementation and configuration. See the documentation accompanying the switch/bridge for information.
Tru64 UNIX Version 4.0F includes a new version of the
sendmail
application, which includes the ability to specify an owner for
a mail alias, which can cause
the identity of the sender on the mailer command line to be different
from the identity of the sender in the From: header line. The end
result is that the recipient of the mail might see the wrong address identified
as the sender of the message.
If this problem occurs, the corrective action is to create a file,
/var/dna/defaults/Dnetrc.defaults,
containing the following lines:
mail11.SenderFromHeader: on mail11.FromLineToUse: From
The
Dnetrc.defaults
file is a configuration file read by the
mail11 mailer. The specified options tell mail11
to take the sender id from
the header lines, and specifically to get it from the From: line.
After you create the
Dnetrc.defaults
file, obtain the latest version of
mail11v3
and replace the current
version in the
/usr/sbin
directory. The
mail11v3
mailer understands the option specified and uses the appropriate sender id.
Starting with Tru64 UNIX Version 4.0F, DHCP database files are stored in
an entirely new format that is incompatible with older formats. The operating
system ships with an online document, provided by JOIN Systems, that
explains the reasons behind this change, lists the files that are affected,
and provides instructions for converting the files to the new format.
The document and conversion utility,
README-DB237
and
conv185-237,
respectively, are located in the
/etc/join
directory.
Tru64 UNIX Version 4.0F includes support for the TCP Selective Acknowledgment Options (SACK) as well as the TCP Timestamp and PAWS (Protect Against Wrapped Sequence Numbers) options. These TCP options can help improve TCP performance over unreliable networks. RFC 2018 TCP Selective Acknowledgment Options describes the SACK options. RFC 1323 TCP Extensions for High Performance describes both the Timestamp and PAWS option.
Tru64 UNIX Version 4.0F provides latent support for a single system to have multiple network adapters in the same subnet; for example, tu0 configured with IP address 192.24.156.20 and tu1 configured with IP address 192.24.156.21, both with the same netmask. Previous versions require each network adapter to be in a separate physical subnet.
On connection establishment, the kernel chooses the interface that has the fewest number of connections. This connection-balancing effect could lead to greater throughput than on a system with just one network adapter per subnet.
You should use this feature only if both of the following configuration situations are true:
The feature might affect the operation of network software or, for example:
traceroute
might give varied output, since the interface used might change from packet
to packet.
To enable this feature, you must use
dbx
on the kernel and set the
routemode
variable to 1. You must patch the kernel for this to persist accross a
reboot, for example:
#
dbx -k /vmunix /dev/mem
(dbx) assign routemode=1 (to set) (dbx) patch routemode=1 (to patch)
The dependence on this kernel variable will be removed, and the behavior of this feature may change in a future release.
For more details about
dbx,
see the
Kernel Debugging
guide and the
Programmer's Guide.
For more details about adding and viewing routes, see the
route(8)
and
netstat(1)
reference pages, respectively.
The following notes apply to Local Area Transport (LAT).
The
latsetup
utility sometimes creates devices with duplicate minor numbers.
If you manually create LAT BSD devices that do not match the valid BSD
tty
name space convention,
latsetup
can create devices with duplicate minor
numbers. For example, creating device
tty0
with a minor number 2 instead of 1 can cause this problem.
When a CTRL/A character is typed during a LAT tty session, all lowercase characters are converted to uppercase. Another CTRL/A changes the mode back to normal.
When doing a number of simultaneous
llogin
connections, you should use
llogin
with the
-p
option. To speed up an
llogin
connection, add the target host name as a reserved service.
See Section 4.4.8 for information on LAT interactions with NetRAIN.
The notes in this section apply to file systems.
Starting with Version 4.0D, the
newfs
command no longer searches the
/etc/disktab
file for hard disk geometry information. It now performs an
ioctl GETDEVGEOM
call to determine the characteristics of a disk.
For an NFS client to make direct use of ACLs or extended attributes
(property lists) over NFS,
you must be enable the
proplistd
daemon on an NFS server. You also must use the
proplist
mount option when mounting on the client. Access checks are enforced
by the server in any case, although NFSv2 client caching could
sometimes cause inappropriate read access to be granted. Correctly
implemented NFSv3 clients make the necessary access checks.
Start the
proplistd
daemon by selecting the number of
proplist
daemons to run when you use the
nfssetup
utility. You can also use the
proplistd
command to start the daemon manually:
#
/usr/sbin/proplistd 4
On the client, the file system must be mounted with the
proplist
option by either of the following methods:
proplist
to the options field in the
/etc/fstab
file:
sware1:/advfs /nfs_advfs nfs rw,proplist 0 0
#
mount -o proplist sware1:/advfs /nfs_advfs
See the
acl(4),
fstab(4),
proplist(4),
mount(8),
nfssetup(8),
and
proplistd(8)
reference pages for more information. Note that the
proplist
option is not documented in
mount(8).
On AdvFS file systems there is a hard limit of 1560
bytes for a property list entry. Since Access Control Lists (ACLs)
are stored in property list entries, this equates to 62 ACL
entries in addition to the three required ACL entries. The
EINVAL
error is returned if you attempt to exceed this limit.
To facilitate interoperation of the UFS and AdvFS ACLs, a
configurable limit has been imposed on UFS ACLs. The default
value of the UFS limit is 1548 bytes, equivalent to the 65-entry
limit on AdvFS. The UFS configurable limit on ACLs has been
added to the
sec
subsystem and has been given the attribute name
ufs-sec-proplist-max-entry.
You can use the
sysconfig
utility to dynamically configure the attribute or you can use
sysconfigdb
or
dxkerneltuner
to statically configure the attribute in the
/etc/sysconfigtab
file.
A configurable property list element size for UFS has also been added
to the
sec
subsystem and has been given the attribute name
ufs-proplist-max-entry.
The value of
ufs-proplist-max-entry
must be larger than
ufs-sec-proplist-max-entry
by enough space to hold a property list element header. The
sysconfig
utility adjusts the
ufs-proplist-max-entry
attribute automatically. The default value of
ufs-proplist-max-entry
is 8192 bytes.
See the
cfgmgr(8),
seconfig(8),
seconfigdb(8),
sysconfig(8),
and
sysconfigdb(8)
reference pages for more information.
The following notes discuss features, problems, and restrictions of the Advanced File System (AdvFS).
You can use the
fsync()
system call to synchronously write dirty file data to
disk. There are two ways a file can have dirty data in memory. One way
is via the
write()
system call. The other is from a memory write reference after an
mmap()
system call. For AdvFS files, the
fsync()
system call writes out dirty data only from the
write()
system call.
If dirty data from an
mmap()
also needs to be written then you must also use the
msync()
system call.
You can reuse a partition that was previously part of an AdvFS domain.
However, before you reuse the partition, you must remove the domain on the
partition you want to reuse. Use the
rmfdmn
command to remove the entire domain. After the unused domain is
removed, you can create a new domain on the partition.
Under certain conditions, the disk usage information on an AdvFS file system
may become corrupted. To correct this, turn on quotas in the
/etc/fstab
file for the affected file system, and then run the
quotacheck
command on the file system. This should correct the disk usage
information.
If a system crashes or goes down unexpectedly due to a loss of power or other similar circumstances, AdvFS will perform recovery the next time that the filesets that were mounted at the time of the crash are remounted after rebooting. This recovery keeps the AdvFS metadata consistent and makes use of the AdvFS log file.
Different versions of the operating system use different AdvFS log record types. Therefore, it is important that AdvFS recovery be done on the same version of the operating system that was running at the time of the crash. For example, if your system is running Version 4.0F and the system crashes, do not reboot using Version 3.2G since that version of AdvFS may not be able to work with the log records that the Version 4.0F system put into the log.
Therefore, if you want to reboot using a different version of the operating system,
make sure that any mounted AdvFS filesets are unmounted cleanly
before rebooting. In addition, if the system panicked or an
AdvFS domain was domain-panicked, it is best to reboot using the
original version of the operating system and run the
/sbin/advfs/verify
command to make sure that the domain is not corrupted. If it is not,
it is then safe to reboot using a different version of the operating system
and remount the filesets.
Use the AdvFS
verify
utility
(/sbin/advfs/verify)
to check the consistency of the on-disk metadata
in an AdvFS domain. This utility has been enhanced to better detect
certain potential problems. Compaq recommends that you
run the
verify
utility during your regular maintenance schedule.
You should run the
verify
utility when an entire AdvFS domain is scheduled to be offline,
as no fileset in the domain can be mounted when you run the
verify
utility.
If you create a cron job, ensure that it executes
the appropriate commands to dismount the file
systems.
You should also run the
verify
utility prior to doing an update installation.
Testing of AdvFS on a multiprocessor system showed
that occasionally (about 30 percent of the time) when a test suite was
run, it would fail because
vdump
processes would not respond to
kill -9
signals. The workaround is to send such a process a second
kill -9
signal.
While running
verify
on a dual-mounted domain, it is possible to receive the following type
of message:
Corruption in frag file type list for frag type 0 Expected to find set ID 36f68cbd.0006ae8c.1.8001 but found set ID 36f68c94.000b1b83.1.8001
This message can be ignored as it does not reflect an actual problem in the frag file, but instead an artifact of the dual-mounted domain.
Creation of domains smaller than 20 MB while running in lockmode 4 can cause the system to panic when the first fileset is created within the small domain. Such domains may safely be created and used if the system is not running in lockmode 4. To see which lockmode the system is running in, enter the following command:
%
sysconfig -q generic lockmode
The following notes describe problems and restrictions of the Logical Storage Manager (LSM).
Under certain hardware failure scenarios, an LSM volume configured with a sparse plex may erroneously return success to the file system or application when in fact the I/O failed. This does not occur when you do not configure volumes with sparse plexes.
Root, primary swap, and secondary swap volumes configured under LSM have the following restrictions:
rootdg.
Physical block 0 on Tru64 UNIX disks is typically write protected by default. If
a disk is added to LSM by using the
voldiskadd
utility, physical block 0 is skipped. However, if a partition that includes
physical block 0 is encapsulated into LSM by using the
volencap,
vollvmencap,
or
voladvdomencap
utility, physical block 0 is not skipped. This is not a problem because the
file system software already skips block 0 and does not write to it.
A problem can occur when an LSM volume that contains a write-protected block 0 is dissolved and its disk space is reused for a new purpose. Neither the new application nor LSM know about the write-protected physical disk block 0 and a write failure can occur.
To fix this problem, use the following steps to remove the write-protected physical disk block 0 from the LSM disk before it can be assigned to the new volume:
voldg
and
voldisk
commands to remove the disk from LSM.
voldiskadd
command to add either a specific partition of the disk
or the entire disk to LSM.
When you create an LSM mirror using a disk that is configured as Just-a-Bunch-of-Disks (JBOD) with either the SWXCR-P or SWXCR-E RAID controllers, a disk failure requires that you reconfigure the disk on the controller. The disk is in an unusable state once it is set off line by the controller and cannot be used by LSM until it is reconfigured. Refer to the StorageWorks RAID Array 200 Subystem Family Installation and Configuration Guide.
If you use the
setld
utility to install LSM after you originally install Tru64 UNIX,
you must rebuild the system kernel to enable LSM.
To rebuild the kernel, run the
doconfig
utility with no command flags.
Be sure to select all the appropriate options for your system, and be ready to edit the configuration file as needed to reimplement any changes required by your system.
Note that the
doconfig
menu display does not include LSM. However, the
doconfig
utility will build a kernel that includes LSM. Refer to the
Logical Storage Manager
guide for more information.
Only
LUN 0
is supported as a boot device by the console. Hence, you can
only mirror the LSM
rootvol
and
swapvol
volumes to
LUN 0
in an
HSZ.
Therefore, when you use the
volrootmir
script to mirror
rootvol
and
swapvol,
use only
LUN 0
on an
HSZ
as an argument to the
volrootmir
script.
If you use the LSM
rootvol
volume for the root file system and
the
swapvol
volume is in use as a primary swap volume, LSM adds the following entries to
the
/etc/sysconfigtab
file to enable rootability:
lsm: lsm_rootvol_is_dev=1 lsm_swapvol_is_dev=1
If these entries are deleted or if the
/etc/sysconfigtab
file is deleted, the system will
not boot. If this happens, you can boot the system interactively
as follows (the "\" character indicates line continuation):
>>>
boot -fl i
......... .........
Enter
kernel_name option_1 ... option_n:
vmunix \ lsm_rootdev_is_volume=1
Use the
sysconfigdb
utility to add the LSM entries as shown above to the
/etc/sysconfigtab
file after the system boots. Then, reboot the system for the changes
to take effect.
When using LSM, a preferred plex can not be dissociated from an active mirrored volume. Attempting to do so will cause the following error:
fsgen/volplex: Unexpected kernel error in configuration update
Before dissociating the plex, change the volume's read policy so the plex is no longer the preferred plex. For example:
#
volume -g my_diskgroup rdpol round my_volume
#
volplex -g my_diskgroup dis my_plex
Due to a problem in the presto driver, avoid using the presto reset and flush
operations (using the command
presto -R
or
presto -F
) to flush presto data. There is
a possibility that the system will panic if a presto reset/flush operation is
attempted. A workaround is to perform an orderly shutdown to flush all data
that can be flushed and use the console command
prflush -z
to purge any remaining data.
Note that reset/purge operations will destroy file system data and so should be performed only after all attempts to recover devices and data have failed.
The Associated Products CD-ROMs (APCDs) can be mounted with
the
mount
command on Tru64 UNIX systems running Version 4.0E or later, as follows:
#
mount -r /dev/rz4c /mnt
To mount the APCDs on releases prior to Version 4.0E, you must mount the CD-ROMs with the following options:
#
mount -r -t cdfs -o rrip /dev/rz4c /mnt
On versions prior to Version 4.0D you might receive the following error message indicating that CDFS support is not built in to the current running kernel:
#
mount -r -t cdfs -o rrip /dev/rz4c /mnt
/dev/rz4c on /mnt: No valid filesystem exists on this partition
If you receive this error, you need to build your kernel with the following option:
ISO 9660 Compact Disc File System (CDFS)