Esta sección describe errores de administración del sistema en el Sistema operativo Solaris 10.
El parche FKU 137137-xx no admite el software Volume Manager de terceros, con algunas excepciones. Esta falta de compatibilidad se debe a la implementación de prepatch, postpatch y postbackout. Si los usuarios utilizan software Volume Manager de terceros, no pueden aplicar el parche FKU. Durante la instalación aparece el siguiente mensaje de error:
unsupported root slice type xxxxx |
Sin embargo, se admite el software Volume Manager de Fujitsu y Veritas.
Solución: ninguna.
En un sistema que tenga zonas no globales, se recomienda no utilizar la opción patchadd -M. La implementación actual de patchadd -M se aplica primero a todos los parches de la zona global, y únicamente después a las zonas no globales. No es la mejor de las situaciones, porque si se da un problema tras aplicar varios parches en la zona global pero no en la zona no global, las zonas pueden quedar bastante desincronizadas entre sí, una situación potencialmente difícil de resolver.
Solución: patchadd -a - M puede utilizarse para generar una secuencia de instalación válida para un conjunto de parches y para asegurarse de que los parches se instalarán sin problemas.
Para obtener más información, consulte el artículo Best Practices de BigAdmin Patching Hub, en http://www.sun.com/bigadmin/features/articles/patch_management.jsp.
El comando ::findleaks del depurador mdb falla en el sistema operativo Solaris 10 10/08. Aparecerá el siguiente mensaje de error:
mdb: couldn't walk 'modctl': unknown walk name |
Solución: antes de utilizar el comando::findleaks , escriba el comando ::load krtld.
El DVD de Solaris 10 10/08 no se monta de forma predeterminada durante el tiempo de ejecución. No se muestra ningún mensaje de error.
Solución: realice los pasos siguientes:
Conviértase en superusuario.
Inhabilite vold:
En los sistemas Solaris 10:
# svcadm disable -t volfs |
En los sistemas Solaris 8 y Solaris 9:
/etc/init.d/volmgt stop |
Monte el medio manualmente con el comando # mount -F hsfs ruta_dispositivo_bloqueo ruta_punto_montaje. Por ejemplo:
# mount -F hsfs /dev/rdsk/c0t2d0s2 /mnt |
La consola de administración de SolarisTM se bloquea y no permite iniciar sesión como usuario root en dicha consola tras habilitarse Solaris Trusted Extensions. El mensaje de error siguiente puede aparecer en pantalla si se bloquea la consola de administración de Solaris:
Configuring the Management Server... |
Solución: realice los pasos siguientes:
Configure Solaris Trusted Extensions e inicie la consola de administración de Solaris.
En el menú de la consola, seleccione Abrir caja de herramientas.
Seleccione localhost si se encuentra disponible.
Si localhost no está disponible, escriba localhost.
Seleccione la caja de herramientas Policy=TSOL.
Inicie sesión nuevamente en la consola de administración de Solaris como usuario root.
(Opcional) Si vuelve a fallar este segundo intento de inicio de sesión en la consola de administración de Solaris, repita los pasos del 1 al 5 escribiendo 127.0.0.1 en lugar de localhost en el paso 3.
Al conectar una zona, si el host original y el nuevo tienen paquetes en el mismo nivel de parches pero en distintos historiales de parches intermedios, la conexión de zona puede llegar a fallar. Aparecen distintos mensajes de error. El mensaje de error depende los respectivos historiales de parches de los hosts.
Solución: compruebe que los sistemas del host original y el nuevo tengan aplicados en cada parche la misma secuencia de versiones de parche.
Los sistemas que tienen un controlador SATA compatible con AHCI, la configuración del BIOS suele permitir que el controlador pueda ajustarse en los modos AHCI, legacy o RAID. Solaris es compatible con los modos AHCI y legacy.
El modo SATA que se establece en el BIOS no debe modificarse tras la instalación inicial de Solaris. Tampoco se debe modificar ni antes ni después de una actualización de Solaris. Si el modo SATA se modifica en el BIOS tras instalar Solaris, el sistema se reiniciará y no arrancará, ni tampoco indicará el motivo del error.
Solución: si se da un error de arranque debido al cambio en el ajuste del BIOS, restablezca el valor original para poder arrancar Solaris.
A partir de los parches 119254-42 y 119255-42, se han modificado las utilidades de instalación de parches patchadd y patchrm para cambiar la forma de manejar determinados parches que incorporan funciones nuevas o archivos existentes que son incompatibles con el sistema que se ejecuta. Esta modificación de utilidades afecta a la instalación de estos parches en cualquier versión 10 de Solaris. Estos parches de activación diferida controlan mejor la amplia gama de cambios en los parches de núcleo.
En la aplicación de parches de activación diferida se utiliza lofs, un sistema de archivos de reproducción en bucle, para crear una copia del sistema de archivos root. Los archivos originales a los que se aplica parches se copian en una ubicación protegida y se aplican los parches a la copia de lofs del sistema de archivos root. A continuación, el archivo original se vuelve a montar en lofs sobre el nuevo archivo al aplicarse el parche. De este modo, durante la aplicación de parches se mantiene la coherencia del sistema que se ejecuta, las funciones nuevas no se activan y los cambios incompatibles permanecen ocultos hasta que el usuario efectúe un rearranque.
Tras aplicar el parche de activación diferida, los usuarios deben rearrancar lo antes posible aunque no inmediatamente, sino que antes pueden aplicar otros parches.
El parche README proporciona instrucciones sobre qué parches requieren un reinicio.
Sun recomienda encarecidamente que las operaciones de parches se lleven a cabo en modo monousuario, sobre todo cuando esto se indica expresamente en el archivo LÉAME (README) del parche.
Si ejecuta zonas no globales o tiene el sistema lofs desactivado, tenga en cuenta lo siguiente cuando instale o elimine los parches de activación diferida:
Todas las zonas no globales deben estar detenidas para esta operación de parche. Debe detener la zona no global antes de aplicar el parche.
Los parches de activación diferida requieren el sistema de archivos en bucle inverso (lofs) para completarse de forma correcta. Es probable que los sistemas que ejecutan Sun Cluster 3.1 o Sun Cluster 3.2 tengan el sistema lofs desactivado a causa de las restricciones en las funciones de HA-NFS cuando lofs está activado. Por tanto, antes de instalar un parche de activación diferida, debe volver a activar el sistema de archivos en bucle siguiendo estos pasos.
Elimine o comente la siguiente línea del archivo /etc/system:
exclude:lofs |
Rearranque el sistema.
Instale la revisión.
Una vez completada la operación de instalación del parche, restaure o elimine los comentarios de la misma línea del archivo /etc/system.
Reinicie el sistema para reanudar las operaciones normales.
No se muestra ningún mensaje de error.
Solución: Sun recomienda la función Modernización automática de Solaris para administrar los parches. La función Modernización automática de Solaris evita los problemas de la aplicación de parches en un sistema en ejecución. La función Modernización automática de Solaris reduce el tiempo de inactividad inherente a la aplicación de parches, así como los riesgos, al proporcionar la función de recuperación en caso de suceder un problema. Para obtener más información, consulte la Guía de instalación de Solaris 10 10/08: Modernización automática de Solaris y planificación de la modernización.
Si se ejecutan en sistemas de archivos de gran tamaño, por ejemplo ZFS, las aplicaciones que utilizan statvfs(2) o statfs(2) para obtener información sobre el estado del sistema de archivos pueden presentar un error. Aparecerá el siguiente mensaje de error:
Value too large for defined data type |
Solución: las aplicaciones deben utilizar statvfs64().
En sistemas que ejecuten una versión de Solaris que no tenga en cuenta zonas, no funcionará el uso de patchadd- R o de cualquier otro comando que acepte la opción -R con el fin de especificar una ruta root alternativa para una zona global con zonas no globales.
En contraposición con el mensaje de error que se muestra al usar el comando luupgrade [- t, -T, -p, -P], en este caso no aparece ningún mensaje de error relativo al uso de las pertinentes restricciones de comandos.
No hay indicaciones de que la opción -R no funcione. Como consecuencia del error del comando, los parches o paquetes de Solaris 10 no se instalan en ninguna de las zonas no globales que están instaladas.
Este problema se da al instalar o desinstalar paquetes o parches.
La opción -R funciona si el entorno de arranque alternativo ha configurado zonas no globales, y no ha instalado zonas no globales. Ahora bien, para prevenir un posible problema, o si no está seguro de que haya zonas no globales instaladas que se hayan usado como ruta de root alternativa, restrinja el uso de la opción -R en todos los casos.
Para obtener mas información, consulte las páginas de comando man :
Solución 1: actualice el sistema operativo como mínimo a la versión Solaris 10 1/06.
Si está ejecutando la versión Solaris 10 3/05, instale los parches siguientes para permitir el uso de comandos que acepten la opción -R para crear una ruta de root alternativa:
Id. de parche 119254-19 para sistemas basados en SPARC.
Id. de parche 119255-19 para sistemas basados en x86.
Solución temporal 2: restrinja el uso del comando patchadd -R o de cualquier otro comando que acepte la opción -R para crear una ruta de root alternativa.
En lugar de ello, arranque la root alternativa, por ejemplo la versión Solaris 10, como sistema operativo activo. A continuación, instale y desinstale los parches y paquetes de Solaris 10 sin utilizar la opción -R.
Un sistema que ejecuta Sun Patch Manager Tool 2.0 puede gestionar sistemas remotos que ejecutan la herramienta Patch Manager Tool, incluido Sun Patch Manager Tool 1.0.
Sin embargo, un sistema con una versión anterior de Patch Manager Tool no puede gestionar sistemas remotos que ejecuten Patch Manager Tool 2.0. Entre las versiones anteriores se incluyen las siguientes:
Software básico de Sun Patch Manager 1.x
Sun Patch Manager Tool 1.0
La compatibilidad del modelo de información común/gestión empresarial basada en web (CIM/WBEM) para Patch Manager Tool no existe en el SO Solaris 8. Por tanto, la gestión remota con Patch Manager no se aplica a los sistemas con Solaris 8.
Si utiliza el comando smdiskless para eliminar un cliente sin disco, el comando falla. El cliente sin disco no se elimina de las bases de datos del sistema. Aparecerá el siguiente mensaje de error:
Failing with error EXM_BMS. |
Solución: deje de compartir la partición /export antes de agregar el cliente.
Si utiliza el comando smosservice delete para quitar un servicio de cliente sin disco, el comando no quita con éxito todos los directorios del servicio.
Solución: Siga estos pasos:
Asegúrese de que no existe ningún cliente que utilice el servicio.
# unshare /export/exec/Solaris_10_sparc.all # rm -rf /export/exec/Solaris_10_sparc.all # rm -rf /export/exec/.copyofSolaris_10_sparc.all # rm -rf /export/.copyofSolaris_10 # rm -rf /export/Solaris_10 # rm -rf /export/share # rm -rf /export/root/templates/Solaris_10 # rm -rf /export/root/clone/Solaris_10 # rm -rf /tftpboot/inetboot.sun4u.Solaris_10 |
Elimine la siguiente entrada del archivo /etc/bootparams.
fs1-24 boottype=:os |
Elimine esta entrada únicamente si este servidor de archivos no proporciona funciones o recursos para otros servicios.
Elimine la siguiente entrada del archivo /etc/dfs/dfstab.
share -F nfs -o ro /export/exec/Solaris_8_sparc.all/usr |
Modifique el archivo /var/sadm/system/admin/services/Solaris_10.
Si el servidor de archivos no es Solaris_10, elimine este archivo.
Si el servidor de archivos es Solaris_10, elimine todas las entradas que haya después de las primeras tres líneas. Las líneas eliminadas indican los paquetes USR_PATH y SPOOLED ROOT de servicio en /export/root/templates/Solaris_10 y las plataformas admitidas.
Después de modificar el contenido de snmpd.conf, puede emitir el comando kill -HUP snmp Process ID. Este comando detiene el proceso snmp. A continuación, el comando envía la señal al agente principal de System Management Agent (snmpd) para que vuelva a leer snmpd.conf e implemente las modificaciones que ha introducido. Es posible que el comando no produzca siempre que el agente principal vuelva a leer el archivo de configuración. Por tanto, la utilización del comando es posible que no active en todos los casos las modificaciones en el archivo de configuración.
En lugar de utilizar kill -HUP, reinicie System Management Agent después de añadir las modificaciones a snmpd.conf. realice los pasos siguientes:
Conviértase en superusuario.
Escriba el siguiente comando:
# /etc/init.d/init.sma restart
Está arrancando un conmutador Sun LX50 que tiene una partición de servicio y el Sistema operativo Solaris 10 instalado en un sistema x86. Al pulsar la tecla de función F4 para arrancar la partición de servicio, cuando se proporciona esta opción, la pantalla se queda en blanco. Después el sistema no consigue arrancar la partición del servicio.
Solución: no pulse la tecla F4 cuando aparezca la pantalla de arranque de la BIOS. Tras un tiempo de espera, aparece la pantalla de información sobre la partición actual del disco. Seleccione un número en la columna Part# que se corresponda con type=DIAGNOSTIC. Pulse la tecla de retorno. El sistema arranca la partición de servicio.
Si decide usar la interfaz de programación de aplicaciones com.sun, en lugar de javax
para desarrollar el software WBEM, sólo se admite totalmente la llamada a método remoto (RMI) del Modelo de información común (CIM). No se garantiza que otros protocolos, como XML/HTTP, funcionen perfectamente con la interfaz de programación de aplicaciones com.sun.
En la siguiente tabla se muestran ejemplos de llamadas que se ejecutan satisfactoriamente con RMI, pero que fallan con XML/HTTP.
Llamada a método |
Mensaje de error |
---|---|
CIMClient.close() |
NullPointerException |
CIMClient.execQuery() |
CIM_ERR_QUERY_LANGUAGE_NOT_SUPPORTED |
CIMClient.getInstance() |
CIM_ERR_FAILED |
CIMClient.invokeMethod() |
XMLERROR: ClassCastException |