¿Cómo hacer que un dispositivo RAID inactivo vuelva a funcionar?

Después del arranque, mi dispositivo RAID1 ( /dev/md_d0*) a veces se ve en un estado extraño y no puedo montarlo.

^{* Originalmente creé, /dev/md0pero de alguna manera se ha transformado /dev/md_d0.}

# mount /opt
mount: wrong fs type, bad option, bad superblock on /dev/md_d0,
       missing codepage or helper program, or other error
       (could this be the IDE device where you in fact use
       ide-scsi so that sr0 or sda or so is needed?)
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

El dispositivo RAID parece estar inactivo de alguna manera:

# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] 
                [raid4] [raid10] 
md_d0 : inactive sda4[0](S)
      241095104 blocks

# mdadm --detail /dev/md_d0
mdadm: md device /dev/md_d0 does not appear to be active.

La pregunta es, ¿cómo volver a activar el dispositivo (usando mdmadm, supongo)?

(Otras veces está bien (activo) después del arranque, y puedo montarlo manualmente sin problemas. Pero aún no se montará automáticamente aunque lo tenga en /etc/fstab:

/dev/md_d0        /opt           ext4    defaults        0       0

Entonces, una pregunta adicional: ¿qué debo hacer para que el dispositivo RAID se monte automáticamente /opten el momento del arranque? )

Esta es una estación de trabajo Ubuntu 9.10. Información básica sobre mi configuración RAID en esta pregunta .

Editar : mi /etc/mdadm/mdadm.confaspecto es así. Nunca he tocado este archivo, al menos a mano.

# by default, scan all partitions (/proc/partitions) for MD superblocks.
# alternatively, specify devices to scan, using wildcards if desired.
DEVICE partitions

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR <my mail address>

# definitions of existing MD arrays

# This file was auto-generated on Wed, 27 Jan 2010 17:14:36 +0200

En /proc/partitionsla última entrada es md_d0al menos ahora, después del reinicio, cuando el dispositivo vuelve a estar activo. (No estoy seguro de si sería lo mismo cuando está inactivo).

Resolución : como sugirió Jimmy Hedman , tomé el resultado de mdadm --examine --scan:

ARRAY /dev/md0 level=raid1 num-devices=2 UUID=de8fbd92[...]

y lo agregó /etc/mdadm/mdadm.conf, lo que parece haber solucionado el problema principal. Después de cambiar /etc/fstabpara usar /dev/md0nuevamente (en lugar de /dev/md_d0), el dispositivo RAID también se monta automáticamente.

Para su pregunta extra:

mdadm --examine --scan >> /etc/mdadm/mdadm.conf

He descubierto que tengo que agregar la matriz manualmente /etc/mdadm/mdadm.confpara que Linux la monte al reiniciar. De lo contrario, obtengo exactamente lo que tienes aquí: md_d1dispositivos que están inactivos, etc.

El archivo conf debería verse a continuación, es decir, una línea ARRAYpara cada dispositivo md. En mi caso, faltaban las nuevas matrices en este archivo, pero si las tiene en la lista, esto probablemente no sea una solución a su problema.

# definitions of existing MD arrays
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=f10f5f96:106599e0:a2f56e56:f5d3ad6d
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa591bbe:bbbec94d:a2f56e56:f5d3ad6d

Agregue una matriz por dispositivo md y agréguelos después del comentario incluido anteriormente, o si no existe dicho comentario, al final del archivo. Obtiene los UUID haciendo sudo mdadm -E --scan:

$ sudo mdadm -E --scan
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=f10f5f96:106599e0:a2f56e56:f5d3ad6d
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa591bbe:bbbec94d:a2f56e56:f5d3ad6d

Como puede ver, puede copiar el resultado del escaneo en el archivo.

Ejecuto ubuntu desktop 10.04 LTS, y hasta donde recuerdo este comportamiento difiere de la versión del servidor de Ubuntu, sin embargo, hace mucho tiempo que creé mis dispositivos md en el servidor, puedo estar equivocado. También puede ser que me haya perdido alguna opción.

De todos modos, agregar la matriz en el archivo conf parece ser el truco. He ejecutado la incursión 1 y la incursión 5 anteriores durante años sin problemas.

Advertencia: En primer lugar, permítame decir que lo siguiente (debido al uso de "--force") me parece arriesgado, y si tiene datos irrecuperables, le recomiendo hacer copias de las particiones involucradas antes de comenzar a intentar cualquiera de Las cosas de abajo. Sin embargo, esto funcionó para mí.

Tuve el mismo problema, con una matriz que se mostraba como inactiva, y nada de lo que hice incluyendo el "mdadm --examine --scan> /etc/mdadm.conf", como lo sugirieron otros aquí, ayudó en absoluto.

En mi caso, cuando intentó iniciar la matriz RAID-5 después de un reemplazo de unidad, decía que estaba sucia (vía dmesg):

md/raid:md2: not clean -- starting background reconstruction
md/raid:md2: device sda4 operational as raid disk 0
md/raid:md2: device sdd4 operational as raid disk 3
md/raid:md2: device sdc4 operational as raid disk 2
md/raid:md2: device sde4 operational as raid disk 4
md/raid:md2: allocated 5334kB
md/raid:md2: cannot start dirty degraded array.

Causando que aparezca como inactivo en /proc/mdstat:

md2 : inactive sda4[0] sdd4[3] sdc4[2] sde4[5]
      3888504544 blocks super 1.2

Encontré que todos los dispositivos tenían los mismos eventos, excepto la unidad que había reemplazado ( /dev/sdb4):

[root@nfs1 sr]# mdadm -E /dev/sd*4 | grep Event
mdadm: No md superblock detected on /dev/sdb4.
         Events : 8448
         Events : 8448
         Events : 8448
         Events : 8448

Sin embargo, los detalles de la matriz mostraron que tenía 4 de 5 dispositivos disponibles:

[root@nfs1 sr]# mdadm --detail /dev/md2
/dev/md2:
[...]
   Raid Devices : 5
  Total Devices : 4
[...]
 Active Devices : 4
Working Devices : 4
[...]
    Number   Major   Minor   RaidDevice State
       0       8        4        0      inactive dirty  /dev/sda4
       2       8       36        2      inactive dirty  /dev/sdc4
       3       8       52        3      inactive dirty  /dev/sdd4
       5       8       68        4      inactive dirty  /dev/sde4

(Lo anterior es de memoria en la columna "Estado", no puedo encontrarlo en mi búfer de desplazamiento hacia atrás).

Pude resolver esto al detener la matriz y luego volver a ensamblarla:

mdadm --stop /dev/md2
mdadm -A --force /dev/md2 /dev/sd[acde]4

En ese momento, la matriz estaba activa, ejecutándose con 4 de los 5 dispositivos, y pude agregar el dispositivo de reemplazo y se está reconstruyendo. Puedo acceder al sistema de archivos sin ningún problema.

Estaba teniendo problemas con Ubuntu 10.04 donde un error en FStab impidió que el servidor se iniciara.

Ejecuté este comando como se menciona en las soluciones anteriores:

mdadm --examine --scan >> /etc/mdadm/mdadm.conf

Esto agregará los resultados de "mdadm --examine --scan" a "/etc/mdadm/mdadm.conf"

En mi caso, esto fue:

ARRAY /dev/md/0 metadata=1.2 UUID=2660925e:6d2c43a7:4b95519e:b6d110e7 name=localhost:0

Este es un 0 falso. Mi comando en / etc / fstab para el montaje automático es:

/dev/md0 /home/shared/BigDrive ext3 defaults,nobootwait,nofail 0 0

Lo importante aquí es que tiene "nobootwait" y "nofail". Nobootwait omitirá los mensajes del sistema que le impiden iniciar. En mi caso, esto estaba en un servidor remoto, por lo que era esencial.

Espero que esto ayude a algunas personas.

Puede activar su dispositivo md con

mdadm -A /dev/md_d0

Supongo que algunos scripts de inicio comienzan demasiado pronto, antes de que se descubra uno de los miembros RAID o algún problema similar. Como una solución rápida y sucia, debería poder agregar esta línea a /etc/rc.local:

mdadm -A /dev/md_d0 && mount /dev/md_d0

Editar: aparentemente su /etc/mdadm/mdadm.conf todavía contiene el antiguo nombre de configuración. Edite este archivo y reemplace las ocurrencias de md0 con md_d0.

Tuve un problema similar ... mi servidor no montaría md2 después de que creciera las particiones de dispositivos asociados. Al leer este hilo descubrí que el dispositivo RAID md2 tenía un nuevo UUID y que la máquina intentaba usar el viejo.

Como se sugiere ... usando la salida 'md2' de

mdadm --examine --scan

Edité /etc/mdadm/mdadm.confy reemplacé la antigua línea UUID con la salida del comando anterior y mi problema desapareció.

Cuando pretendes hacer algo con /dev/md[012346789}eso va a /dev/md{126,127...}. /dev/md0continúa montado en /dev/md126o /dev/md127tienes que:

umount /dev/md127 o umount /dev/md126.

Esto es temporal para permitirle ejecutar comandos y algunas aplicaciones sin detener su sistema.

md_d0 : inactive sda4[0](S)se ve mal para una matriz RAID1. Parece sugerir que la matriz no tiene dispositivos activos y un dispositivo de repuesto ^{_{(indicado por (S), vería (F) allí para un dispositivo fallido y nada para un dispositivo OK / activo)}} - para una matriz RAID1 que no es No se debe ejecutar degradado, debe haber al menos dos dispositivos OK / activos ^{_{(y para una matriz degradada, al menos un dispositivo OK / activo)}} y no se puede activar una matriz RAID1 sin dispositivos sin fallas y sin fallas (como repuestos no contenga una copia de los datos hasta que se activen cuando falle otra unidad). Si estoy leyendo esa /proc/mdstatsalida correctamente, no podrá activar la matriz en su estado actual.

¿Tiene alguna unidad física en la máquina que no haya podido girar? ¿ ls /dev/sd*Enumera todas las unidades y particiones que normalmente esperaría ver en esa máquina?

Una manera simple de hacer que la matriz se ejecute suponiendo que no haya problemas de hardware y que tenga suficientes unidades / particiones para iniciar la matriz es la siguiente:

md20 : inactive sdf1[2](S)
      732442488 blocks super 1.2

 sudo mdadm --manage /dev/md20  --run

Podría ser que, por cualquier razón, la matriz está bien, pero algo le impidió comenzar o construir. En mi caso, esto se debió a que mdadm no sabía que el nombre original de la matriz era md127 y que todas las unidades estaban desconectadas para esa matriz. Al volver a conectar tuve que ensamblar manualmente (probablemente un error en el que mdadm pensaba que la matriz ya estaba activa debido al antiguo nombre de la matriz fuera de línea).