VBolume RAID non persistant au reboot

DonutMan · Février 12, 2020, 7:29am

Bonjour,
je dispose de deux disques HDD que je souhaite monter en RAID1 sous Debian 10.

J’ai suivi ce tuto 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, 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

anon61356901 · Février 12, 2020, 8:47am

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)

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

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 !

PascalHambourg · Février 12, 2020, 8:54am

A mon avis tu as commis deux erreurs.

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.
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*

DonutMan · Février 22, 2020, 4:30pm

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

$ lsmod | grep  raid
  raid10                 57344  0
  raid456               172032  0
  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
  raid1                  45056  0
  raid0                  20480  0
  md_mod                167936  6 raid1,raid10,raid0,linear,raid456,multipath

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

PascalHambourg · Février 22, 2020, 5:50pm

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.

anon61356901 · Février 24, 2020, 11:45am

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 :

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 :

# 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 :

# 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.

DonutMan · Février 25, 2020, 2:49pm

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.