Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
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
je reboote, et à nouveau j'ai les arrays md127/125/126 
Je re-stoppe et re-assemble (mdadm.conf est resté correct avec les md1/md2/md3 !) et j'ai maintenant cela :
Tout semble bon, sauf que j'ai toujours :
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 :
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
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 . 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.
Mais que se passe-t-il donc et comment sortir de ce casse-tête ?
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
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 !
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...
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 !
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
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...).
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.
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
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 ?
Non, à partir de 127 en descendant.
Ah, ok ! Je n'avais pas pensé qu'il pouvait numéroter en sens inverse !
"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
Tu parles bien de remplacer, dans /etc/fstab, les /dev/mdx qui s'y trouvent actuellement par les UUID correspondants ?
Oui.
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
. J'espère que d'autres ne m'ont pas échappé !)
Dernière modification par jibe (21-09-2019 14:08:21)
Hors ligne
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