logo Debian Debian Debian-France Debian-Facile Debian-fr.org Forum-Debian.fr Debian ? Communautés logo inclusivité

Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 16-09-2019 21:51:08

jibe
Membre
Distrib. : DF-Linux 10
Noyau : Linux 4.19.0-10-amd64
(G)UI : mate
Inscription : 19-06-2018

Problème RAID : /dev/md127 au lieu de /dev/md1 introduit par Debian 10

Salut,

Je tente de récupérer les données d'un ancien serveur sous SME8 (basé sur CentOS 5.9). Pour un transfert plus rapide et sans passer par le réseau, j'ai monté le disque (RAID 1 en mode dégradé, l'autre disque n'existe plus) sur Debian10. Ensuite, j'ai voulu redémarrer le vieux serveur, mais il plante sur kernel panic.

Je n'ai rien écrit (du moins, rien de manière volontaire et consciente) sur le disque depuis la Debian, et l'ancien serveur fonctionnait très bien avant. Comme message, j'en repère un qui parle de problème dans un superbloc, empêchant la mise en route des ARRAY du raid.

Je remets le disque sur Debian et, en regardant de plus près, je m'aperçois que mes arrays raid ont été modifiées :

# mdadm --examine --scan
ARRAY /dev/md127 UUID=88201c7a:6c061aa0:adfa4438:40a858d5
ARRAY /dev/md125 UUID=1f6edc43:1dcee78c:e34f50cd:f0e9ba98
ARRAY /dev/md126 UUID=c69fe4f5:1376ebfe:cc124579:f2e0a00e



Or, sur l'ancien serveur, j'avais /dev/md1, /dev/md2 et /dev/md3 (dans l'ordre) au lieu des (respectivement) /dev/md127, /dev/md125 et /dev/md126.

Je stoppe les arrays, je réassemble avec les bons numéros, tout fonctionne bien. Je repasse mon disque sur l'ancien serveur, et à nouveau : kernel panic.

Retour sur Debian, mon disque se retrouve en md127/125/126. /etc/mdadm/mdadm.conf ne contient aucune ligne sur les arrays. Je re-stoppe les arrays, les réassemble en md1/md2/md3, je remplis mdadm.conf, je m'assure de ne pas avoir de /var/lib/mdadm/conf-unchecked, je fais un

# update-initramfs -u


je reboote, et à nouveau j'ai les arrays md127/125/126 crash.gif

Je re-stoppe et re-assemble (mdadm.conf est resté correct avec les md1/md2/md3 !) et j'ai maintenant cela :

# fdisk -l
Disk /dev/sda: 931.5 GiB, 1000203804160 bytes, 1953523055 sectors
Disk model: TOSHIBA HDWD110
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xf9ffb6a3

Device     Boot      Start        End    Sectors   Size Id Type
/dev/sda1  *          2048 1945155583 1945153536 927.5G 83 Linux
/dev/sda2       1945157630 1953521663    8364034     4G  5 Extended
/dev/sda5       1945157632 1953521663    8364032     4G 82 Linux swap / Solaris

Partition 2 does not start on physical sector boundary.


Disk /dev/sdb: 465.8 GiB, 500106780160 bytes, 976771055 sectors
Disk model: Hitachi HDS72105
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot   Start       End   Sectors   Size Id Type
/dev/sdb1  *          1    208769    208769   102M fd Linux raid autodetect
/dev/sdb2        208770   4289155   4080386     2G fd Linux raid autodetect
/dev/sdb3       4289156 976768063 972478908 463.7G fd Linux raid autodetect




Disk /dev/md2: 2 GiB, 2089091072 bytes, 4080256 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/md3: 463.7 GiB, 497908973568 bytes, 972478464 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/md1: 101.9 MiB, 106823680 bytes, 208640 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
 



# cat /etc/mdadm/mdadm.conf
# mdadm.conf
#
# !NB! Run update-initramfs -u after updating this file.
# !NB! This will ensure that initramfs has an uptodate copy.
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
#DEVICE partitions containers

# 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

# This configuration was done on Mon, 16 Sep 2019 by joseph
ARRAY /dev/md1 UUID=88201c7a:6c061aa0:adfa4438:40a858d5
ARRAY /dev/md2 UUID=1f6edc43:1dcee78c:e34f50cd:f0e9ba98
ARRAY /dev/md3 UUID=c69fe4f5:1376ebfe:cc124579:f2e0a00e
 



# mdadm --detail --scan
ARRAY /dev/md2 metadata=0.90 UUID=1f6edc43:1dcee78c:e34f50cd:f0e9ba98
ARRAY /dev/md3 metadata=0.90 UUID=c69fe4f5:1376ebfe:cc124579:f2e0a00e
ARRAY /dev/md1 metadata=0.90 UUID=88201c7a:6c061aa0:adfa4438:40a858d5



Tout semble bon, sauf que j'ai toujours :

# mdadm --examine --scan
ARRAY /dev/md127 UUID=88201c7a:6c061aa0:adfa4438:40a858d5
ARRAY /dev/md125 UUID=1f6edc43:1dcee78c:e34f50cd:f0e9ba98
ARRAY /dev/md126 UUID=c69fe4f5:1376ebfe:cc124579:f2e0a00e



Je pense que c'est ça qui coince au démarrage de l'ancien serveur : il construit maintenant ses arrays en /dev/md127, /dev/md125, /dev/md126 alors que tout est configuré pour /dev/md1, /dev/md2 et /dev/md3... Le fstab de ce serveur fait effectivement monter / sur /dev/md3. Pour info, voici le mdadm.conf de l'ancien serveur :

cat /mnt/sme/etc/mdadm.conf

# mdadm.conf written out by anaconda
DEVICE partitions
ARRAY /dev/md3 level=raid1 num-devices=1 uuid=c69fe4f5:1376ebfe:cc124579:f2e0a00e
ARRAY /dev/md1 level=raid1 num-devices=1 uuid=88201c7a:6c061aa0:adfa4438:40a858d5
ARRAY /dev/md2 level=raid1 num-devices=2 uuid=1f6edc43:1dcee78c:e34f50cd:f0e9ba98



Question : comment faire pour pouvoir à nouveau démarrer l'ancien serveur ? Je pense qu'il faudrait déjà que mdadm --examine --scan me donne les bonnes valeurs pour les /dev/mdx ?

Questions subsidiaires : c'est quoi ce b**del que m'a foutu Debian 10 ? Comment a-t-il pu me casser un disque que j'ai déjà monté sur d'autres systèmes sans que ça me change les numéros de device RAID ?

Hors ligne

#2 18-09-2019 15:37:00

jibe
Membre
Distrib. : DF-Linux 10
Noyau : Linux 4.19.0-10-amd64
(G)UI : mate
Inscription : 19-06-2018

Re : Problème RAID : /dev/md127 au lieu de /dev/md1 introduit par Debian 10

Salut,

Le mystère s'épaissit... Suite aux manips ci-dessus, au redémarrage j'avais :

# mdadm --examine --scan          
ARRAY /dev/md127 UUID=88201c7a:6c061aa0:adfa4438:40a858d5
ARRAY /dev/md2 UUID=1f6edc43:1dcee78c:e34f50cd:f0e9ba98
ARRAY /dev/md3 UUID=c69fe4f5:1376ebfe:cc124579:f2e0a00e



Bon, je ne comprends pas pourquoi j'ai /dev/md2 et /dev/md3 qui ont repris leurs bons numéros et pas /dev/md127, mais j'ai un petit espoir qu'en re-stoppant puis ré-assemblant sous le bon numéro, ça devrait rentrer dans l'ordre. Mais rien à faire, même en rebootant.

Finalement, je me dis que puisque l'ancien serveur mentionne un problème de superbloc, il suffit probablement de le remplacer par une copie. Mais avant de faire des bêtises, il me faut cloner le disque. J'installe donc un disque supplémentaire de même capacité dans mon nouveau serveur, le redémarre... et en m'assurant par fdisk -l de quel disque je dois copier sur qui, quelle n'est pas ma surprise de constater que le raid est maintenant avec tous les bons numéros ! Est-ce le simple fait d'avoir redémarré une fois de plus, d'avoir ajouté un disque, ou sont-ce les dernières commandes que j'ai lancées avant d'arrêter pour installer le nouveau disque ? Mystère !

Bon, tant que j'y suis, je clone, puis je récupère le disque d'origine pour le remettre dans l'ancien serveur. Comme l'array md3 contient le système et qu'elle semble maintenant bonne, il démarre un peu mieux mais se plante en essayant de monter la partition /boot, qui est sur l'array md1. fdisk -l m'indique qu'en fait, l'array md1 est assemblée en /dev/md127 crash.gif. Je remarque aussi qu'il me signale que les partitions ne correspondent pas aux cylindres. Comme le système me propose un shell en me proposant de faire un e2fsck -b pour récupérer une copie de superbloc, c'est ce que je fais. S'ensuit une vérification qui trouve un tas de problèmes avec les espaces libres, mais tout semble finalement se corriger. Redémarrage... et re-plantage : on est toujours en md127 !

Remontage du disque sur mon nouveau serveur : le RAID a bien les arrays en md1,md2,md3 ! Je peux sans problème mounter md1 et md3 (md2 est la swap), et le contenu des partitions est bien visible et correct. Et fdisk -l ne me signale aucun problème sur les partitions. crash.gif

Mais que se passe-t-il donc et comment sortir de ce casse-tête ?

Hors ligne

#3 18-09-2019 16:00:02

raleur
Membre
Inscription : 03-10-2014

Re : Problème RAID : /dev/md127 au lieu de /dev/md1 introduit par Debian 10

Il suffit de faire comme d'habitude quand les noms de périphériques ne sont pas stables : utiliser des identifiants persistants comme l'UUID ou le LABEL à la place.

Il me semble que la numérotation d'un ensemble RAID à partir de 127 peut se produire lorsque le nom d'hôte enregistré dans le superbloc ne correspond pas avec le nom d'hôte du système, pour éviter la collision avec un ensemble RAID de même numéro créé par le système.

Accessoirement, tes superblocs sont au format 0.90 qui est obsolète.

Concernant l'erreur de superbloc, si tu ne la mentionnes pas avec exactitude on ne pourra pas t'aider.

Il vaut mieux montrer que raconter.

Hors ligne

#4 18-09-2019 21:58:33

jibe
Membre
Distrib. : DF-Linux 10
Noyau : Linux 4.19.0-10-amd64
(G)UI : mate
Inscription : 19-06-2018

Re : Problème RAID : /dev/md127 au lieu de /dev/md1 introduit par Debian 10

Salut,

Merci de ta réponse.

En fait, ce qui me surprend surtout, c'est que j'ai souvent manipulé des disques de ce type de serveur (SME) sur d'autres distribs, et que je n'ai jamais eu ni de numérotation différente, ni de problème en les remettant sur le serveur d'origine... Je n'en mettrais pas ma main au feu, mais je crois bien l'avoir fait sous Stretch, sans problème. J'ai du mal à comprendre pourquoi Buster m'a bricolé le superbloc...

raleur a écrit :

Il suffit de faire comme d'habitude quand les noms de périphériques ne sont pas stables : utiliser des identifiants persistants comme l'UUID ou le LABEL à la place.


Oui... Ça ne m'est pas venu à l'esprit, parce que j'ai peur que ce ne soit pas simple : l'ancien serveur ne démarre plus, et je ne suis pas sûr que les UUID des raid soient les mêmes sur Buster que sur l'ancien serveur, surtout vu la pagaille que j'ai constatée !

raleur a écrit :

Il me semble que la numérotation d'un ensemble RAID à partir de 127 peut se produire lorsque le nom d'hôte enregistré dans le superbloc ne correspond pas avec le nom d'hôte du système, pour éviter la collision avec un ensemble RAID de même numéro créé par le système.


C'est une explication qui me semble assez logique, mais j'ai trouvé quelques trucs sur cette numérotation à partir de 127 (mais en fait, à partir de 125 en ce qui me concerne !), mais aucun ne donne cette explication et presque tous disent que c'est assez bizarre...

raleur a écrit :

Accessoirement, tes superblocs sont au format 0.90 qui est obsolète.


Oui : comme je l'ai dit, ce vieux serveur était sous CentOS 5 (SME 8 plus exactement), qui est plus qu'obsolète : plus maintenu depuis Mars 2017 ! Mais est-ce une raison pour que Buster me les bricole ? J'ai juste mis le disque pour le lire !

raleur a écrit :

Concernant l'erreur de superbloc, si tu ne la mentionnes pas avec exactitude on ne pourra pas t'aider.


Apparemment, je n'ai plus d'erreur sur /dev/md2 (swap) ni /dev/md3 (/). C'est quand au cours du boot qu'il veut mounter /dev/md127 (/boot, qui devrait être /dev/md1... et qui a fini par le redevenir sur Buster !) qu'il met un message du genre "you should try ex2fs -b <No de la première copie de superbloc> <device>" puis : "you are connected to a shell, type Ctrl D to exit". Je n'ai plus accès au serveur à cette heure ci, mais si besoin je pourrai relever le message exact.

Hors ligne

#5 19-09-2019 15:03:34

raleur
Membre
Inscription : 03-10-2014

Re : Problème RAID : /dev/md127 au lieu de /dev/md1 introduit par Debian 10

jibe a écrit :

je ne suis pas sûr que les UUID des raid soient les mêmes sur Buster que sur l'ancien serveur


Un UUID est conçu pour être un identifiant unique et persistant, il n'y a aucune raison qu'il ne soit pas le même en passant d'un système à l'autre. D'autre part je ne parle pas des UUID internes des ensembles RAID mais des UUID de leur contenu (système de fichiers, swap...).

jibe a écrit :

j'ai trouvé quelques trucs sur cette numérotation à partir de 127 (mais en fait, à partir de 125 en ce qui me concerne !)


Non, à partir de 127 en descendant.

jibe a écrit :

il met un message du genre "you should try ex2fs -b <No de la première copie de superbloc> <device>"


"du genre", ce n'est pas assez précis. Il faut le message exact et complet (y compris ce qui précède).
En tout cas ce message concerne un superbloc de système de fichiers ext2/3/4, pas un superbloc RAID.

Dernière modification par raleur (19-09-2019 15:05:44)


Il vaut mieux montrer que raconter.

Hors ligne

#6 19-09-2019 21:48:38

jibe
Membre
Distrib. : DF-Linux 10
Noyau : Linux 4.19.0-10-amd64
(G)UI : mate
Inscription : 19-06-2018

Re : Problème RAID : /dev/md127 au lieu de /dev/md1 introduit par Debian 10

Salut,

raleur a écrit :

Un UUID est conçu pour être un identifiant unique et persistant, il n'y a aucune raison qu'il ne soit pas le même en passant d'un système à l'autre. D'autre part je ne parle pas des UUID internes des ensembles RAID mais des UUID de leur contenu (système de fichiers, swap...).


Bon, soit on ne parle pas de la même chose, soit quelque chose m'échappe... Je ne suis pas sûr de bien comprendre ce qui correspond exactement à ce que tu appelles "les UUID internes des ensembles RAID" et "les UUID de leur contenu" ?
Tu parles bien de remplacer, dans /etc/fstab, les /dev/mdx qui s'y trouvent actuellement par les UUID correspondants ? Donc ceux indiqués dans le superbloc RAID ?

raleur a écrit :

Non, à partir de 127 en descendant.


Ah, ok ! Je n'avais pas pensé qu'il pouvait numéroter en sens inverse !

raleur a écrit :

"du genre", ce n'est pas assez précis. Il faut le message exact et complet (y compris ce qui précède).
En tout cas ce message concerne un superbloc de système de fichiers ext2/3/4, pas un superbloc RAID.


Je suis pris demain toute la journée, je relèverai le message exact ce week-end.

Mais justement : le message ne concerne pas le raid, et AMHA n'est que le résultat du fait que le système ne comprend plus ce qui se passe avec ce /dev/md127 persistant. En effet, AMHA le système de fichiers et ses superblocs n'ont rien, puisque tout va bien sur Debian et qu'en plus, rien ne change quand on remplace le superbloc soi-disant défectueux par une de ses copies.

Bon, j'ai peut-être loupé quelque chose avant le message, mais ça m'étonnerait : ce message m'ayant paru curieux dès que je l'ai vu, j'ai cherché s'il n'y avait pas autre chose de plus plausible. En tous cas, je re-vérifierai une fois de plus.

Hors ligne

#7 20-09-2019 11:00:19

raleur
Membre
Inscription : 03-10-2014

Re : Problème RAID : /dev/md127 au lieu de /dev/md1 introduit par Debian 10

jibe a écrit :

Tu parles bien de remplacer, dans /etc/fstab, les /dev/mdx qui s'y trouvent actuellement par les UUID correspondants ?


Oui.

jibe a écrit :

Donc ceux indiqués dans le superbloc RAID ?


Non. L'UUID du superbloc RAID est utilisé dans mdadm.conf, pas dans fstab. Dans fstab il faut utiliser l'UUID du système de fichiers ou du swap contenu dans l'ensemble RAID, tel qu'affiché par blkid.
/dev/md* (ensemble RAID) -> UUID du système de fichiers à utiliser dans fstab.
/dev/sd* (si membre d'un ensemble RAID) ->UUID du superbloc RAID à utiliser dans mdadm.conf.

Dernière modification par raleur (20-09-2019 11:01:07)


Il vaut mieux montrer que raconter.

Hors ligne

#8 21-09-2019 14:04:56

jibe
Membre
Distrib. : DF-Linux 10
Noyau : Linux 4.19.0-10-amd64
(G)UI : mate
Inscription : 19-06-2018

Re : Problème RAID : /dev/md127 au lieu de /dev/md1 introduit par Debian 10

Salut,

Merci pour tes explications ! Encore un truc que j'ignorais, ces doubles UUID pour un ensemble RAID. Pour ceux qui suivent le sujet, il y a quelques précisions ici. Si quelqu'un a de meilleurs liens, ils seront toujours les bienvenus !

Donc, grâce à toi, mes connaissances du fonctionnement du RAID progressent big_smile

Le mystère concernant le problème reste : J'avais remis le disque fautif sur Buster pour voir concrètement ces histoires d'UUID, et quand je l'ai remis sur l'ancien serveur, celui-ci a redémarré normalement ! Impossible donc de retrouver le message d'erreur...

Je pense qu'on peut raisonnablement en conclure que Buster bricole quelque chose sur le disque, même quand on ne fait que des lectures, et que ce qu'il fait perturbe le fonctionnement du RAID. Si on arrive à obtenir qu'il n'attribue plus par défaut des numéros d'ensembles RAID décroissants à partir de 127 et à ce qu'il prenne ceux d'origine, il finit (apparemment après plusieurs redémarrages) par remettre les choses d'aplomb...

Bon, mon problème est donc résolu, puisque j'ai réussi à faire redémarrer cet ancien serveur. Je vais donc pouvoir dumper les quelques BDD que j'avais à y récupérer. Par contre, par curiosité, j'aimerais bien comprendre ce qui s'est passé. Si quelqu'un a une explication ou quelques tests à effectuer pour tenter de comprendre, je suis preneur.

(edit: correction d'une énorme faute ops.gif. J'espère que d'autres ne m'ont pas échappé !)

Dernière modification par jibe (21-09-2019 14:08:21)

Hors ligne

#9 21-09-2019 17:28:26

raleur
Membre
Inscription : 03-10-2014

Re : Problème RAID : /dev/md127 au lieu de /dev/md1 introduit par Debian 10

jibe a écrit :

ces doubles UUID pour un ensemble RAID


Ce n'est pas spécifique au RAID. La structure des données sur un disque est un empilement de couches, et chaque couche a son ou ses UUID.
- Une partition a son UUID propre indépendamment de son contenu (PARTUUID)
- Un ensemble RAID a un UUID commun à tous ses membres (UUID) et des UUID propres à chaque membre (UUID_SUB)
- Idem pour un système de fichiers Btrfs
- LVM utilise des UUID pour ses volumes physiques, logiques et groupes de volumes
- Un système de fichiers ou un swap a un UUID


Il vaut mieux montrer que raconter.

Hors ligne

Pied de page des forums