Comment faire pour un nouveau RAID inactif?
Après le démarrage, mon périphérique RAID1 (/dev/md_d0 *) se met parfois dans un état étrange et je ne peux pas le monter.
* A l'origine, j'ai créé /dev/md0 mais 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 en quelque sorte:
# 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, comment rendre le périphérique actif à nouveau (en utilisant mdmadm, je présume)?
(Parfois, c'est correct (actif) après le démarrage, et je peux le monter manuellement sans problèmes. Mais il ne sera toujours pas monté 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 à /opt au démarrage? )
Ceci est une station de travail Ubuntu 9.10. Informations de base sur ma configuration RAID dans cette question .
Modifier : Mon /etc/mdadm/mdadm.conf ressemble à ceci. Je n'ai jamais touché à ce dossier, 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/partitions, la dernière entrée est md_d0 au moins maintenant, après le redémarrage, lorsque le périphérique est à nouveau actif. (Je ne sais pas si ce serait la même chose quand c'est inactif.)
Résolution : comme Jimmy Hedman a suggéré , j'ai pris la sortie de mdadm --examine --scan:
ARRAY /dev/md0 level=raid1 num-devices=2 UUID=de8fbd92[...]
et l'a ajouté dans /etc/mdadm/mdadm.conf, ce qui semble avoir résolu le problème principal. Après avoir modifié /etc/fstab pour utiliser /dev/md0 à nouveau (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 devais ajouter le tableau manuellement dans /etc/mdadm/mdadm.conf pour que Linux le monte au redémarrage. Sinon, je reçois exactement ce que vous avez ici - md_d1- périphériques inactifs, etc.
Le fichier de configuration devrait ressembler à ce qui suit: c’est-à-dire une ligne ARRAY 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 md-device, et ajoutez-les après le commentaire inclus ci-dessus ou, à défaut, à 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 constater, vous pouvez copier le résultat du résultat de l'analyse dans le fichier.
Je lance ubuntu desktop 10.04 LTS et, autant que je m'en souvienne, ce comportement diffère de la version du serveur d'Ubuntu. Cependant, il y a si longtemps que j'ai créé mes périphériques md sur le serveur, je peux me tromper. Peut-être aussi que j'ai juste manqué une option.
Quoi qu'il en soit, l'ajout du tableau dans le fichier de configuration semble faire l'affaire. J'ai couru les raids 1 et 5 ci-dessus pendant des années sans aucun problème.
Avertissement: Tout d’abord, permettez-moi de dire que le texte ci-dessous (en raison de l'utilisation de "--force") semble risqué pour moi, et si 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 baie de disques RAID-5 après le remplacement d'un disque, il disait que c'é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 constaté que tous les périphériques comportaient les mêmes événements, à l'exception du 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 matrice ont montré que 4 périphériques sur 5 étaient 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 dans la colonne "Etat", je ne le trouve pas dans mon tampon de défilement arrière).
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 opérationnelle et fonctionnait avec 4 des 5 périphériques. J'ai pu ajouter le périphérique de remplacement et le reconstruire. Je peux accéder au système de fichiers sans aucun problème.
J'avais des problèmes avec Ubuntu 10.04 lorsqu'une erreur dans FStab empêchait le serveur de démarrer.
J'ai exécuté cette commande comme indiqué dans les solutions ci-dessus:
mdadm --examine --scan >> /etc/mdadm/mdadm.conf
Ceci annexera 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
Ceci est un fakeraid 0. Ma commande dans /etc/fstab pour un montage automatique est la suivante:
/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.
Lorsque vous prétendez faire quelque chose avec /dev/md[012346789}, il passe à /dev/md{126,127...}. /dev/md0 continue de monter à /dev/md126 ou /dev/md127 vous 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.
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 qu'un des membres du RAID ne soit découvert ou un problème similaire. Pour contourner le problème rapidement et correctement, vous devriez pouvoir ajouter cette ligne à /etc/rc.local:
mdadm -A /dev/md_d0 && mount /dev/md_d0
Edit: apparemment, votre /etc/mdadm/mdadm.conf contient toujours l’ancien nom de la 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 développé les partitions de périphériques associés. En lisant ce fil, j'ai découvert 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 édité /etc/mdadm/mdadm.conf et remplacé l'ancienne ligne UUID par la sortie de la commande ci-dessus et mon problème est parti.
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 en panne et rien pour un périphérique OK/actif) - pour une matrice RAID1 qui ne fonctionne pas, il doit y avoir au moins deux périphériques OK/actifs (et pour un tableau dégradé, au moins un périphérique OK/actif) et vous ne pouvez pas activer une grappe RAID1 sans aucun périphérique non-épargné sans défaillance (les disques de secours ne contenant pas de copie des données tant qu'ils ne sont pas rendus actifs en cas de panne d'un autre lecteur). Si je lis bien cette sortie de /proc/mdstat, vous ne pourrez pas activer le tableau dans son état actuel.
Avez-vous des disques physiques sur la machine qui ont échoué? ls /dev/sd* répertorie-t-il tous les lecteurs et partitions que vous vous attendriez normalement à voir sur cette machine?
Voici un moyen simple d’exécuter la baie en supposant qu’il n’ya pas de problème matériel et que vous avez suffisamment de lecteurs/partitions pour démarrer la baie:
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 réseau soit correct mais que quelque chose l’empêche de démarrer ou de se construire. Dans mon cas, cela était dû au fait que mdadm ne savait pas que le nom du groupe d'origine était md127 et que tous les lecteurs étaient débranchés pour ce groupe. Lors du rechargement, je devais assembler manuellement (probablement un bogue dans lequel mdadm pensait que le tableau était déjà actif en raison de l'ancien nom du tableau hors ligne).