Hoy tengo una nueva batallita que contaros sobre configuraciones RAID y LVM en un Debian Lenny (testing). Ya tocaba porque hacia bastante que funcionaba sin ningún problema y eso “no puede ser normal”.

Bromas aparte os recuerdo un poco como está configurada esta máquina:

El servidor incorpora 5 discos duros bastante variados: 1 de 300 GB, 2 de 320 GB y 2 de 500 GB.

El motivo de esta variedad es porque a medida que van fallando o puedo ir ampliando discos los voy sustituyendo por otros de mayor capacidad lo que me permite ir aumentando la capacidad disponible, sobre todo teniendo en cuenta que sobre el software RAID utilizao LVM para gestionar particiones.

El problema me lo he encontrado ahora que he reiniciado la máquina, pero se generó hace ya semanas con un cambio que realicé (y para el que no reinicié en su momento ya que no era necesario).

Antes de ese cambio tenia dos unidades software RAID, md0 y md1. La primera es un simple RAID 1 para /boot sobre 3 dispositivos. El segundo es más interesante, un RAID 5 sobre 5 particiones de cada uno de los discos.

El cambio fue sustituir 2 discos de 320 GB por los actuales 2 de 500 GB y para ir aprovechando el espacio (hasta que pueda disponer de todos en 500GB) utilizaré el espacio sobrante de los de 500GB para crear un RAID 1 de dos particiones.

Bueno, nada más facil. Creé el RAID con mdadm, lo convertí en unidad física LVM con pvcreate y lo añadí a un grupo existente (vg0). Todo funcionaba correctamente hasta que hoy he reiniciado la máquina y me he encontrado que no arranca quejándose de que no puede montar la partición raiz (y unas lineas más arriba el LVM se queja que le falta un dispositivo).

El problema está en que si bien LVM si que hace un escaneo total de todas las particiones y busca las unidades y dispositivos físicos, el software raid se basa en el fichero /etc/mdadm/mdadm.conf para construir los arrays aunque los pueda detectar automáticamente. El problema es que el arranque del Debian me deja un mínimo sistema (busybox) en el que no dispongo del LVM aunque si del mdadm.

Lo siguiente es arrancar con un CD (en este caso tras un kubuntu que no lleva mdadm ni lvm y un debian-installer antiguo que no me reconoce una controladora SATA PCI-Express) acabo consiguiendo arrancar con una imagen nueva del Debian-Installer para testing. Con eso consigo entrar por linea de comandos, construir la unidad y el lvm y acceder a mi /etc.

Una vez en /etc puedo ya editar el mdadm.conf y poner el nuevo array. Grabo fichero, rearranco, y sigue igual. ¡Claro! El mdadm.conf es una de las partes que se copian en la imagen de arranque en memoria (el llamado initramfs). Así que además de modificar el mdadm.conf tengo que actualizar ese initramfs.

Así que vuelta a arrancar con el CD, monto de nuevo la partición raiz y el /var que también necesito, y ejecuto update-initramfs -ut para actualizar la última versión del kernel. De momento no los actualizo todos para probar… no sea el caso que rompamos algo.

Reinicio para probar y arranco con el último kernel. Y ahora si, todo perfecto (aunque con tanto ir y venir el RAID se ha quejado y está reconstruyendo la unidad).

Así que la moraleja de hoy es: si añades un array con mdadm y quieres tenerlo disponible al arrancar, recuerda ejecutar update-initramfs.

Actualización 6/6/08: Para generar fácilmente el fichero mdadm.conf podemos utilizar el comando mdadm –examine –scan