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?
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)
Je me rends compte que c’est une question plus ancienne, mais j’ai passé un moment frustrant avec cela sur la version 32 bits d’Ubuntu Server 12.04.
En cours d'exécution mdadm --detail --scan >> /etc/mdadm/mdadm.conf
a ajouté 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 à nouveau le mdadm --detail --scan
(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 monter manuellement /dev/md/ubuntu:0
fonctionnerait. 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.
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 un ensemble RAID sur /dev/sda1
et /dev/sdb1
qui n'ont pas pu être assemblés au démarrage. J'ai eu dans mon fichier /etc/mdadm/mdadm.conf
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'ai eu dans mon fichier /etc/fstab
l'entrée
/dev/md0 /data ext4 defaults 0 0
(et bien sûr, /data
existait bien)
À 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-raid
et inséré une ligne de code de débogage
ls /dev > /home/pi/devices.txt
Redémarrage et vérification de ce fichier J'ai appris que les périphériques /dev/sda
et /dev/sdb
existaient au moment de l'initialisation du mdadm-raid
, mais que les partitions /dev/sda1
et /dev/sdb1
étaient manquantes. J'ai édité le fichier /etc/init.d/mdadm-raid
et inséré la ligne
partprobe
après l’en-tête (c’est-à-dire après le ### END INIT INFO
mais avant le début du script). Cela a provoqué la détection des partitions et le script mdadm-raid
a donc pu assembler la matrice RAID, résolvant ainsi le problème. J'espère que cela aide quelqu'un!
Sous Debian Wheezy, une étape supplémentaire est requise: dans /etc/default/mdadm
, définissez le démarrage automatique de false à true
#AUTOSTART: # Mdadm doit-il démarrer les tableaux répertoriés dans /etc/mdadm/mdadm.conf automatiquement # Au démarrage? AUTOSTART = true
De plus, je devais utiliser mdadm -Es >>/etc/mdadm/mdadm.conf
au lieu de l'option --scan
, car cela ne fonctionnait pas pour moi.
J'ai essayé avec
mdadm --create /dev/md/abcdef ...
Je vois le lien symbolique /dev/md/abcdef
persistant au redémarrage et, si besoin est, accéder à l'appareil via un lien virtuel.
Est-ce une solution acceptable?
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é au profit 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 exécuter update-rc.d mdadm-raid defaults
, suivie de update-initramfs -uv -k `uname -r`
(les backticks autour de uname
) a corrigé (enfin). Pour moi, en tout cas, YMMV.
Avoir le Raspberry Pi 3, en ajoutant le rootdelay=5
au /boot/cmdline.txt
a résolu ce problème pour moi.
Le crédit va ici .