Comment faire fonctionner à nouveau un périphérique RAID inactif?

Après le démarrage, mon périphérique RAID1 ( /dev/md_d0*) passe parfois dans un état drôle et je ne peux pas le monter.

^{* À l'origine, j'ai créé, /dev/md0mais il s'est en quelque sorte transformé en /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

Le périphérique RAID semble être inactif d'une manière ou d' une autre:

# 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 question est de savoir comment réactiver l'appareil (en utilisant mdmadm, je présume)?

(D'autres fois, il est correct (actif) après le démarrage, et je peux le monter manuellement sans problème. Mais il ne se montera toujours pas automatiquement même si je l'ai dans /etc/fstab:

/dev/md_d0        /opt           ext4    defaults        0       0

Donc, une question bonus: que dois-je faire pour que le périphérique RAID se monte automatiquement /optau démarrage? )

Il s'agit d'une station de travail Ubuntu 9.10. Informations générales sur ma configuration RAID dans cette question .

Edit : Mon /etc/mdadm/mdadm.confressemble à ceci. Je n'ai jamais touché ce fichier, du moins à la main.

# 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

Dans /proc/partitionsla dernière entrée se trouve md_d0au moins maintenant, après le redémarrage, lorsque l'appareil se trouve être à nouveau actif. (Je ne sais pas si ce serait la même chose quand il est inactif.)

Résolution : comme Jimmy Hedman l'a suggéré , j'ai pris la sortie de mdadm --examine --scan:

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

et l'ajoute /etc/mdadm/mdadm.conf, ce qui semble avoir résolu le problème principal. Après avoir changé /etc/fstabpour réutiliser /dev/md0(au lieu de /dev/md_d0), le périphérique RAID est également monté automatiquement!

Pour votre question bonus:

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

J'ai constaté que je dois ajouter le tableau manuellement /etc/mdadm/mdadm.confafin de le faire monter par Linux au redémarrage. Sinon, j'obtiens exactement ce que vous avez ici - des md_d1appareils inactifs, etc.

Le fichier conf devrait ressembler à ci-dessous - c'est-à-dire une ARRAYligne pour chaque périphérique md. Dans mon cas, les nouveaux tableaux manquaient dans ce fichier, mais si vous les avez répertoriés, ce n'est probablement pas une solution à votre problème.

# 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

Ajoutez un tableau par périphérique md et ajoutez-les après le commentaire inclus ci-dessus, ou si aucun commentaire n'existe, à la fin du fichier. Vous obtenez les UUID en faisant 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

Comme vous pouvez le voir, vous pouvez à peu près simplement copier la sortie du résultat de l'analyse dans le fichier.

Je lance ubuntu desktop 10.04 LTS, et pour autant que je me souvienne, ce comportement diffère de la version serveur d'Ubuntu, mais il y a si longtemps que j'ai créé mes périphériques md sur le serveur, je me trompe peut-être. Il se peut aussi que je viens de rater une option.

Quoi qu'il en soit, l'ajout du tableau dans le fichier conf semble faire l'affaire. J'ai exécuté le raid 1 et le raid 5 ci-dessus pendant des années sans aucun problème.

Avertissement: Tout d'abord, permettez-moi de dire que ce qui suit (en raison de l'utilisation de "--force") me semble risqué, et si vous avez des données irrécupérables, je vous recommande de faire des copies des partitions concernées avant de commencer à essayer l'une des les choses ci-dessous. Cependant, cela a fonctionné pour moi.

J'ai eu le même problème, avec un tableau apparaissant comme inactif, et rien de ce que j'ai fait, y compris le "mdadm --examine --scan> /etc/mdadm.conf", comme suggéré par d'autres ici, n'a aidé du tout.

Dans mon cas, quand il a essayé de démarrer la matrice RAID-5 après un remplacement de disque, il disait qu'il était sale (via 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.

Le faire apparaître comme inactif dans /proc/mdstat:

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

J'ai trouvé que tous les appareils avaient les mêmes événements, sauf le lecteur que j'avais remplacé ( /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

Cependant, les détails de la baie ont montré qu'il y avait 4 appareils sur 5 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

(Ce qui précède provient de la mémoire de la colonne "État", je ne le trouve pas dans mon tampon de défilement).

J'ai pu résoudre ce problème en arrêtant le tableau puis en le réassemblant:

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

À ce stade, la baie était en place, fonctionnant avec 4 des 5 périphériques, et j'ai pu ajouter le périphérique de remplacement et sa reconstruction. Je peux accéder au système de fichiers sans aucun problème.

J'avais des problèmes avec Ubuntu 10.04 où une erreur dans FStab empêchait le serveur de démarrer.

J'ai exécuté cette commande comme mentionné dans les solutions ci-dessus:

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

Cela ajoutera les résultats de "mdadm --examine --scan" à "/etc/mdadm/mdadm.conf"

Dans mon cas, c'était:

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

Il s'agit d'un fakeraid 0. Ma commande dans / etc / fstab pour le montage automatique est:

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

La chose importante ici est que vous avez "nobootwait" et "nofail". Nobootwait ignorera tous les messages système qui vous empêchent de démarrer. Dans mon cas, c'était sur un serveur distant, donc c'était essentiel.

J'espère que cela aidera certaines personnes.

Vous pouvez activer votre appareil md avec

mdadm -A /dev/md_d0

Je suppose qu'un script de démarrage démarre trop tôt, avant que l'un des membres du RAID ne soit découvert ou un problème similaire. Comme solution de contournement rapide et sale, vous devriez pouvoir ajouter cette ligne à /etc/rc.local:

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

Modifier: apparemment, votre /etc/mdadm/mdadm.conf contient toujours l'ancien nom de configuration. Modifiez ce fichier et remplacez les occurrences de md0 par md_d0.

md_d0 : inactive sda4[0](S)semble incorrect pour une matrice RAID1. Il semble suggérer que la matrice n'a pas de périphériques actifs et un périphérique de rechange ^{_{(indiqué par le (S), vous}} verriez ^{_{(F) là pour un périphérique défectueux et rien pour un périphérique OK / actif)}} - pour une matrice RAID1 qui n'est pas ne fonctionne pas dégradé, il devrait y avoir au moins deux périphériques OK / actifs ^{_{(et pour une matrice dégradée, au moins un périphérique OK / actif)}} et vous ne pouvez pas activer une matrice RAID1 sans aucun périphérique non disponible non défaillant (comme pièces de rechange ne contiennent pas de copie des données tant qu'elles ne sont pas rendues actives lorsqu'un autre disque tombe en panne). Si je lis bien cette /proc/mdstatsortie, vous ne pourrez pas activer le tableau dans son état actuel.

La machine contient-elle des disques physiques qui n'ont pas pu tourner? Répertorie ls /dev/sd*tous les lecteurs et partitions que vous attendez normalement de voir sur cette machine?

J'ai eu un problème similaire ... mon serveur ne montait pas md2 après avoir développé les partitions des périphériques associés. En lisant ce fil, j'ai trouvé que le périphérique RAID md2 avait un nouvel UUID et que la machine essayait d'utiliser l'ancien.

Comme suggéré ... en utilisant la sortie 'md2' de

mdadm --examine --scan

J'ai modifié /etc/mdadm/mdadm.confet remplacé l'ancienne ligne UUID par la seule sortie de la commande ci-dessus et mon problème a disparu.

Lorsque vous faites semblant de faire quelque chose avec, /dev/md[012346789}cela va /dev/md{126,127...}. /dev/md0continue monté à /dev/md126ou /dev/md127vous devez:

umount /dev/md127 ou umount /dev/md126.

Ceci est temporaire pour vous permettre d'exécuter des commandes et certaines applications sans arrêter votre système.

Un moyen simple de faire fonctionner la baie en supposant qu'il n'y a pas de problème matériel et que vous disposez de suffisamment de lecteurs / partitions pour démarrer la baie est le suivant:

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

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

Il se peut que pour quelque raison que ce soit, le tableau est correct, mais quelque chose l'a empêché de démarrer ou de se construire. Dans mon cas, c'était parce que mdadm ne savait pas que le nom d'origine de la baie était md127 et que tous les disques étaient débranchés pour cette baie. Lors de la réinstallation, j'ai dû assembler manuellement (probablement un bogue où mdadm pensait que la baie était déjà active en raison de l'ancien nom de la baie hors ligne).