J'ai réussi à créer un RAID (mise en miroir) en utilisant mdadm. Cependant, je dois exécuter les commandes suivantes après chaque démarrage:
mdadm --stop --scan // to stop /dev/md127 - I don't know where the number 127 even comes from
mdadm --assemble --scan // to start /dev/md0
Qu'est-ce que je fais mal / pourquoi dois-je exécuter ces commandes au démarrage? Quelle est la bonne façon de démarrer automatiquement le RAID à chaque démarrage / réinitialisation?
Réponses:
NB: Vous devez soit être connecté en tant que root, soit utiliser sudo pour faire tout cela ...
Si le fichier n'existe même pas, collez ce qui suit dans le nouveau fichier vide:
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#
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 root
# definitions of existing MD arrays
Sauvegarder le fichier
Exécutez la commande suivante pour ajouter une référence à votre configuration de tableau à la fin du fichier:
mdadm --detail --scan >> /etc/mdadm/mdadm.conf
Cela devrait ajouter une ligne comme celle-ci à la fin de mdadm.conf:
ARRAY / dev / md0 level = raid5 num-devices = 3 métadonnées = 00,90 UUID = a44a52e4: 0211e47f: f15bce44: 817d167c
Si la commande mdadm a ajouté un élément au-dessus de la ligne ARRAY, supprimez-le. Par exemple, sur l'une de mes machines, la commande retourne 'mdadm: format de métadonnées 00.90 inconnu, ignoré.' avant la ligne ARRAY.
Votre tableau devrait maintenant se construire automatiquement au démarrage et vous pouvez donc ajouter une entrée à / etc / fstab pour le monter (si ce n’est pas déjà fait)
mdadm -Esplutôt.
grub-install /dev/sdapour que cela fonctionne (remplace sda par tout ce qui vous convient)
md.auto=1... Je n'ai pas vraiment testé cela à fond, mais il est supposé qu'il les détecte et les assemble (ou du moins tente de le faire). Mais alors kernel.org/doc/html/v4.15/admin-guide/md.html est un peu ambigu sur ce point: lorsque md est compilé dans le noyau (pas en tant que module), les partitions de type 0xfd sont analysées et assemblées automatiquement. dans des matrices RAID. [...] Depuis le noyau 2.6.9, seuls les lecteurs avec un superbloc de type 0 peuvent être détectés automatiquement et exécutés au démarrage. Et cela ne fait pas référence à md.auto (ou quoi que ce soit d'autre), donc je ne suis pas sûr pour le moment.
Je me rends compte que c’est une question plus ancienne, mais j’ai passé un moment frustrant avec cette version 32 bits d’Ubuntu Server 12.04.
Running mdadm --detail --scan >> /etc/mdadm/mdadm.confajouté à la ligne
ARRAY / dev / md0 métadonnées = 1.2 nom = ubuntu: 0 UUID = a8a570c6: 96f61865: 05abe131: 5c2e2f7e
Après un redémarrage, je ne pouvais jamais voir / dev / md0. Lancer à mdadm --detail --scannouveau (sans mettre le résultat dans un fichier), je verrais bien
ARRAY / dev / md / ubuntu: 0 métadonnées = 1.2 nom = ubuntu: 0 UUID = a8a570c6: 96f61865: 05abe131: 5c2e2f7e
et le montage manuel /dev/md/ubuntu:0fonctionnerait. En fin de compte, c’est aussi ce que j’ai mis dans le fichier fstab.
Je ne suis pas sûr de comprendre ce qui m'est arrivé, si c'est ainsi que cela fonctionne dans Ubuntu 12.04 ou s'il s'agit d'une mauvaise pratique. Je voulais juste partager ce qui a fonctionné pour moi.
Sur Debian Wheezy, une étape supplémentaire est requise: pour /etc/default/mdadmdéfinir le démarrage automatique de false à true
#AUTOSTART: # devrait mdadm démarrer les tableaux listés dans /etc/mdadm/mdadm.conf automatiquement # pendant le démarrage? AUTOSTART = true
De plus, je devais utiliser mdadm -Es >>/etc/mdadm/mdadm.confl' --scanoption à la place, car cela ne fonctionnait pas pour moi.
sudo mdadm -Es >> /etc/mdadm/mdadm.conf
Modifiez maintenant les lignes ajoutées à /etc/mdadm/mdadm.conf de la manière suivante. Supprimer tout, sauf les éléments de base. Il devrait ressembler à
ARRAY /dev/md5 UUID=031cea92:50a7a28c:6b077fe7:8817092a
ARRAY /dev/md6 UUID=53454954:4044eb66:9169d1ed:40905643
Remarque: vous pouvez choisir X dans mdX à votre convenance.
Maintenant redémarrer
sudo update-initramfs -u
sudo reboot
EDIT: commande corrigée.
J'ai eu ce problème sur mon Raspberry Pi 2 sous Raspbian GNU / Linux 8 (Jessie). J'ai eu une matrice RAID sur /dev/sda1et /dev/sdb1qui n'a pas réussi à assembler au démarrage. J'avais dans mon /etc/mdadm/mdadm.confdossier l'entrée
ARRAY /dev/md/0 metadata=1.2 UUID=53454954:4044eb66:9169d1ed:40905643 name=raspberrypi:0
(vos chiffres seront différents; voir les autres réponses pour savoir comment l'obtenir.)
J'avais dans mon /etc/fstabdossier l'entrée
/dev/md0 /data ext4 defaults 0 0
(et bien sûr /dataexistait)
À l'instar de l'OP, je pouvais assembler et monter manuellement la matrice RAID après le démarrage, mais je ne pouvais pas que cela se produise automatiquement pendant le démarrage, même si apparemment elle avait été correctement configurée.
J'ai pu résoudre le problème comme suit. J'ai examiné le script à /etc/init.d/mdadm-raidet inséré une ligne de code de débogage
ls /dev > /home/pi/devices.txt
Redémarrages et des vérifier ce fichier j'ai appris que les appareils /dev/sdaet /dev/sdbexistais au moment de l' mdadm-raidinitialisation est arrivé, mais les partitions /dev/sda1et /dev/sdb1ont été portés disparus. J'ai édité le /etc/init.d/mdadm-raidfichier et inséré la ligne
partprobe
après l’en-tête (c’est-à-dire après ### END INIT INFOmais avant le début du script). Cela a provoqué la détection des partitions et le mdadm-raidscript a donc pu assembler la matrice RAID, résolvant ainsi le problème. J'espère que cela aide quelqu'un!
Je me suis battu avec cela sur Raspbian en utilisant deux disques durs USB externes sur un Raspberry Pi. J'ai dû modifier l'ordre de démarrage des services pour m'assurer que mdadm-raid a bien démarré après la reconnaissance des clés USB par udev mais avant checkfs.sh (qui vérifie les systèmes de fichiers au démarrage). Si mdadm-raid a démarré trop tôt, les disques n'étaient pas disponibles et le module n'était donc pas assemblé. Cela signifiait que fsck avait ensuite échoué et que le processus de démarrage avait été abandonné en raison d'une invite de maintenance (car le tableau RAID était requis pour d'autres services).
La modification des dépendances d’amorçage pour démarrer mdadm-raid après checkroot.sh mais avant checkfs.sh et en cours d’exécution update-rc.d mdadm-raid defaults, suivie de update-initramfs -uv -k `uname -r`(annotez les pseudos autour uname), a résolu le problème (enfin). Pour moi, en tout cas, YMMV.
Avoir le Raspberry Pi 3, en ajoutant le rootdelay=5à /boot/cmdline.txtrésolu ce problème pour moi.
Le crédit va ici .
update-initramfs -u