web-dev-qa-db-fra.com

Le logiciel Raid0 ne monte pas correctement dans fstab

J'ai créé un Raid0 et tout fonctionne comme prévu. Le fichier de tableau est créé à /dev/md0. Je veux que cela soit monté automatiquement en ajoutant cette ligne à la fin du fichier /etc/fstab:

/dev/md0 /mnt/storage ext4 noatime,commit=60,data=writeback,nodiratime,journal_async_commit,nouser_xattr 0 0

et cette ligne à la fin du /etc/mdadm/mdadm.conf:

ARRAY /dev/md0 metadata=1.2 name=lil-RIKO:lil-RIKO UUID=6016d5e4:6e42cb97:6b2a8e6e:098c1982

Dans Boot time, j'ai vu que/mnt/storage était attendu pour être monté et offrait deux options: Passer ... ou à Ma ... J'ai oublié ce que ça dit. J'ai attendu si longtemps que j'ai pensé que quelque chose n'allait pas. Je suis passé en "mode maintenance" qui est un shell racine puis j'ai rapidement vérifié la présence du fichier /dev/md0. Le fichier n'était pas là, seulement/dev/md127. J'ai essayé de monter ce fichier à la place et il s'est plaint de ne pas trouver un superbloc. J'ai monté manuellement le raid via mdadm --assemble /md0 après avoir supprimé le fichier /dev/md127 via mdadm --stop /dev/md* et j'ai continué à démarrer. Après le redémarrage, j'ai rencontré le même problème.

Comment se fait-il que le raid ne soit pas monté automatiquement? Il n’y avait aucune présence de/dev/md0 au démarrage et j’ai pu le monter manuellement.

EDIT1: J'ai réussi à le "fusionner" en un disque qui s'appelle/dev/md127 en supprimant un disque. Le problème persiste, mais lorsque j'émets ce cat /proc/mdstat j'ai ceci:

md127 : inactive sdc[1](S) sdb[0](S)
      7830528 blocks super 1.2

Cela signifie (je pense) que le raid n'est pas encore activé. Mais quand je le rattache, il devient actif comme ceci:

md127 : active raid0 sdc1[1] sdb1[0]
      7830528 blocks super 1.2 512k chunks

Qu'est-ce qui s'est mal passé cette fois?

bootmountraidfstabmdadm
1
user128712

J'espère que vous avez déjà trouvé une réponse. sinon, je viens de passer par ceci, et la réponse courte est d'éditer vos définitions de tableau à /etc/mdadm/mdadm.conf; essentiellement, supprimez tout ce qui est autre que/dev/md * et UUID = info (supprimez les métadonnées, le nom, etc.). Au redémarrage, vous ne devriez plus avoir le problème md127, md126, etc. avec vos tableaux.

Donc, en fonction de votre ligne ci-dessus, changez

ARRAY /dev/md0 metadata=1.2 name=lil-RIKO:lil-RIKO UUID=6016d5e4:6e42cb97:6b2a8e6e

à

ARRAY /dev/md0 UUID=6016d5e4:6e42cb97:6b2a8e6e
2
todd

Avez-vous pensé à exécuter update-initramfs après avoir assemblé le tableau en tant que md0? Si ce n’est pas le cas, essayez d’arrêter puis de ré-assembler le tableau, puis c’est-à-dire,.

Sudo mdadm --stop /dev/md127
Sudo mdadm --assemble /dev/md0
Sudo update-initramfs -u

Cela devrait rendre le système de fichiers racine initial 'conscient' du tableau au démarrage

2
steeldriver

J'ai rencontré un problème similaire: le montage du tableau md0 dans fstab échoue avec une "erreur grave rencontrée lors de la tentative de montage/mnt/md0" (ou similaire). Frigged avec cela pendant une heure, ne pouvait pas le faire fonctionner. UUID vérifié,/proc/mdstat, mdadm.conf, etc., tout semble aller pour le mieux.

Ajout de l'option nobootwait à fstab pour qu'il ne verrouille pas le processus de démarrage (serveur sans tête)

Cela ressemble à une condition de concurrence, car émettre la commande de montage manuellement après le démarrage fonctionne correctement.

Solution de contournement qui fonctionne pour moi:

modifier rc.local, ajouter la ligne suivante avant la sortie 0

sommeil 10 && montage -t auto/dev/md0/mnt/md0

Sideeffect est que la monture apparaît 10 secondes plus tard, mais je peux vivre avec ça. Sans la commande sleep, cela ne fonctionnait pas.

J'espère que ça aide quelqu'un.

0
Blindfreddy