If a signed patch's contents are extracted into the same directory as the signed patch, the extracted patch cannot be installed by using the /usr/sbin/patchadd command. Instead, the signed patch is installed when you execute /usr/sbin/patchadd ./patchid. The unsigned, extracted patch is ignored.
In some instances, the following error messages might be displayed:
Verifying signed patch patchid... ERROR: Unable to open keystore /var/sadm/security/patchadd /truststore for reading ERROR: Unable to lock keystore /var/sadm/security for exclusive access Signature invalid on signed patch patchid. Patchadd is terminating. |
Workaround: Choose from the following workarounds:
Extract the signed patch into a directory other than the directory where the signed patch exists. Use the path to the extracted patch when executing the /usr/sbin/patchadd command.
After extracting the signed patch, but before running the /usr/sbin/patchadd command, delete the .jar file.
Do not extract the signed patch. Instead, populate the package keystore and install the signed patch directly. Follow these steps:
Become superuser.
Execute the following commands:
# /usr/bin/mkdir /var/sadm/security |
# /usr/bin/keytool -export -storepass changeit -alias \ gtecybertrustca -keystore usr/java/jre/lib/security/cacerts -file \ /tmp/gte.crt |
# /usr/bin/pkgadm addcert -t -f der /tmp/gte.crt |
Change the default password changeit to the password that is used to protect the Java keystore.
When using the lucreate command to create a new boot environment, the command fails in the following instances:
The device path for any mounted storage device is a subset of the device path for another mounted storage device.
For example, one file system is currently mounted on /dev/md/dsk/d1, and another file system is currently mounted on /dev/md/dsk/d10.
The device path for any mounted storage device is a subset of the device path for a storage device used as an argument to the lucreate command.
For example, if one file system is currently mounted on /dev/md/dsk/d10 and /dev/md/dsk/d100 is used as an option to lucreate, specifying a file system for the new boot environment.
The following misleading error messages are displayed:
The file system creation utility /usr/lib/fs/ufsufs/mkfs is not available. |
Unable to create all required file systems for boot-environment. |
Cannot make file systems for boot-environment |
Workaround: Ensure that there are no file systems in use on storage devices that have device names which are subsets of other storage devices with file systems that are also in use.
If any name ambiguity exists among the mounted file systems, rename the existing Solaris Volume Management metadevices.
In the following workaround, d10 and d100 are used as an example only. Other examples of ambiguous device names are d20 and d200, or d377 and d37, where d20 matches d200 and d377 matches d37.
Become superuser.
Use the metarename command to rename one of the ambiguous metadevice names.
# metarename d10 d300 |
The metadevice d10 is renamed to d300.
The file system on d10 must be unmounted before using the metarename command.
While the file system in unmounted, edit the /etc/vfstab file. Also, edit any other appropriate configuration file that contains the name of the metadevice you are renaming. Change any references of the old metadevice name to the new metadevice name.
If a process is accessing data on the file system, take the system down to single-user mode to unmount the file system. Reboot the system after making the changes.
If you use Solaris Management Console to perform operations on a User or Group account on a system that serves as a Domain Name Service (DNS) server, errors occur. These errors occur if the /etc/named.conf file exists on that system.
The following errors occur when you perform these operations from the graphical user interface (GUI) or when you use smuser and smgroup, which are command-line interfaces for the console.
The console launches a new dialog box or the smuser command exits with the following error messages when operated on a User:
"The attempt to view Users or Roles has failed due to an unexpected error. This was caused by the following error: CIM_ERR_FAILED." |
The console launches a new dialog box or the smgroup command exits with the following error message when operated on a Group:
"Attempted Read of Group IDs failed with unexpected CIM error: CIM_ERR_FAILED."operations from the GUI or command-line interface. |
Workaround: Choose from one of the following workarounds:
To solve this problem by restarting the DNS server, follow these steps:
Become superuser.
Move the named.conf file to a different directory. For example:
# mv /etc/named.conf /var/named/named.conf |
Restart the DNS server.
# pkill -9 in.named |
# /usr/sbin/in.named /var/named/named.conf |
To solve this problem by restarting the WBEM server, follow these steps:
Become superuser.
Use a text editor to edit the /usr/sadm/lib/wbem/WbemUtilityServices.properties file.
Replace the /etc/named.conf string with /tmp/new-filename.
Ensure that the file name that you choose does not already exist on the system.
Stop WBEM server.
# /etc/init.d/init.wbem stop |
Start the WBEM server
# /etc/init.d/init.wbem start |
For more information, see the smuser(1M) and the smgroup(1M) man pages.
You are booting a Sun LX50 which has a Service partition and the Solaris 9 12/03 (x86 Platform Edition) software is installed. Pressing the F4 function key to boot the Service partition, when given the option, causes the screen to go blank. The system then fails to boot the Service partition.
Workaround: Do not press the F4 key when the BIOS Bootup Screen is displayed. After a time-out period, the Current Disk Partition Information screen is displayed. Select the number in the Part# column that corresponds to type=DIAGNOSTIC. Press the Return key. The system boots the Service partition.
In the Solaris 9 12/03 release, on UltraSPARC II based systems, the CP Event message that accompanies some Uncorrectable Memory Error messages is not always produced. The following systems are included:
Sun EnterpriseTM 10000 system
Sun Enterprise 6500 system
Sun Enterprise 6000 system
Sun Enterprise 5500 system
Sun Enterprise 5000 system
Sun Enterprise 4500 system
Sun Enterprise 4000 system
Sun Enterprise 3500 system
Sun Enterprise 3000 system
The result is that some information needed to identify a failing CPU might not always be present.
Workaround: For the latest information, check the SunSolveSM Web site at http://sunsolve.sun.com.
The Solaris WBEM Services 2.5 daemon cannot locate providers that are written to the com.sun.wbem.provider interface or to the com.sun.wbem.provider20 interface. Even if you create a Solaris_ProviderPath instance for a provider that is written to these interfaces, the Solaris WBEM Services 2.5 daemon does not locate the provider.
Workaround: To enable the daemon to locate such a provider, stop and restart the Solaris WBEM Services 2.5 daemon.
# /etc/init.d/init.wbem stop # /etc/init.d/init.wbem start |
If you use the javax
API to develop
your provider, you do not need to stop and restart the Solaris WBEM Services
2.5 daemon. The Solaris WBEM Services 2.5 daemon dynamically recognizes javax
providers.
If you choose to use the com.sun application programming
interface rather than the javax
application programming interface to develop your WBEM software, only Common
Information Model (CIM) remote method invocation (RMI) is fully supported.
Other protocols, such as XML/HTTP, are not guaranteed to work completely with
the com.sun application programming interface.
The following table lists examples of invocations that execute successfully under RMI but fail under XML/HTTP:
Method Invocation |
Error Message |
---|---|
CIMClient.close() |
NullPointerException |
CIMClient.execQuery() |
CIM_ERR_QUERY_LANGUAGE_NOT_SUPPORTED |
CIMClient.getInstance() |
CIM_ERR_FAILED |
CIMClient.invokeMethod() |
XMLERROR: ClassCastException |
The Solaris Management Console Mounts and Shares tool cannot modify mount options on system-critical file systems such as root (/), /usr, and /var.
Workaround: Choose one of the following workarounds:
Use the remount option with the mount command.
# mount -F file-system-type -o remount,additional-mount-options \ device-to-mount mount-point |
Mount property modifications that are made by using the -remount option with the mount command are not persistent. In addition, all mount options that are not specified in the additional-mount-options portion of the previous command inherit the default values that are specified by the system. See the man page mount_ufs(1M) for more information.
Edit the appropriate entry in the /etc/vfstab file to modify the file-system mount properties, then reboot the system.
The following error message is displayed when memory is low:
CIM_ERR_LOW_ON_MEMORY |
You cannot add more entries when the CIM Object Manager is low on memory. You must reset the CIM Object Manager Repository.
Workaround: To reset the CIM Object Manager Repository, follow these steps:
Become superuser.
Stop the CIM Object Manager.
# /etc/init.d/init.wbem stop |
Remove the JavaSpacesTM log directory.
# /bin/rm -rf /var/sadm/wbem/log |
Restart the CIM Object Manager.
# /etc/init.d/init.wbem start |
When you reset the CIM Object Manager Repository, you lose any proprietary definitions in your data store. You must recompile the MOF files that contain those definitions by using the mofcomp command. See the following example:
# /usr/sadm/bin/mofcomp -u root -p root-password your-mof-file |