Este capítulo describe los problemas conocidos relacionados con la instalación y el uso del software Solaris 9 MU4.
Se puede dañar la base de datos CIM del depósito WBEM en las condiciones siguientes:
Aplica una revisión de la modificación 112945 en una versión de actualización de Solaris 9 en un sistema que ejecute el entorno operativo Solaris.
Elimina, a continuación, la modificación que se ha aplicado al sistema.
Si el depósito WBEM está dañado, aparece el siguiente mensaje de errror en el registro de Solaris Management Console:
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 |
Solución: elija una de las soluciones alternativas siguientes:
Siga estos pasos para evitar daños en el depósito WBEM.
Conviértase en superusuario.
Antes de aplicar la modificación, haga una copia de seguridad del depósito WBEM.
# cp -r /var/sadm/wbem/logr ruta/logr |
En el ejemplo anterior, ruta es la ruta a la copia de seguridad del depósito WBEM.
Si el depósito WBEM se daña después de haber retirado la modificación, pare el servidor WBEM.
# /etc/init.d/init.wbem stop |
Restaure el depósito WBEM de la copia de seguridad.
# cp -rf ruta/logr /var/sadm/wbem/logr |
Reinicie el servidor WBEM.
# /etc/init.d/init.wbem start |
Siga estos pasos para crear un depósito WBEM nuevo.
Esta solución alternativa no restaura los datos de WBEM si se daña el depósito WBEM. Se pierde cualquier dato añadido al depósito durante la instalación.
Conviértase en superusuario.
Pare el servidor WBEM.
# /etc/init.d/init.wbem stop |
Elimine los archivos del directorio /logr.
# rm /var/sadm/wbem/logr/* |
Elimine el directorio /notFirstTime.
# rmdir notFirstTime |
Inicie el servidor WBEM.
# /etc/init.d/init.wbem start |
Compile manualmente cualquier MOF propietario.
# /usr/sadm/bin/mofcomp nombre_archivo_MOF |
Si instala una modificación que admita la arquitectura de paquete múltiple, podría aparecer en /var/sadm/install_data/Maintenance_Update_log un error similar al mensaje siguiente:
Installing xxxxxx-yy (x of xx) See /var/sadm/patch/xxxxxx-yy log for details grep: can't open pdgabbrev.extension/pkginfo |
Por ejemplo, si la modificación 123456-01 contiene los paquetes de modificaciones SUNWcar y SUNWcar.u, aparece el mensaje de error siguiente:
grep: can't open SUNWcar.u/pkginfo |
Solución: haga caso omiso del mensaje de error. El mensaje no afecta a la instalación de la modificación. El mensaje indica que el comando patchadd no pasa el parámetro correcto a la función remove_PATCH_PROPERTIES.
Si desea más información consulte la página de comando man patchadd(1M).
A causa de los problemas que surgen de la interacción entre sh(1) y ksh(1), es posible que la utilidad install_mu no instale correctamente algunas modificaciones. Este fallo se produce cuando se inicia la utilidad, desde la línea de comandos o desde un script de administración, mediante el comando siguiente:
# /bin/sh ./install_mu opciones |
Solución: ejecute install_mu desde la línea de comandos o desde una secuencia administrativa de la forma siguiente:
# ./install_mu opciones |
Uno de los siguientes mensajes benignos se podría mostrar en el archivo Maintenance_Update_log dentro del directorio /var/sadm/install_data:
One or more patch packages included in XXXXXX-YY are not installed on this system. Patchadd is terminating. |
O bien:
Installation of XXXXXX-YY failed: Attempting to patch a package that is not installed. |
Estos mensajes indican que el comando patchadd no ha podido encontrar en el sistema ninguno de los paquetes que el comando intentaba modificar, de manera que se omitió la modificación indicada.
Aparece el mensaje cuando el comando patchadd descubre una discrepancia al instalar una modificación de un tipo de arquitectura en un sistema con otro tipo de arquitectura diferente. Por ejemplo, una modificación de sun4u en un sistema sun4m.
Este mensaje también podría mostrarse como resultado de la falta de uno o varios paquetes. Puede que el administrador haya eliminado el paquete o que nunca haya existido. Un ejemplo de este error sería la instalación de un grupo más reducido que la Distribución completa.
Solución: haga caso omiso del mensaje de error.
Al realizar la instalación de MU en modalidad monousuario, no use el comando exit cuando haya terminado. Use el comando reboot. Si se usó el comando exit en lugar de reboot ocurre lo siguiente:
El sistema se ha llevado al estado init 3 y no puede iniciar la sesión hasta que no rearranque el sistema.
Ningún usuario puede iniciar la sesión mientras no se rearranque el sistema.
El módulo pam_projects.so.1 realiza un volcado del núcleo cuando algún usuario o proceso intenta iniciar una sesión. Aparece el mensaje siguiente:
NOTICE: core_log: in.rshd[1479] core dumped: /var/crash/core.in.rshd.1479 |
Si un proceso intenta acceder al módulo pam_projects.so.1, se muestran mensajes de carga de módulo en la consola del sistema. Se muestra un mensaje parecido al siguiente:
cron[1433]: load_modules: can not open module /usr/lib/security/pam_projects.so.1 |
Estos mensajes también se muestran si MU se ha instalado en modalidad multiusuario. En ambos casos, los mensajes dejan de aparecer tras rearrancar el sistema.
Solución: si se utiliza el comando exit después de instalar en modo de monousuario, rearranque el sistema.
Si se usa el comando exit después de instalar MU en modalidad de multiusuario y no queda ningún usuario root conectado, rearranque el sistema.