Nota: este artículo presenta información concerniente al sistema operativo Solaris 10, por ejemplo, un nuevo bootblk. El resto del artículo y la secuencia de comandos que le acompaña trabajan con las versiones 8, 9 o 10 de Solaris.
Es importante recopilar suficiente información antes de iniciar una análisis root-cause para determinar por qué la sesión patchadd o patchrm no tuvo éxito. Este documento está destinado a ayudar a los usuarios del sistema operativo Solaris, para plataformas SPARC o x86, a hacerlo. La atención se centra en qué hacer si el sistema al que se le aplicó el parche no rearranca correctamente, ya sea por provocar un aviso grave continuamente o por recaer en un indicador OK (en el caso del sistema operativo Solaris para plataformas SPARC).
Este artículo delinea qué archivos son más relevantes, dóndelocalizar estos archivos, y también (en función de qué herramienta de automatización del parche, si existe alguna, fue utilizada para aplicar el parche) dónde localizar cualquier salida relevante de esas herramientas. El documento no se ha diseñado para ayudar al analizar el fallo real, porque los problemas relacionados con parches pueden tener un sinnúmero de causas diferentes, pero intenta proporcionar algunos punteros genéricos.
Arranque del sistema desde un CD-ROM o una red
Si el sistema se reinicia y falla al regresar al nivel requerido para la ejecución, o falla al iniciar en modo de mantenimiento (es decir, si el sistema provoca un aviso grave o recae en un indicador OK), es necesario iniciar el sistema desde la red, o un CD-ROM, y montar los sistemas de archivos pertinentes para poder acceder al sistema.
1. Sólo para sistemas SPARC, si el sistema recae en un indicador OK, tal como se indica a continuación, realice estos pasos secundarios:
{1} ok
a. Primero, intente capturar la salida relevante de consola desde cuando el sistema comenzó a rearrancar hasta el punto donde el indicador OK se muestra. Mantenga esta salida, porque podría ser muy relevante para diagnosticar la causa real del error.
b. En este punto, intente identificar si el problema puede resolverse sin recurrir a arrancar desde la red o un medio, en contraposición a arrancar desde disco.
c. Si necesita iniciar en modo de single-user desde algún medio y montar los sistemas de archivo raíz, hay un par de opciones:
Inicializar desde red
Inicializar desde CD-ROM
Para inicializar desde red, asegúrese de que el cliente está configurado adecuadamente en el servidor de inicio y las conexiones y configuraciones de red son correctas (esto está fuera del alcance de este documento). A continuación, ejecute este comando:
{1} ok boot net -s
Para inicializar desde CD-ROM, ejecute este comando:
{1} ok boot cdrom -s
2. Si el sistema entra en pánico de continuo rearranque:
a. Primero intente capturar la salida completa del pánico desde consola.
b. A continuación, para un sistema SPARC, vaya al indicador OK y siga las instrucciones arriba explicadas para el paso 1.
Para un sistema x86, tendrá que asegurarse que la prioridad BIOS de arranque permite inicializar el sistema desde la red o un CD-ROM antes de arrancar desde disco duro. Cuando se lleva a cabo un arranque desde red, asegúrese de que el cliente está correctamente configurado en el servidor de inicio. Por ejemplo, si está usando DHCP, asegúrese de que las conexiones y configuraciones de la red del cliente son correctas, o si está usando NIS, compruebe que el cliente está configurado correctamente en el servidor NIS.
Recopilación de datos diversos para habilitar el análisis root-cause
En esta fase, supondremos que todas las tareas en el paso 2 citado arriba, se han completado y que el sistema ha sido montado en /a.
Nota: la mayoría de los datos siguientes es recopilada por la secuencia de comandos patchanalysis_gather.txt, con la excepción del patchadd de salida a la terminal. A continuación se incluye el código de origen para los archivos de secuencia de comandos patchanalysis_gather.txt.
1. Recopile los archivos de registro relacionados con patchadd o patchrm.
Si una sesión patchadd fue realizada exclusivamente a través de la utilidad patchadd, entonces a menos que haya capturado la salida patchadd en un archivo de registro, estos datos no son recuperables. Es posible que simplemente corte y pegue la salida patchadd desde una terminal o consola, si la salida sigue estando disponible. Tenga en cuenta que desea la salida real (STDOUT/STDERR) del patchadd, en lugar de los archivos de registo en /var/sadm/patch/ generados por patchadd.
Se recomienda encarecidamente que todas las salidas patchadd se redireccionen hacia un archivo durante la aplicación de parches, para que la salida pueda ser recuperada fácilmente si se requiere más adelante para un examen.
Por ejemplo, el siguiente comando dirige la salida de patchadd a un archivo de registo:
2. En los siguientes ejemplos, utilizaremos /a como prefijo para todos los comandos, porque suponemos que se arranca desde un medio alternativo y el sistema de archivos de raíz se monta bajo /a.
Si al sistema se le aplicó un parche utilizando la herramienta Traffic Light Patch (TLP), la salida TLP se encuentra en el siguiente directorio:
# ls /a/var/sadm/install_data/
PMGT:_TLP-Set_for_node_v4u-880c-muc07,_phase_GREEN,
_snapshot_2008-10-28_log
Estos datos son capturados por patchanalysis_gather.txt. Estos archivos son archivos de texto estándar que contienen salida patchadd. Por cada ejecución de la herramienta TLP se genera un archivo.
3. Si al sistema se le aplicó un parche mediante Sun Update Connection - Entreprise (UCE) o Sun xVM Ops Center (xVMOC) 1.x o 2.x, verificar que /a/var/opt/SUNWuce/agent existe, lo que confirma que UCE, xVMOC 1.x o xVMOC 2.x se utilizó.
Si /a/var/opt/SUNWuce/agent no existe, y se ha verificado que /a/var se ha montado correctamente (suponiendo que es independiente del sistema de archivos de raíz), al sistema no se le aplicó ningún parche utilizando ninguna de estas herramientas.
4. Los siguientes datos son también capturados por patchanalysis_gather.txt.
Si /a/var/opt/SUNWuce/agent existe, ejecute los siguientes comandos y observe la salida para identificar qué herramienta de automatización del parche se utilizó:
pkgparam -R /a -v SUNWucea VERSION
Esta salida implica que UCE está instalado: VERSION='1.1.1-314'.
pkgparam -R /a -v SUNWscnconnmgt VERSION
Esta salida implica que xVMOC 1.x está instalado: VERSION='1.0.0'.
Esta salida implica que xVMOC 2.x está instalado: VERSION='2.0.0.820,REV=2009.01.26.07.57.17'.
Es útil saber qué herramienta fue utilizada para poder ayudar a eliminar cualquier posible problemas en la herramienta o para reproducir el problema en otro sistema para identificar el problema subyacente.
Todas las herramientas de automatización del parche mencionadas anteriormente almacenan sus salida en /a/var/opt/SUNWuce/agent/logs/:
# ls -l /a/var/opt/SUNWuce/agent/logs/
total 33032
-rw-r--r-- 1 root root 5610478 Feb 20 17:12 error.log
-rw-r--r-- 1 root root 10485681 Feb 20 13:15 error.log.ad_bak
-rw-r--r-- 1 root root 94418 Feb 20 13:28 job.log
-rw-r--r-- 1 root root 15478 Feb 19 11:02 job_50007101.tgz
-rw-r--r-- 1 root root 11377 Feb 20 13:04 job_50011801.tgz
-rw-r--r-- 1 root root 12189 Feb 20 13:15 job_50012001.tgz
-rw-r--r-- 1 root root 12185 Feb 20 13:28 job_50012002.tgz
-rw------- 1 root root 323598 Feb 19 10:53 last_nco_file.xml
-rw-r--r-- 1 root root 30730 Feb 20 13:28 last_seeking.tgz
-rw-r--r-- 1 root root 16602 Feb 20 13:28 nco.log
-rw-r--r-- 1 root root 253666 Feb 20 13:28 resolve.log
-rw-r--r-- 1 root root 1434 Feb 20 09:29 uce_agent.log
# gzcat /a/var/opt/SUNWuce/agent/logs/job_50012002.tgz | tar tvf -
drwxr-xr-x 0/0 0 Feb 20 13:28 2009 va64-x4100a-muc07_job_500120
02/
-rwx------ 0/0 4466 Feb 20 13:28 2009 va64-x4100a-muc07_job_500120
02/Task.out
-rw-r--r-- 0/0 167297 Feb 20 13:28 2009 va64-x4100a-muc07_job_500120
2/copy_inventory
-rw-r--r-- 0/0 497 Feb 20 13:28 2009 va64-x4100a-muc07_job_500120
02/copy_basket
-rw-r--r-- 0/0 17 Feb 20 13:28 2009 va64-x4100a-muc07_job_500120
02/copy_policy
El archivo de registo más importante es Task.out. Contiene la salida de los comandos patchadd que se han ejecutado. No obstante, se recomienda copiar todos los archivos en /a/var/opt/SUNWuce/agent/logs fuera del sistema para posibles examen futuros. Copie también la salida de ls -ltr of /a/var/opt/SUNWuce/agent/logs. Estos datos son capturados por patchanalysis_gather.txt.
Otros archivos de registo que deberían ser examinados
Esta sección enumera datos relevantes que merecen ser capturados, todos son agrupados en la secuencia de comandos patchanalysis_gather.
patchadd -R /a -p
pkginfo -R /a -p
pkginfo -R /a
df -k /a y cualquier otro punto de montaje bajo /a
/a/var/adm/messages*
/a/var/sadm/system/admin/CLUSTER
/a/var/sadm/install/contents (este archivo puede ser bastante grande)
/a/etc/system
/a/etc/vfstab
/a/release
El contenido del directorio de /a/var/sadm/system/logs/
El contenido del directorio de /a/var/sadm/install_data/
Si hay zonas no-globales, lo siguiente podría ser útil:
/a/etc/zones/*
Estos datos son capturados por patchanalysis_gather.txt.
El siguiente directorio en cada zona no global contiene los registros del parche, y podría contener datos útiles para el análisis de problemas en cualquier zona no global. Nota: actualmente, la secuencia de comandos patchanalysis_gather.txtno recopila estos datos, porque es poco probable que este directorio contenga datos relevantes para impedir que el sistema se pueda arrancar.
<zonepath>/root/var/sadm/patch/*
Examinar salida y archivos de registo
Después de que la anterior información ha sido recopilada, se recomienda comenzar examinando la salida patchadd. A continuación, examine también el registro patchadd, que ha sido recopilado por /var/sadm/patch/*/log.
Busque errores y advertencias en estos registros, en concreto, la salida patchadd podría contener referencias a fallos pkgadd, con el subsecuente archivo de registo almacenado en /var/tmp.
Si es así, recupere este archivo de registo /a/var/tmp y examínelo, porque es muy relevante para determinar qué provocó el problema.
Examine también la salida patchadd para detectar si cualquier secuencia en el nivel del parche, como, por ejemplo, prepatch o postpatch, falló o generó mensajes inesperados. Compare la salida patchadd con salidas nominales conocidas patchadd de un sistema en el que la aplicación del parche se completó con éxito, y busque cualquier mensaje adicional u omitido.
Si hay zonas no-globales presentes en el sistema afectado, examine la salida patchadd en busca de errores que indiquen problemas específicos a la presencia de zona no globales. Esto puede tomar la siguiente forma:
Failed to boot non-global zone <zone-name>
Este mensaje indica que la zona no global en cuestión se ha detenido, y patchadd no pudo mover la zona afectada hacia una área interna utilizada para el mantenimiento de software. Si se produce esta situación, recopile los archivos /a/etc/zones/*.xml además de /a/etc/vfstab. Estos archivos permiten a un ingeniero de asistencia técnica comenzar a determinar el estado del sistema y la configuración de la zona antes de aplicar el parche.
Si la salida df -k indica que el espacio disponible en el sistema de archivos de raíz o en /var alcanzó 100% de su capacidad, se recomienda que se ponga en contacto con el servicio de asistencia técnica de Sun, porque en función del parche que estaba siendo instalado y qué parte de la instalación del parche falló, puede que se requieran ciertos pasos manuales para restablecer la consistencia del sistema.
Por ejemplo, si durante la 137137-09 ejecución post-parche, espacio disponible en /platform llegó a 100%, entonces al volver a arrancar, el sistema seguramente no iniciará más allá del indicador OK, y los errores indicarán que la carga de arranque ha fallado. En esos casos, es posible que el sistema sea rescatado fácilmente sin ningún daño irreversible, si se puede recuperar suficiente espacio para permitir que el archivo de arranque sea reconstruido.
Por lo tanto, como puede ver, es vital entender primero el problema exacto, porque eso le puede permitir tomar una decisión adecuada sobre el procedimiento de acción que necesita emprender.
Soluciones y problemas posibles
Problema: no se puede abrir /etc/path_to_inst.
Para solucionar, ejecute boot -ar, y cuando se le inste a reconstruir /etc/patch_to_inst, seleccione yes.
Problema: bloque de inicio (que son particulares de sistemas Solaris 10 basados en SPARC a los que se aplicó el parche Kernel Update 137137-09). Normalmente, estos se identifican mediante un error parecido a uno de los siguientes:
The file just loaded does not appear to be executable.
Boot load failed. The file just loaded does not appear to be executable.
Se recomienda que se ponga en contacto con el servicio de asistencia técnica de Sun con la información siguiente para obtener más instrucciones. Puede obtener $ROOTFSTYPE desde df -n /a | awk '{print $3}' (si la raíz está montada ./a):
ls -l /platform/`uname -m`/boot_archive
ls -l /platform/`uname -m`/lib/fs/$ROOTFSTYPE/bootblk
A partir de la versión Solaris 10 10/08 para plataformas SPARC, o si el parche Kernel Update 137137-09 es el que se aplica, un nuevo bootblk está instalado. Esta nueva bootblk utiliza un boot_archive para iniciar el sistema, en lugar de cargar ufsboot, como se hacía en las actualizaciones anteriores a la versión Solaris 10 10/08 o cuando 137137-09 no es aplicado.
Por lo tanto, es vital comprender qué bootblk es adecuado. La instalación del bootblk incorrecto hace que el sistema no se pueda arrancar hasta que el bootblk correcto sea instalado. Se recomienda obtener instrucciones más detalladas del servicio de asistencia técnica de Sun.
Si el sistema de archivos de raíz se queda sin espacio suficiente en /platform mientras construye el boot_archive, esto puede llevar al siguiente error:
The file just loaded does not appear to be executable.
De nuevo, se recomienda que se ponga en contacto con el servicio de asistencia técnica de Sun en tal caso, puesto que el sistema tiene que analizarse para determinar la mejor solución a largo plazo para economizar espacio y crear el boot_archive utilizando el comando bootadm.
Es importante tener en cuenta que para usar herramientas como installboot al arrancar desde un medio para instalar un bloqueo de inicio, debe utilizar installboot desde el medio correcto. Para instalar bootblk en un sistema con parche al nivel 137137-09 o en un sistema que ya ejecuta el SO Solaris 10 10/08, debe arrancar fuera de la versión Solaris 10 10/08 o posterior, o debe utilizar installboot desde el sistema montado.
Por lo tanto, por ejemplo, si arranca el sistema desde la red a una imagen del sistema Solaris 5/08, debe ejecutar esto:
#/a/usr/sbin/installboot
No esto:
#/usr/sbin/installboot
Pero si arranca el sistema desde Solaris 10 10/08 o versiones posteriores, es aceptable ejecutar lo siguiente:
#/usr/sbin/installboot
Por lo tanto, debe tener cuidado durante la utilización de las utilidades del sistema mientras haya arrancado desde un medio para realizar modificaciones a un sistema montado. Se aconseja que utilice la última actualización disponible de la imagen de Solaris como imagen de arranque.
Para más información
A continuación se ofrecen algunos recursos adicionales:
Print-friendly Version
