Installation Bugs

SPARC: Removing Patches After Upgrade Might Corrupt WBEM Repository (4820614)

The WBEM Repository CIM database can be corrupted under the following conditions:

1. You apply a revision of patch 112945 for a Solaris 9 Update Release to a system that is running the Solaris 9 operating environment.

2. You then remove the patch that was applied to the system.

If the WBEM Repository is corrupted, the following error message is displayed in the Solaris Management Console Log Viewer:

CIM_ERR_FAILED:
/usr/sadm/lib/wbem/../../../../var/sadm/wbem/logr/
preReg/PATCH113829install/Solaris_Application.mof,18,ERR_SEM,
ERR_EXC_SET_CLASS,CIM_ERR_FAILED:Other Exception:
java.io.StreamCorruptedException: invalid stream header

Workaround: Choose one of the following workarounds.

• Follow these steps to prevent the WBEM Repository from being corrupted.

  1. Become superuser.

  2. Before you apply the patch, back up the WBEM Repository.

     # cp -r /var/sadm/wbem/logr path/logr

     In the previous example, path is the path to the backup WBEM Repository.

  3. If the WBEM Repository is corrupted after you back out the patch, stop the WBEM server.

     # /etc/init.d/init.wbem stop

  4. Restore the backup WBEM Repository.

     # cp -rf path/logr /var/sadm/wbem/logr

  5. Restart the WBEM server.

     # /etc/init.d/init.wbem start

• Follow these steps to create a new WBEM Repository.

  ---

  Note –

  This workaround does not restore the WBEM data if the WBEM Repository is corrupted. Any data that was added to the repository during the installation is lost.

  ---

  1. Become superuser.

  2. Stop the WBEM server.

     # /etc/init.d/init.wbem stop

  3. Remove the files from the /logr directory.

     # rm /var/sadm/wbem/logr/*

  4. Remove the /notFirstTime directory.

     # rmdir notFirstTime

  5. Start the WBEM server.

     # /etc/init.d/init.wbem start

  6. Manually compile any proprietary MOFs.

     # /usr/sadm/bin/mofcomp MOF-filename

patchadd Command Displays Error Message if a Patch That Supports Multiple Patch Architecture Is Installed (4706994)

If you install a patch that supports multiple package architecture, an error similar to the following benign error message might be displayed in the /var/sadm/install_data/Maintenance_Update_log:

Installing xxxxxx-yy (x of xx)
See /var/sadm/patch/xxxxxx-yy log for details
grep: can't open pdgabbrev.extension/pkginfo

For example, if patch 123456-01 contains patch packages SUNWcar and SUNWcar.u, the following error message is displayed.

grep: can't open SUNWcar.u/pkginfo

Workaround: Ignore the error message. The message does not affect the installation of the patch. The message indicates that the patchadd command does not pass the correct parameter to the remove_PATCH_PROPERTIES function.

For more information, refer to the patchadd(1M) man page.

install_mu Does Not Function Correctly if Started With sh (4062334)

Because of problems that stem from the interactions between sh(1) and ksh(1), the install_mu utility might fail to install certain patches correctly. This failure occurs when you start the utility by using the following command from the command line or from an administrative script:

# /bin/sh ./install_mu options

Workaround: Execute install_mu from the command line or from an administrative script as follows:

# ./install_mu options

patchadd Command Displays an Error That It Is Terminating

One of the following benign messages might be displayed in the Maintenance_Update_log in the /var/sadm/install_data directory:

One or more patch packages included in
XXXXXX-YY are not installed on this system.

Patchadd is terminating.

Or:

Installation of XXXXXX-YY failed:
Attempting to patch a package that is not installed.

These messages indicate the patchadd command could not locate on your system any of the packages that the command intended to patch, so the indicated patch was skipped.

The message is displayed when the patchadd command discovers a discrepancy while installing a patch of one architecture onto a system with a different architecture. For example, a sun4u patch on a sun4m system.

This message might also be the result of one or more missing packages. The package might have been removed by the administrator, or was never installed. An example of this type of error would be if a cluster that was smaller than the Entire Distribution was installed.

Workaround: Ignore the error message.

Cannot Log In if System Is Not Rebooted (4423853)

When installing the MU in single-user mode, do not use the exit command when you are done. Use the reboot command. If the exit command is used instead of the reboot command, the following problems occur:

• The system is brought to init 3, and you cannot log in until the system is rebooted.

• No other users can log in until the system is rebooted.

• The pam_projects.so.1 module dumps core when any user or process tries to log in. The following message is displayed:

  NOTICE: core_log: in.rshd[1479] core dumped: /var/crash/core.in.rshd.1479

• If a process attempts to access the pam_projects.so.1 module, load module messages are displayed on the system console. A message similar to the following is displayed:

  cron[1433]: load_modules: can not open module /usr/lib/security/pam_projects.so.1

  These messages are also displayed if the MU is installed in multiuser mode. In both cases, the messages are no longer displayed after the system is rebooted.

Workaround: If the exit command is used after installing in single-user mode, reboot the system.

If the exit command is used after installing the MU in multiuser mode, and no root users remain logged in, reboot the system.