Comment faire fonctionner à nouveau un appareil RAID inactif ?

Pour votre question bonus :

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

J'ai découvert que je dois ajouter le tableau manuellement en /etc/mdadm/mdadm.conf afin de le faire monter par Linux au redémarrage. Sinon, j'obtiens exactement ce que vous avez ici - md_d1-dispositifs inactifs, etc.

Le fichier conf-file devrait ressembler à ce qui suit - c'est-à-dire une ligne ARRAY pour chaque périphérique md. Dans mon cas, les nouveaux tableaux étaient manquants dans ce fichier, mais si vous les avez listé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 de ce type n'existe, à la fin du fichier. Vous obtenez les UUIDs 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 pratiquement 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, cependant il y a si longtemps que j'ai créé mes md-devices sur le serveur que je peux me tromper. Il se peut aussi que j'aie raté une option.

Quoi qu'il en soit, ajouter le tableau dans le fichier de configuration semble faire l'affaire. J'ai fait les raids 1 et 5 ci-dessus pendant des années sans aucun problème.

Attention: Tout d'abord, laissez-moi vous 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 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'elle é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 faisant 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 périphériques avaient les mêmes événements, sauf le disque 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 du tableau montraient qu'il avait 4 périphériques 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 ma mémoire tampon de défilement).

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

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

A ce moment là, le tableau était en place, fonctionnant avec 4 des 5 périphériques, et j'ai pu ajouter le périphérique de remplacement et il est en cours de 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 va ajouter 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

C'est un fakeraid 0. Ma commande dans /etc/fstab pour le montage automatique est :

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

L'important ici est que vous ayez “nobootwait” et “nofail”. Nobootwait ignorera tous les messages du 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 que certains scripts de démarrage démarrent trop tôt, avant qu'un des membres du RAID ne soit découvert ou qu'un problème similaire ne se produise. Pour contourner ce problème, vous devriez pouvoir ajouter cette ligne dans le fichier /etc/rc.local :

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

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

J'ai eu un problème similaire… mon serveur ne voulait pas monter md2 après avoir fait croître les partitions des périphériques associés. En lisant ce fil de discussion, j'ai découvert que le périphérique RAID md2 avait un nouveau UUID et que la machine essayait d'utiliser l'ancien.

Comme suggéré… en utilisant la sortie ‘md2’ de la commande

mdadm --examine --scan

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

md_d0 : inactive sda4[0](S) ne semble pas convenir à 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 en panne et rien pour un périphérique OK/actif) - pour une matrice RAID1 qui ne fonctionne pas en panne, 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 périphériques non en panne et non de rechange (car les pièces de rechange ne contiennent pas de copie des données jusqu'à ce qu'elles soient rendues actives lorsqu'un autre disque tombe en panne). Si je lis bien cette sortie /proc/mdstat, vous ne pourrez pas activer la matrice dans son état actuel.

Avez-vous des disques physiques dans la machine qui n'ont pas réussi à tourner ? ls /dev/sd* énumère-t-il tous les disques et partitions que vous vous attendez normalement à voir sur cette machine ?

Lorsque vous prétendez faire quelque chose avec /dev/md[012346789} cela passe à /dev/md{126,127...}./dev/md0 continue monté à /dev/md126 ou /dev/md127 vous devez le faire :

umount /dev/md127ou umount /dev/md126.

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

Voici un moyen simple de faire fonctionner le tableau en supposant qu'il n'y ait pas de problème matériel et que vous ayez suffisamment de lecteurs/parties pour lancer le tableau :

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

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

Il se peut que pour une raison quelconque, le tableau fonctionne bien mais que quelque chose l'ait empêché de démarrer ou de se construire. Dans mon cas, c'est parce que mdadm ne savait pas que le nom original du tableau était md127 et que tous les lecteurs étaient débranchés pour ce tableau. Lors du replugging, j'ai dû assembler manuellement (probablement un bug où mdadm pensait que le tableau était déjà actif à cause de l'ancien nom du tableau hors ligne).