# VBolume RAID non persistant au reboot **URL:** \ **Category:** Support Debian\ **Created:** [Février 12, 2020, 7:28 UTC](https://www.debian-fr.org/t/vbolume-raid-non-persistant-au-reboot/81230 "2020-02-12T07:28:20Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![DonutMan](https://www.debian-fr.org/user_avatar/www.debian-fr.org/donutman/32/7713_2.png) [@DonutMan](https://www.debian-fr.org/u/DonutMan)\ **Post date:** [Février 12, 2020, 7:28 UTC](https://www.debian-fr.org/t/vbolume-raid-non-persistant-au-reboot/81230/1 "2020-02-12T07:28:21Z")
Bonjour, je dispose de deux disques HDD que je souhaite monter en RAID1 sous Debian 10. J’ai suivi [ce tuto](https://www.justegeek.fr/tuto-creer-raid-logiciel-mdadm-debian/) et tout s’est bien déroulé. J’ai créé un système de fichier EXT4 sur mon RAID et j’ai pu y écrire quelques données. Hélas, au reboot mon volume md0 n’apparaît plus ! ``` $ ll /dev/md* ls: impossible d'accéder à '/dev/md*': Aucun fichier ou dossier de ce type ``` Un mdadm scan ne renvoie d’ailleurs plus rien : ``` $ sudo mdadm --detail --scan --verbose $ sudo mdadm --examine --scan --verbose ``` Avant le reboot j’avais pourtant : ``` $ sudo sh -c 'mdadm --examine --scan --verbose >> /etc/mdadm/mdadm.conf' $ more /etc/mdadm/mdadm.conf ARRAY /dev/md/0 level=raid1 metadata=1.2 num-devices=2 UUID=13e5d3ed:13339b2a:855e6390:4396e577 name=turrican:0 devices=/dev/sdb,/dev/sda ``` La syntaxte « ARRAY /dev/md/0 » m’a paru curieuse car dans man mdadm.conf les volumes sont définis par md0 et non pas md/0 : > EXAMPLE > # /dev/md0 is known by its UUID. > ARRAY /dev/md0 UUID=3aaa0122:29827cfa:5331ad66:ca767371 Sur la [page du wiki Ubuntu dédiée au RAID logiciel](https://doc.ubuntu-fr.org/raid_logiciel), ils suggèrent d’appliquer ces deux commandes : ``` $ sudo mdadm --daemonise /dev/md0 $ sudo mdadm --monitor --daemonise /dev/md0 ``` La première renvoie « mdadm: --daemonise does not set the mode, and so cannot be the first option. », la seconde fork et je ne sais pas bien ce qu’elle fabrique. Je ne sais pas trop où chercher les erreurs : ``` $ sudo dmesg | grep -i md0 $ sudo dmesg | grep -i raid [3.316016] raid6: sse2x1 gen() 8849 MB/s [3.384016] raid6: sse2x1 xor() 9141 MB/s [3.452358] raid6: sse2x2 gen() 17657 MB/s [3.520335] raid6: sse2x2 xor() 12459 MB/s [3.588336] raid6: sse2x4 gen() 19858 MB/s [3.656325] raid6: sse2x4 xor() 11404 MB/s [3.724330] raid6: avx2x1 gen() 21590 MB/s [3.792352] raid6: avx2x1 xor() 17754 MB/s [3.860437] raid6: avx2x2 gen() 38610 MB/s [3.928018] raid6: avx2x2 xor() 23511 MB/s [3.996018] raid6: avx2x4 gen() 40046 MB/s [4.064333] raid6: avx2x4 xor() 20359 MB/s [4.064333] raid6: using algorithm avx2x4 gen() 40046 MB/s [4.064333] raid6: .... xor() 20359 MB/s, rmw enabled [4.064334] raid6: using avx2x2 recovery algorithm ``` Qu’en pensez-vous ? Merci d’avance 🙂 Donut ---
**Author:** ![anon61356901](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/cab0a1/32.png) [@anon61356901](https://www.debian-fr.org/u/anon61356901)\ **Post date:** [Février 12, 2020, 7:36 UTC](https://www.debian-fr.org/t/vbolume-raid-non-persistant-au-reboot/81230/2 "2020-02-12T07:36:15Z")
> [@DonutMan](#): > > Hélas, au reboot mon volume md0 n’apparaît plus ! > > `ls: impossible d'accéder à '/dev/md*'` Bonjour, Faut voir si il est nécessaire de créer le périphérique `/dev/md0` avec `mknod` ; Mais c’est étonnant quand même 🤔 car c’est fait - ou à faire - avant normalement. Je crois que la commande serait : `# mknod /dev/md0 b 9 0` Puis redémarrer (pour éventuellement « récupérer » ton miroir) ```plaintext root@n40l:~# ls -l /dev/md0 brw-rw---- 1 root disk 9, 0 févr. 12 08:47 /dev/md0 root@n40l:~# ``` Il est possible que les modules nécessaires ne soient pas chargés. Regarde avec `lsmod | grep raid` ```plaintext root@n40l:~# lsmod | grep raid raid10 57344 0 raid1 45056 0 raid0 20480 0 raid456 172032 1 async_raid6_recov 20480 1 raid456 async_memcpy 16384 2 raid456,async_raid6_recov async_pq 16384 2 raid456,async_raid6_recov async_xor 16384 3 async_pq,raid456,async_raid6_recov async_tx 16384 5 async_pq,async_memcpy,async_xor,raid456,async_raid6_recov raid6_pq 122880 3 async_pq,raid456,async_raid6_recov libcrc32c 16384 1 raid456 md_mod 167936 7 raid1,raid10,raid0,linear,raid456,multipath root@n40l:~# ``` ps : j’espère que Pascal ne va pas trop m’allumer ! 😋 ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Février 12, 2020, 8:53 UTC](https://www.debian-fr.org/t/vbolume-raid-non-persistant-au-reboot/81230/3 "2020-02-12T08:53:14Z")
A mon avis tu as commis deux erreurs. 1. Fixer les noms de périphériques membres dans mdadm.conf. Les noms /dev/sd\* ne sont pas stables, si jamais ils ne correspondent pas l’ensemble RAID ne pourra pas être assemblé. On n’a pas besoin de les fixer pour identifier les membres, les UUID sont là pour ça. 2. Utiliser des disques entiers comme membres d’un ensemble RAID. C’est techniquement possible, mais ça a des inconvénients comme le fait de rendre plus difficile l’identification de leur contenu pour les humains et ce n’est pas compatible avec la présence d’une table de partition qu’il faut donc effacer. Lorsqu’on utilise des partitions, on peut les définir de type “RAID”, ce qui facilite leur identification comme membres de RAID. On peut voir la sortie des commandes suivantes ? ``` fdisk -l mdadm --examine /dev/sd* blkid /dev/sd* ``` ---
**Author:** ![DonutMan](https://www.debian-fr.org/user_avatar/www.debian-fr.org/donutman/32/7713_2.png) [@DonutMan](https://www.debian-fr.org/u/DonutMan)\ **Post date:** [Février 22, 2020, 4:30 UTC](https://www.debian-fr.org/t/vbolume-raid-non-persistant-au-reboot/81230/4 "2020-02-22T16:30:18Z")
Bonjour à tous, merci pour vos retours et désolé pour mon retard 🙂 Effectivement je suis d’accord avec vous, il faudrait que je passe par les UUID de façon générale. Pascal, je crois que tu as trouvé le problème avec ton deuxième point !! Voici le retour des commandes demandées. Pour info, ma configuration globale en terme de disques : - 1 disque NVMe sur lequel est installé Windows 10 (nvme0n1) - 1 disque NVMe sur lequel est installé Debian (nvme1n1) - 2 disques sda et sdb sur lesquels je souhaite installer un RAID logiciel J’ai repris l’ensemble de la procédure en utilisant des UUID à la place de sda/sdb et en essayant de créer une grappe en se basant sur les partitions (UUID de sda1 et sdb1) et non pas des disques. Voici ce que j’obtiens in fine : ``` sudo fdisk -l Disque /dev/nvme0n1 : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs Modèle de disque : Force MP600 Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 512 octets taille d'E/S (minimale / optimale) : 512 octets / 512 octets Type d'étiquette de disque : gpt Identifiant de disque : 764B6852-3A1F-4FB8-9E35-44494CC2FD7B Périphérique Début Fin Secteurs Taille Type /dev/nvme0n1p1 2048 1085439 1083392 529M Environnement de récupératio /dev/nvme0n1p2 1085440 1288191 202752 99M Système EFI /dev/nvme0n1p3 1288192 1320959 32768 16M Réservé Microsoft /dev/nvme0n1p4 1320960 1953523711 1952202752 930,9G Données de base Microsoft Disque /dev/nvme1n1 : 111,8 GiB, 120034123776 octets, 234441648 secteurs Modèle de disque : LDLC F8+M.2 120 Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 512 octets taille d'E/S (minimale / optimale) : 512 octets / 512 octets Type d'étiquette de disque : gpt Identifiant de disque : 7B029D44-A622-4D7C-BA22-2ED5662417E7 Périphérique Début Fin Secteurs Taille Type /dev/nvme1n1p1 2048 1050623 1048576 512M Système EFI /dev/nvme1n1p2 1050624 167438335 166387712 79,3G Système de fichiers Linux /dev/nvme1n1p3 167438336 234440703 67002368 32G Partition d'échange Linux Disque /dev/sdb : 2,7 TiB, 3000592982016 octets, 5860533168 secteurs Modèle de disque : TOSHIBA HDWD130 Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 4096 octets taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets Type d'étiquette de disque : gpt Identifiant de disque : 66629560-57B4-449E-A0D5-84951980917E Périphérique Début Fin Secteurs Taille Type /dev/sdb1 2048 5860533134 5860531087 2,7T RAID Linux Disque /dev/sda : 2,7 TiB, 3000592982016 octets, 5860533168 secteurs Modèle de disque : TOSHIBA HDWD130 Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 4096 octets taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets Type d'étiquette de disque : gpt Identifiant de disque : 58B59708-0C2E-4333-8653-92A1AEF10B40 Périphérique Début Fin Secteurs Taille Type /dev/sda1 2048 5860533134 5860531087 2,7T RAID Linux Disque /dev/md127 : 2,7 TiB, 3000456642560 octets, 5860266880 secteurs Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 4096 octets taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets ``` Au redémarrage le device raid est bien créé automatiquement mais curieusement en md127 ``` $ ll /dev/md* brw-rw---- 1 root disk 9, 127 févr. 22 16:18 /dev/md127 /dev/md: total 0 lrwxrwxrwx 1 root root 8 févr. 22 16:18 turrican:0 -> ../md127 ``` Mais en tout cas, ça semble fonctionner 🙂 Merci à vous tous !! Donut ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Février 22, 2020, 5:49 UTC](https://www.debian-fr.org/t/vbolume-raid-non-persistant-au-reboot/81230/5 "2020-02-22T17:49:56Z")
> [@DonutMan](#): > > Au redémarrage le device raid est bien créé automatiquement mais curieusement en md127 C’est un sujet qui a toujours été un peu obscur pour moi ; la numérotation lors de l’auto-assemblage partirait de 127 en descendant quand mdadm considère qu’un ensemble RAID n’appartient pas à ce système/hôte et pourrait entrer en conflit avec un autre ensemble RAID appartenant au système. /etc/mdadm/mdadm.conf a-t-il été mis à jour suite à la création du nouvel ensemble RAID ? De toute façon j’ai tendance à considérer que les noms de périphériques /dev/md\* des ensembles RAID, c’est comme les noms /dev/sd\* des disques SCSI/SATA/USB : ce n’est pas stable donc si possible il faut éviter de les utiliser dans les fichiers de configuration comme /etc/fstab et leur préférer des identifiants persistants comme les UUID ou LABELs. ---
**Author:** ![anon61356901](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/cab0a1/32.png) [@anon61356901](https://www.debian-fr.org/u/anon61356901)\ **Post date:** [Février 24, 2020, 11:41 UTC](https://www.debian-fr.org/t/vbolume-raid-non-persistant-au-reboot/81230/6 "2020-02-24T11:41:05Z")
> Avertissement: veuillez faire une sauvegarde avant de suivre tout conseil donné ici 🙂 C’était aussi plutôt obscur pour moi @PascalHambourg . J’ai utilisé les explications et une procédure décrite ici pour comprendre et changer le nom de trois grappes en RAID1 : [https://superuser.com/questions/346719/how-to-change-the-name-of-an-md-device-mdadm](https://superuser.com/questions/346719/how-to-change-the-name-of-an-md-device-mdadm) Ce lien est digne d’intérêt pour qui cherche à comprendre. J’ai sur un PC d’expérimentation une Gentoo avec trois grappes RAID1 actives qui étaient mal numérotées. (le rootfs /, le swap et un emplacement de données « DATA ») J’ai aussi sur ce PC une buster qui n’utilise pas ces grappes. Mes `/etc/fstab` n’utilisent que les UUID. J’ai utilisé buster pour appliquer la procédure « Option #2, With 1.x arrays » du lien ci-dessus. en utilisant le `hostname` de la Gentoo. Pour que la persistance des noms des grappes soit effective sous buster, j’ai eu à faire ensuite : ```plaintext # mdadm --detail --scan >> /etc/mdadm/mdadm.conf ``` Il faut vérifier le contenu de `/etc/mdadm/mdadm.conf` pour effacer les références aux grappes mal numérotées. Puis, une fois le `/etc/mdadm/mdadm.conf` vérifié et corrigé si besoin : ```plaintext # update-initramfs -v -u ``` J’ai réussi à bien numéroter les grappes comme je l’entendais ; rootfs en `md0`, swap en `md1` et « DATA » en `md2`. ---
**Author:** ![DonutMan](https://www.debian-fr.org/user_avatar/www.debian-fr.org/donutman/32/7713_2.png) [@DonutMan](https://www.debian-fr.org/u/DonutMan)\ **Post date:** [Février 25, 2020, 2:49 UTC](https://www.debian-fr.org/t/vbolume-raid-non-persistant-au-reboot/81230/7 "2020-02-25T14:49:12Z")
Bonjour à tous, merci pour ce lien je vais regarder ça en détail ! En tout cas, le RAID semble fonctionner correctement. Il me reste maintenant à bien comprendre le monitoring 🙂 Bonne journée à tous et merci pour vos conseils 🙂 Donut.