Últimos Cambios
Blog personal: El hilo del laberinto
|
|
|
Últimos Cambios |
|
Blog personal: El hilo del laberinto
|
|
|
Última Actualización: 29 de diciembre de 2009 - Martes
Solaris 10 Update 8 se publico hace unas semanas, y he actualizado la mayoría de mis sistemas sin ningún problema.
No obstante existe un problema conocido con la actualización, cuando estamos usando Zonas y la zona Global tiene el directorio "/var" en un "dataset" separado (que es mi caso). Esperando que solucionen este problema, tengo algunas máquinas usando aún Solaris 10 Update 7.
Por supuesto Solaris 10 Update 7 sigue siendo una versión soportada de Solaris, así que se siguen publicando actualizaciones con frecuencia. En una de ellas Sun ha portado el soporte para la nueva versión de ZFS, que es una de las mejoras del Update 8. "¡¡Bien!!", me dije, "Puedo utilizar el nuevo formato ZFS 15, aunque no pueda actualizar el sistema operativo, de momento". Y así lo hice.
Mi consejo es... ¡¡NO LO HAGAS!!. O, al menos, no actualices tu "pool" ZFS de arranque. No cometas el mismo error que yo, sobre todo si no eres capaz de resolver el entuerto por ti mismo.
En cuanto salieron esos parches ZFS, actualicé mi "pool" de la versión 10 a la version 15. Perfecto, todo funciona correctamente. Era un hombre feliz.
Nueve días más tarde, en una instalación rutinaria de parches, tuve que reiniciar la máquina. Es algo que hay que hacer de vez en cuando, porque algunos parches necesitan instalarse en "single user" o necesitan un reinicio para activarse.
Y la máquina no arrancó.
La máquina en sí está en Francia, y no tengo acceso físico a ella. Simplemente no estaba accesible de forma remota. Afortunadamente me pasé dos meses preparándome para esa eventualidad, y este incidente ha demostrado que fue tiempo bien empleado.
Aprovechando que esa máquina tiene KVM remoto, conecté con el cliente correspondiente para acceder a la pantalla y ver qué problema había. La máquina arrancaba el GRUB, pero éste no era capaz de encontrar el "menu.lst" para lanzar el sistema operativo.
Frecuentando muchas listas de correo sobre Solaris, reconocía los síntomas: El GRUB que arranca el sistema operativo no había sido actualizado para soportar el nuevo formato ZFS. Es un problema, pero conocido y de fácil solución gracias a la preparación que hice al equipo para poder enfrentarme a una "recuperación catastrófica".
Arranqué la máquina con Linux (tiene arranque dual), descargué la ISO de Solaris 10 Update 8, la monté en la máquina virtual y arranqué el Solaris dentro de la máquina virtual. Una vez en el instalador, arranque el DVD en modo "single user" y actualicé el GRUB del disco duro con la versión en el DVD (que está actualizado) con los commandos:
installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c0d0s0 installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c0d1s0
Reinicio la máquina virtual de nuevo, desactivando la ISO Solaris. El GRUB reconoce el "menu.lst" sin problemas. Perfecto. No arranco Solaris porque el hardware virtualizado es diferente y no quiero pasar por un ciclo de "reconfigure". Hasta aquí, rutina.
Reinicio Solaris de forma nativa. A través del KVM veo el GRUB, que parece funcionar correctamente. El sistema arranca... pero a los pocos segundos la máquina se reinicia. Se crea un bucle infinito en el que la máquina arranca pero reinicia a los pocos segundos de empezar a cargar el sistema operativo. Aún no me preocupo. A fin de cuentas he instalado parches nuevos y es posible que, después de todo, sí necesite realizar un "reconfigure".
Usando el KVM, intento arrancar en modo a prueba de fallos. En Solaris, al contrario que en otros sistemas operativos, el modo a prueba de fallos es un sistema operativo independiente, con su propio kernel y su propia "ramdisk" de arranque. Lo lanzo. Funciona correctamente. Entro por el KVM e intento montar el "pool" ZFS del disco duro. El sistema me dice que no existe. Que no encuentra nada.
Una actualización rutinaria se ha convertido en la típica pesadilla de un viernes (mi regla es "¡no se toca nada los viernes!"), pero en esta ocasión es un sábado a las 4 de la mañana, he dormido poco el día anterior, estoy cansado, no he cenado aún y estoy de mal humor. Vamos, cuando menos te apetece y cuando más fácil puedes meter la pata y convertir un problema en un auténtico problemón.
¿Qué hacer?. Se trata de una máquina en producción, y de las "importantes" (está pendiente tener una máquina "clon" lista para entrar a funcionar cuando termine de refinar ésta).
Lo primero que uno piensa es que alguno de los parches que acabo de instalar, algunos de los cuales son "drivers" de bajo nivel, tiene problemas. Bueno, ésto es Solaris con ZFS, así que tengo el sistema bien montado con bastantes "datasets" y con "snapshots" frecuentes. En particular, el sistemas operativo y los "root" de las Zonas Solaris están en sus propios "datasets", así que puedo hacer un "rollback" a una versión previa, antes de los parches "problemáticos". Por supuesto, un "rollback" supone perder los cambios realizados, pero tengo más o menos controlado lo que he ido haciendo, y los datos en sí están en "datasets" separados, a los que no haré "rollback".
Dado que el modo a prueba de fallos no me reconoce el "pool" ZFS, arranco otra vez el Linux con la máquina virtual y el DVD de Solaris. Aquí sí me reconoce perfectamente el "pool". Hago un "rollback" de cinco "datasets" seleccionados. Vuelvo así a una versión previa del sistema operativo (incluyendo las Zonas Solaris), previa a los parches que acabo de instalar y que asumo son problemáticos. El GRUB no se ve afectado, porque se instala en el sector de arranque, no en un "dataset" ZFS.
Reinicio la máquina en modo nativo... Y mismo problema. Intentando arrancar en modo normal el ordenador entra en un ciclo de arranque, carga del SO y reinicio. En modo "a prueba de errores" sigue sin reconocerme el "pool". No obstante sé que el "pool" funciona correctamente, porque cuando arranco el sistema virtualizado, todos mis datos están ahí.
¿Qué diablos está pasando?. He hecho un "rollback" a una versión previa y sigue fallando. He deshecho cambios para nada. Obviamente el parche problemático es anterior. Puedo empezar a retroceder más en el pasado (tengo un histórico de "snapshots" de, al menos, uno al mes), pero si empiezo a sacrificar cambios de configuración que hice hace semanas y no recuerdo volver a hacer, puedo dejar la máquina en un estado indeseado (por ejemplo, una configuración de cortafuegos inadecuada, porque mis cambios se han "perdido" al retroceder en los "snapshots"). Más aún, si retrocedo más de nueve días, tendré problemas serios, porque retrocederé a una versión del sistema que no es capaz de reconocer el ZFS versión 15, al que he migrado el "pool" nueve días antes.
Decido una huída hacia adelante. Ya que tengo en el sistema virtualizado el DVD de Solaris 10 Update 8, que no he actualizado esa máquina por el problema con las zonas Solaris ya documentado al principio de este texto, y que la máquina está actualmente "caída", me planteo aprovechar la situación para actualizar el sistema operativo desde el DVD. Así que lo arranco e inicio el proceso, para descubrir que si tienes el sistema operativo en "ZFS Root" no puedes actualizarlo desde DVD. Sólo puedes actualizarlo a través de "Live Upgrade", lo que es perfecto y deseable, salvo que te tropieces con este bug, aún no resuelto.
Bien, tengo un sistema que no funciona en absoluto y que, aparentemente, tendré que reinstalar desde cero. Tengo backups, pero está en España y transferir 200 gigas a través de la WAN es, cuando menos, lento (cuando haya máquina de backup, la copia de seguridad estará en local, a 100mbps). No es planteable. En un momento dado, me planteo romper el "mirror", reinstalar el sistema en uno de los discos y, una vez en funcionamiento, montar el segundo disco y recuperar los datos. Sin embargo tengo claro que es un proceso que llevará horas, delicado y que, al no saber cuál es el problema, no tengo garantías de éxito. Pudiera ser que hubiese alguna incompatibilidad hardware con el nuevo sistema, por ejemplo.
¿Qué hacer entonces?. Viendo la hora y mi cansancio, mejor dedicar diez minutos a reflexionar sobre el mejor curso de acción, sin dejarme llevar por las prisas.
Decido que lo mejor es dedicar unos minutos a intentar encontrar la causa última del problema, ya que tal vez sea una chorrada solucionable de forma simple. Arranco la máquina y reconfiguro manualmente el GRUB para arrancar el kernel en modo "verbose" (todo ésto es posible en remoto gracias al KVM). Pero el reinicio borra la pantalla rápidamente y no me da tiempo a leer nada. Lo que está claro es que el fallo es en un "driver" que se carga muy al principio del arranque del sistema operativo, justo después de inicializar el sistema de disco.
Se me ocurre arrancar el kernel "normal", pero en modo "single user" y usando la "ramdisk" del modo a prueba de fallos. No funciona porque el kernel normal es 64 bits, y los drivers y demás de la "ramdisk" de recuperación son de 32 bits. Intento varias combinaciones, sin éxito.
Arranco desde la máquina virtual (donde sí funciona correctamente) e investigo el procedimiento de arranque a prueba de fallos de Solaris, una de esas cosas que sabes cómo funciona pero que nunca has revisado en profundidad. Como ya he dicho más arriba, el arranque a prueba de fallos de Solaris es un kernel y una "ramdisk" separadas del sistema operativo normal (así que no nos los podemos cargar, desconfigurar, etc, "fácilmente"). El sistema arranca con un kernel y una "ramdisk" reconocidamente "buenas", que sabemos que funciona correctamente, por mucho que hayamos destrozado el sistema operativo real (de ahí la ventaja de que estén separados). La "ramdisk" contiene las utilidades mínimas para poder solventar problemas "normales". El problema es que cuando arranco con este entorno, no me reconoce el "pool" ZFS, así que poco puedo hacer para solucionar nada.
Durante este proceso de investigación me fijo que el kernel usado por la recuperación tiene fecha de julio de 2009. El kernel "normal" del sistema operativo tiene fecha de septiembre. Ese kernel soporta ZFS versión 15. Obviamente un kernel de julio no puede soportar dicha versión ZFS. Vaya, aparentemente la instalación de los parches ZFS ha actualizado el kernel normal, pero NO actualizó ni el GRUB (ya comentado antes) ni el kernel de recuperación a prueba de fallos.
Vaya.
Como tengo máquinas ya actualizadas a Solaris 10 Update 8, es planteable copiar su entorno de arranque a prueba de fallos (que compruebo que sí está correctamente actualizado) a la máquina problemática. Pero tengo que hacerlo desde el entorno virtualizado, que no tiene configurada la red, ni el cortafuegos, ni nada de nada. Además, cualquier cambio que haga en la configuración de Solaris, como configurar una tarjeta de red nueva o definir servidores de DNS o arranque por DHCP, tengo que deshacerla luego, cuando arranque la máquina en modo nativo.
¿No hay alguna otra forma mejor?.
Tras pensarlo unos minutos, se me ocurre que ya tengo un entorno de arranque capaz de reconocer ZFS versión 15 a mano: la ISO del DVD de Solaris 10 Update 8, que tengo vinculada a la máquina virtual. Así que arranco desde el DVD, monto el disco para poder examinarlo y estudio su forma de arranque.
Por fin encuentro el directorio "boot" en el DVD, que es el entorno de arranque mínimo. Monto el "pool" y copio el directorio en cuestión en el disco duro. Mi menú GRUB normal no es capaz de arrancar ese modo a prueba de fallos nuevo, porque la estructura del mismo ha cambiado, pero nada que no se pueda cambiar manualmente desde el KVM. Además, no me interesa cambiar el "menu.lst" del sistema.
¡¡¡Funciona!!!. Con unos retoques en el GRUB, que baso en el "menu.lst" de mis máquinas actualizadas, el nuevo modo a prueba de fallos arranca correctamente, y reconoce ZFS versión 15 sin problemas. ¡Parece que se ve la luz al final del túnel!.
Una vez que arrancamos la versión a prueba de fallos y montamos el "pool" real del sistema operativo, procedemos a hacer un "reconfigure" y a recrear el "boot_archive" (la "ramdisk" de arranque). Reiniciamos la máquina y... ¡¡funciona!!.
Luego invierto un par de horas reinstalando parches y rehaciendo cambios que perdimos al hacer el "rollback", así como asegurándome de que todo funciona correctamente. Reinicio la máquina varias veces, para ir sobre seguro. Una vez que estoy razonablemente seguro de que todo va sobre ruedas, hago un "snapshot", renombro "/boot" a "/z-boot-Solaris10U8" por si vuelvo a necesitarlo en el futuro, y recupero el "/boot" original de un "snapshot" previo, para que no haya problemas con posibles futuros "parcheos" del sistema.
Se acabó el stress. A dormir, a las 10 de la mañana del domingo.
Como siempre, lo más difícil es diagnosticar el problema. Una vez que comprendí que el arranque a prueba de fallos no estaba lo bastante actualizado como para reconocer un "pool" con ZFS 15, los pasos a dar son evidentes. Por el camino, claro, uno prueba más hipótesis, como que un parche instalado da problemas, que un driver nuevo tiene alguna incompatibilidad, que la máquina ha desarrollado algún tipo de problema hardware... No se me ocurrió que un parche que dote a Solaris 10 Update 7 de la capacidad de manejar "pools" con ZFS 15 se podría haber "olvidado" de actualizar también el entorno de recuperación a prueba de errores.
Mis conclusiones son:
Puedes actualizar otros "pools" sin problemas, no obstante. Por ejemplo, discos externos, pendrives, otros "pools" en los discos duros, etc. Lo importante es que el "pool" de arranque no se actualice porque a) el GRUB no se actualiza y b) el sistema de arranque a prueba de fallos tampoco se actualiza.
Un usuario experimentado conocedor del problema, claro, puede actualizar el "pool" de arranque si actualiza también el GRUB y el sistema de arranque a prueba de fallos, preferiblemente en otro "path" distinto del normal, para no destruir el arranque a prueba de fallos "por defecto"; incompatible, pero no queremos tener problemas con futuros parches.
En mi caso, si hubiese reiniciado tras actualizar el "pool" me hubiera encontrado con el problema del GRUB inmediatamente, y la causa hubiera sido obvia.
Como prometió, Sun ha publicado una actualización que soluciona el problema, a mediados de diciembre de 2009. Se trata del parche 121431-44, disponible de forma pública aunque no tengamos un contrato de mantenimiento con Sun. Este parche soluciona los siguientes problemas:
Una vez instalado el parche, podemos realizar una actualización vía Live Upgrade de forma normal y corriente. ¿O no?. Pues no...
Más información sobre los OpenBadges
Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS
