Pb de RAID au re démarrage d'un serveur XEN : le RAID5 ne voit plus qu'un disque sur 4.
15 réponses
yann
Bonjour,
Je viens de constater que mon serveur domestique ne démarre plus (XEN4.0
+ lenny LTS).
Le symptôme initial est qu'il ne trouve pas /var et /home qui sont des
volumes logique sur un volume en RAID5.
Le volume en raid5 ne comporte qu'un disque sur quatre et n'est donc pas
démarré (sd[bcde]).
Ce volume a été crée en 2010, il a fonctionner sans trop de problème
jusque là.
Ce serveur dispose de deux devices en raid1 pour /boot (md0) et / (md1),
le troisième (md2) est un RAID5 qui contient un volume groupe pour
toutes les partitions des 5 hôtes hébergés en plus de /var et /home du
dom0.
Premiers essais
- j'ai démarré le serveur sous sysrescue => le raid 5 est bien vu et
démarré, les lv sont tous là...
- en mode maintenance sur le serveur :
* les disques sd[bcde] ont bien une partition raid linux
* après un arrêt de md2 (mdadm --stop /dev/md2), le redémarrage indique
des problèmes d'UUID sur les disques (mdadm --assemble /dev/md2)
- le mdadm --detail --scan donne le même fichier de configuration depuis
sysrescuecd ou bien le système...
Pour aller plus loin, j'ai regardé dmesg : j'ai trouvé ce que je pense
être une annomalie :
+ le disque sdb est détecté,
+ le raid md2 démarrage mais plante parce que pas assez de disque
plus loin les autres disques sont détectés
Je ne comprend pas d'ou peu venir se problème ni comment le contrer...
Je pense mettre une attente à la volée dans grub (comme pour les disques
USB), mais je ne sais plus/pas comment faire...
Je viens de constater que mon serveur domestique ne démarre plus (XEN4.0 + lenny LTS).
Je pensais que LTS avait commencé avec Squeeze. Lenny, c'est un peu vieux pour un système en production.
Le symptôme initial est qu'il ne trouve pas /var et /home qui sont des volumes logique sur un volume en RAID5.
Le volume en raid5 ne comporte qu'un disque sur quatre et n'est donc pas démarré (sd[bcde]).
Ce volume a été crée en 2010, il a fonctionner sans trop de problème jusque là.
Ce serveur dispose de deux devices en raid1 pour /boot (md0) et / (md1), le troisième (md2) est un RAID5 qui contient un volume groupe pour toutes les partitions des 5 hôtes hébergés en plus de /var et /home du dom0.
Premiers essais - j'ai démarré le serveur sous sysrescue => le raid 5 est bien vu et démarré, les lv sont tous là...
- en mode maintenance sur le serveur : * les disques sd[bcde] ont bien une partition raid linux * après un arrêt de md2 (mdadm --stop /dev/md2), le redémarrage indique des problèmes d'UUID sur les disques (mdadm --assemble /dev/md2)
Mais encore ?
- le mdadm --detail --scan donne le même fichier de configuration depuis sysrescuecd ou bien le système...
AMA c'est plutôt --examine -v qu'il faudrait utiliser.
Pour aller plus loin, j'ai regardé dmesg : j'ai trouvé ce que je pense être une annomalie : + le disque sdb est détecté, + le raid md2 démarrage mais plante parce que pas assez de disque plus loin les autres disques sont détectés
As-tu configuré le paquet mdadm pour assembler tous les ensembles RAID dans l'initramfs ou seulement celui de la racine ?
Je pense mettre une attente à la volée dans grub (comme pour les disques USB), mais je ne sais plus/pas comment faire...
Il y a l'option "rootdelay=N", mais c'est plutôt pour attendre que le périphérique contenant la racine soit disponible.
Si tu veux vérifier un problème de timing, tu peux utiliser l'option "break" pour interrompre le démarrage et lancer le shell de secours de l'initramfs, attendre que les disques soient bien détectés et fermer le shell pour poursuivre le démarrage.
yann@ianco.org a écrit :
Je viens de constater que mon serveur domestique ne démarre plus (XEN4.0
+ lenny LTS).
Je pensais que LTS avait commencé avec Squeeze. Lenny, c'est un peu
vieux pour un système en production.
Le symptôme initial est qu'il ne trouve pas /var et /home qui sont des
volumes logique sur un volume en RAID5.
Le volume en raid5 ne comporte qu'un disque sur quatre et n'est donc pas
démarré (sd[bcde]).
Ce volume a été crée en 2010, il a fonctionner sans trop de problème
jusque là.
Ce serveur dispose de deux devices en raid1 pour /boot (md0) et / (md1),
le troisième (md2) est un RAID5 qui contient un volume groupe pour
toutes les partitions des 5 hôtes hébergés en plus de /var et /home du
dom0.
Premiers essais
- j'ai démarré le serveur sous sysrescue => le raid 5 est bien vu et
démarré, les lv sont tous là...
- en mode maintenance sur le serveur :
* les disques sd[bcde] ont bien une partition raid linux
* après un arrêt de md2 (mdadm --stop /dev/md2), le redémarrage indique
des problèmes d'UUID sur les disques (mdadm --assemble /dev/md2)
Mais encore ?
- le mdadm --detail --scan donne le même fichier de configuration depuis
sysrescuecd ou bien le système...
AMA c'est plutôt --examine -v qu'il faudrait utiliser.
Pour aller plus loin, j'ai regardé dmesg : j'ai trouvé ce que je pense
être une annomalie :
+ le disque sdb est détecté,
+ le raid md2 démarrage mais plante parce que pas assez de disque
plus loin les autres disques sont détectés
As-tu configuré le paquet mdadm pour assembler tous les ensembles RAID
dans l'initramfs ou seulement celui de la racine ?
Je pense mettre une attente à la volée dans grub (comme pour les disques
USB), mais je ne sais plus/pas comment faire...
Il y a l'option "rootdelay=N", mais c'est plutôt pour attendre que le
périphérique contenant la racine soit disponible.
Si tu veux vérifier un problème de timing, tu peux utiliser l'option
"break" pour interrompre le démarrage et lancer le shell de secours de
l'initramfs, attendre que les disques soient bien détectés et fermer le
shell pour poursuivre le démarrage.
Je viens de constater que mon serveur domestique ne démarre plus (XEN4.0 + lenny LTS).
Je pensais que LTS avait commencé avec Squeeze. Lenny, c'est un peu vieux pour un système en production.
Le symptôme initial est qu'il ne trouve pas /var et /home qui sont des volumes logique sur un volume en RAID5.
Le volume en raid5 ne comporte qu'un disque sur quatre et n'est donc pas démarré (sd[bcde]).
Ce volume a été crée en 2010, il a fonctionner sans trop de problème jusque là.
Ce serveur dispose de deux devices en raid1 pour /boot (md0) et / (md1), le troisième (md2) est un RAID5 qui contient un volume groupe pour toutes les partitions des 5 hôtes hébergés en plus de /var et /home du dom0.
Premiers essais - j'ai démarré le serveur sous sysrescue => le raid 5 est bien vu et démarré, les lv sont tous là...
- en mode maintenance sur le serveur : * les disques sd[bcde] ont bien une partition raid linux * après un arrêt de md2 (mdadm --stop /dev/md2), le redémarrage indique des problèmes d'UUID sur les disques (mdadm --assemble /dev/md2)
Mais encore ?
- le mdadm --detail --scan donne le même fichier de configuration depuis sysrescuecd ou bien le système...
AMA c'est plutôt --examine -v qu'il faudrait utiliser.
Pour aller plus loin, j'ai regardé dmesg : j'ai trouvé ce que je pense être une annomalie : + le disque sdb est détecté, + le raid md2 démarrage mais plante parce que pas assez de disque plus loin les autres disques sont détectés
As-tu configuré le paquet mdadm pour assembler tous les ensembles RAID dans l'initramfs ou seulement celui de la racine ?
Je pense mettre une attente à la volée dans grub (comme pour les disques USB), mais je ne sais plus/pas comment faire...
Il y a l'option "rootdelay=N", mais c'est plutôt pour attendre que le périphérique contenant la racine soit disponible.
Si tu veux vérifier un problème de timing, tu peux utiliser l'option "break" pour interrompre le démarrage et lancer le shell de secours de l'initramfs, attendre que les disques soient bien détectés et fermer le shell pour poursuivre le démarrage.
Yann Cohen
Le lundi 28 décembre 2015 à 13:19 +0100, Pascal Hambourg a écrit :
Note : Tu as répondu en privé. Je fais de même au cas où ce serait volontaire.
Perturbé par le lecteur de mail de "secours", alors que le serveur ne démarrait pas...
Donc tout est public...
a écrit : > Le 2015-12-28 11:57, Pascal Hambourg a écrit : >> a écrit : >>> >>> - en mode maintenance sur le serveur : >>> * les disques sd[bcde] ont bien une partition raid linux >>> * après un arrêt de md2 (mdadm --stop /dev/md2), le redémarrage >>> indique >>> des problèmes d'UUID sur les disques (mdadm --assemble /dev/md2) >> Mais encore ? > > mdadm --stop /dev/md2 > mdadm --assemble -v /dev/md2 > pvscan > vgscan > vgchange -a y > mount -a > exit > > et le serveur démarre... En fait j'aurais voulu des précisions sur la teneur du message qui "indique des problèmes d'UUID".
De mémoire, la teneur est : pas le bon "uuid"...
> Donc il me faut comprendre pourquoi pas au boot initial
Pour le moment, l'hypothèse serait que les disques sont détectés trop tard.
>> As-tu configuré le paquet mdadm pour assembler tous les ensembles RAID >> dans l'initramfs ou seulement celui de la racine ? > > Ah vrai dire, je n'ai aucun souvenir d'avoir effectuer ce choix... > dpkg-reconfigure j'imagine ?
Oui. Cela peut être intéressant de ne pas assembler cet ensemble RAID dans l'initramfs en même temps que celui de la racine car cela laisse un peu plus de temps pour la découverte des disques.
Les partitions membres de l'ensemble RAID 1 de la racine sont-elles sur les mêmes disques que le RAID 5 ?
Le RAID 1 est sur deux disques (cartes Flash 4Go, dont une jamais mise en service...)
Le RAID 5 est sur 4DD 1To.
Yann.
Le lundi 28 décembre 2015 à 13:19 +0100, Pascal Hambourg a écrit :
Note : Tu as répondu en privé. Je fais de même au cas où ce serait
volontaire.
Perturbé par le lecteur de mail de "secours", alors que le serveur ne
démarrait pas...
Donc tout est public...
yann@ianco.org a écrit :
> Le 2015-12-28 11:57, Pascal Hambourg a écrit :
>> yann@ianco.org a écrit :
>>>
>>> - en mode maintenance sur le serveur :
>>> * les disques sd[bcde] ont bien une partition raid linux
>>> * après un arrêt de md2 (mdadm --stop /dev/md2), le redémarrage
>>> indique
>>> des problèmes d'UUID sur les disques (mdadm --assemble /dev/md2)
>> Mais encore ?
>
> mdadm --stop /dev/md2
> mdadm --assemble -v /dev/md2
> pvscan
> vgscan
> vgchange -a y
> mount -a
> exit
>
> et le serveur démarre...
En fait j'aurais voulu des précisions sur la teneur du message qui
"indique des problèmes d'UUID".
De mémoire, la teneur est : pas le bon "uuid"...
> Donc il me faut comprendre pourquoi pas au boot initial
Pour le moment, l'hypothèse serait que les disques sont détectés trop tard.
>> As-tu configuré le paquet mdadm pour assembler tous les ensembles RAID
>> dans l'initramfs ou seulement celui de la racine ?
>
> Ah vrai dire, je n'ai aucun souvenir d'avoir effectuer ce choix...
> dpkg-reconfigure j'imagine ?
Oui. Cela peut être intéressant de ne pas assembler cet ensemble RAID
dans l'initramfs en même temps que celui de la racine car cela laisse un
peu plus de temps pour la découverte des disques.
Les partitions membres de l'ensemble RAID 1 de la racine sont-elles sur
les mêmes disques que le RAID 5 ?
Le RAID 1 est sur deux disques (cartes Flash 4Go, dont une jamais mise
en service...)
Le lundi 28 décembre 2015 à 13:19 +0100, Pascal Hambourg a écrit :
Note : Tu as répondu en privé. Je fais de même au cas où ce serait volontaire.
Perturbé par le lecteur de mail de "secours", alors que le serveur ne démarrait pas...
Donc tout est public...
a écrit : > Le 2015-12-28 11:57, Pascal Hambourg a écrit : >> a écrit : >>> >>> - en mode maintenance sur le serveur : >>> * les disques sd[bcde] ont bien une partition raid linux >>> * après un arrêt de md2 (mdadm --stop /dev/md2), le redémarrage >>> indique >>> des problèmes d'UUID sur les disques (mdadm --assemble /dev/md2) >> Mais encore ? > > mdadm --stop /dev/md2 > mdadm --assemble -v /dev/md2 > pvscan > vgscan > vgchange -a y > mount -a > exit > > et le serveur démarre... En fait j'aurais voulu des précisions sur la teneur du message qui "indique des problèmes d'UUID".
De mémoire, la teneur est : pas le bon "uuid"...
> Donc il me faut comprendre pourquoi pas au boot initial
Pour le moment, l'hypothèse serait que les disques sont détectés trop tard.
>> As-tu configuré le paquet mdadm pour assembler tous les ensembles RAID >> dans l'initramfs ou seulement celui de la racine ? > > Ah vrai dire, je n'ai aucun souvenir d'avoir effectuer ce choix... > dpkg-reconfigure j'imagine ?
Oui. Cela peut être intéressant de ne pas assembler cet ensemble RAID dans l'initramfs en même temps que celui de la racine car cela laisse un peu plus de temps pour la découverte des disques.
Les partitions membres de l'ensemble RAID 1 de la racine sont-elles sur les mêmes disques que le RAID 5 ?
Le RAID 1 est sur deux disques (cartes Flash 4Go, dont une jamais mise en service...)
Le RAID 5 est sur 4DD 1To.
Yann.
Pascal Hambourg
Yann Cohen a écrit :
- en mode maintenance sur le serveur : * les disques sd[bcde] ont bien une partition raid linux * après un arrêt de md2 (mdadm --stop /dev/md2), le redémarrage indique des problèmes d'UUID sur les disques (mdadm --assemble /dev/md2)
Mais encore ?
mdadm --stop /dev/md2 mdadm --assemble -v /dev/md2 pvscan vgscan vgchange -a y mount -a exit
et le serveur démarre...
En fait j'aurais voulu des précisions sur la teneur du message qui "indique des problèmes d'UUID".
De mémoire, la teneur est : pas le bon "uuid"...
Lors de l'assemblage de /dev/md2, je présume ? Sans le message exact et complet, ça ne me dit rien.
Yann Cohen a écrit :
- en mode maintenance sur le serveur :
* les disques sd[bcde] ont bien une partition raid linux
* après un arrêt de md2 (mdadm --stop /dev/md2), le redémarrage
indique
des problèmes d'UUID sur les disques (mdadm --assemble /dev/md2)
Mais encore ?
mdadm --stop /dev/md2
mdadm --assemble -v /dev/md2
pvscan
vgscan
vgchange -a y
mount -a
exit
et le serveur démarre...
En fait j'aurais voulu des précisions sur la teneur du message qui
"indique des problèmes d'UUID".
De mémoire, la teneur est : pas le bon "uuid"...
Lors de l'assemblage de /dev/md2, je présume ?
Sans le message exact et complet, ça ne me dit rien.
- en mode maintenance sur le serveur : * les disques sd[bcde] ont bien une partition raid linux * après un arrêt de md2 (mdadm --stop /dev/md2), le redémarrage indique des problèmes d'UUID sur les disques (mdadm --assemble /dev/md2)
Mais encore ?
mdadm --stop /dev/md2 mdadm --assemble -v /dev/md2 pvscan vgscan vgchange -a y mount -a exit
et le serveur démarre...
En fait j'aurais voulu des précisions sur la teneur du message qui "indique des problèmes d'UUID".
De mémoire, la teneur est : pas le bon "uuid"...
Lors de l'assemblage de /dev/md2, je présume ? Sans le message exact et complet, ça ne me dit rien.
Jean-Michel OLTRA
Bonjour,
Le lundi 28 décembre 2015, a écrit...
Je viens de constater que mon serveur domestique ne démarre plus (XEN4.0 + lenny LTS).
Le symptôme initial est qu'il ne trouve pas /var et /home qui sont des volumes logique sur un volume en RAID5.
Le volume en raid5 ne comporte qu'un disque sur quatre et n'est donc pas démarré (sd[bcde]).
Ce volume a été crée en 2010, il a fonctionner sans trop de problème jusque là.
Et tu as fait quelque chose entre temps ? Car une histoire d'uuid (si je m'en tiens aux courriels suivants), c'est un peu bizarre si rien n'a été modifié ? Disques ? Mise à jour ?
-- jm
Bonjour,
Le lundi 28 décembre 2015, yann@ianco.org a écrit...
Je viens de constater que mon serveur domestique ne démarre plus (XEN4.0 +
lenny LTS).
Le symptôme initial est qu'il ne trouve pas /var et /home qui sont des
volumes logique sur un volume en RAID5.
Le volume en raid5 ne comporte qu'un disque sur quatre et n'est donc pas
démarré (sd[bcde]).
Ce volume a été crée en 2010, il a fonctionner sans trop de problème jusque
là.
Et tu as fait quelque chose entre temps ? Car une histoire d'uuid (si je
m'en tiens aux courriels suivants), c'est un peu bizarre si rien n'a été
modifié ? Disques ? Mise à jour ?
Je viens de constater que mon serveur domestique ne démarre plus (XEN4.0 + lenny LTS).
Le symptôme initial est qu'il ne trouve pas /var et /home qui sont des volumes logique sur un volume en RAID5.
Le volume en raid5 ne comporte qu'un disque sur quatre et n'est donc pas démarré (sd[bcde]).
Ce volume a été crée en 2010, il a fonctionner sans trop de problème jusque là.
Et tu as fait quelque chose entre temps ? Car une histoire d'uuid (si je m'en tiens aux courriels suivants), c'est un peu bizarre si rien n'a été modifié ? Disques ? Mise à jour ?
J'ai redémarré le serveur pour de nouveau avoir le problème...
Ce n'était pas nécessaire, il suffisait de fouiller dans les logs.
Pascal Hambourg
Yann COHEN a écrit :
Bonjour,
J'ai redémarré le serveur pour de nouveau avoir le problème... Je joins le log de mdadm --assemble /dev/md2
============ > mdadm: looking for devices for /dev/md2
mdadm: no RAID superblock on /dev/sdc mdadm: /dev/sdc has wrong uuid. mdadm: no RAID superblock on /dev/sdd mdadm: /dev/sdd has wrong uuid. mdadm: no RAID superblock on /dev/sde mdadm: /dev/sde has wrong uuid. mdadm: cannot open device /dev/md/1: Device or resource busy mdadm: /dev/md/1 has wrong uuid. mdadm: no RAID superblock on /dev/md/0 mdadm: /dev/md/0 has wrong uuid. mdadm: no RAID superblock on /dev/sdb mdadm: /dev/sdb has wrong uuid. mdadm: cannot open device /dev/sda2: Device or resource busy mdadm: /dev/sda2 has wrong uuid. mdadm: cannot open device /dev/sda1: Device or resource busy mdadm: /dev/sda1 has wrong uuid. mdadm: cannot open device /dev/sda: Device or resource busy mdadm: /dev/sda has wrong uuid. mdadm: /dev/sdc1 is identified as a member of /dev/md2, slot 0. mdadm: /dev/sdd1 is identified as a member of /dev/md2, slot 1. mdadm: /dev/sde1 is identified as a member of /dev/md2, slot 2. mdadm: /dev/sdb1 is identified as a member of /dev/md2, slot 3. mdadm: added /dev/sdd1 to /dev/md2 as 1 mdadm: added /dev/sde1 to /dev/md2 as 2 mdadm: added /dev/sdb1 to /dev/md2 as 3 mdadm: added /dev/sdc1 to /dev/md2 as 0 mdadm: /dev/md2 has been started with 4 drives.
============ Les messages "wrong uuid" ne concernent que des périphériques (disques ou partitions) qui ne sont pas membres de /dev/md2. En revanche les 4 partitions membres sont bien reconnues. Rien d'anormal donc.
Yann COHEN a écrit :
Bonjour,
J'ai redémarré le serveur pour de nouveau avoir le problème...
Je joins le log de mdadm --assemble /dev/md2
============ > mdadm: looking for devices for /dev/md2
mdadm: no RAID superblock on /dev/sdc
mdadm: /dev/sdc has wrong uuid.
mdadm: no RAID superblock on /dev/sdd
mdadm: /dev/sdd has wrong uuid.
mdadm: no RAID superblock on /dev/sde
mdadm: /dev/sde has wrong uuid.
mdadm: cannot open device /dev/md/1: Device or resource busy
mdadm: /dev/md/1 has wrong uuid.
mdadm: no RAID superblock on /dev/md/0
mdadm: /dev/md/0 has wrong uuid.
mdadm: no RAID superblock on /dev/sdb
mdadm: /dev/sdb has wrong uuid.
mdadm: cannot open device /dev/sda2: Device or resource busy
mdadm: /dev/sda2 has wrong uuid.
mdadm: cannot open device /dev/sda1: Device or resource busy
mdadm: /dev/sda1 has wrong uuid.
mdadm: cannot open device /dev/sda: Device or resource busy
mdadm: /dev/sda has wrong uuid.
mdadm: /dev/sdc1 is identified as a member of /dev/md2, slot 0.
mdadm: /dev/sdd1 is identified as a member of /dev/md2, slot 1.
mdadm: /dev/sde1 is identified as a member of /dev/md2, slot 2.
mdadm: /dev/sdb1 is identified as a member of /dev/md2, slot 3.
mdadm: added /dev/sdd1 to /dev/md2 as 1
mdadm: added /dev/sde1 to /dev/md2 as 2
mdadm: added /dev/sdb1 to /dev/md2 as 3
mdadm: added /dev/sdc1 to /dev/md2 as 0
mdadm: /dev/md2 has been started with 4 drives.
============ Les messages "wrong uuid" ne concernent que des périphériques (disques
ou partitions) qui ne sont pas membres de /dev/md2. En revanche les 4
partitions membres sont bien reconnues. Rien d'anormal donc.
J'ai redémarré le serveur pour de nouveau avoir le problème... Je joins le log de mdadm --assemble /dev/md2
============ > mdadm: looking for devices for /dev/md2
mdadm: no RAID superblock on /dev/sdc mdadm: /dev/sdc has wrong uuid. mdadm: no RAID superblock on /dev/sdd mdadm: /dev/sdd has wrong uuid. mdadm: no RAID superblock on /dev/sde mdadm: /dev/sde has wrong uuid. mdadm: cannot open device /dev/md/1: Device or resource busy mdadm: /dev/md/1 has wrong uuid. mdadm: no RAID superblock on /dev/md/0 mdadm: /dev/md/0 has wrong uuid. mdadm: no RAID superblock on /dev/sdb mdadm: /dev/sdb has wrong uuid. mdadm: cannot open device /dev/sda2: Device or resource busy mdadm: /dev/sda2 has wrong uuid. mdadm: cannot open device /dev/sda1: Device or resource busy mdadm: /dev/sda1 has wrong uuid. mdadm: cannot open device /dev/sda: Device or resource busy mdadm: /dev/sda has wrong uuid. mdadm: /dev/sdc1 is identified as a member of /dev/md2, slot 0. mdadm: /dev/sdd1 is identified as a member of /dev/md2, slot 1. mdadm: /dev/sde1 is identified as a member of /dev/md2, slot 2. mdadm: /dev/sdb1 is identified as a member of /dev/md2, slot 3. mdadm: added /dev/sdd1 to /dev/md2 as 1 mdadm: added /dev/sde1 to /dev/md2 as 2 mdadm: added /dev/sdb1 to /dev/md2 as 3 mdadm: added /dev/sdc1 to /dev/md2 as 0 mdadm: /dev/md2 has been started with 4 drives.
============ Les messages "wrong uuid" ne concernent que des périphériques (disques ou partitions) qui ne sont pas membres de /dev/md2. En revanche les 4 partitions membres sont bien reconnues. Rien d'anormal donc.
Est-ce que tu as un fichier /boot/grub/device.map ?
Quel rapport avec le problème exposé ? Ce fichier ne sert qu'à GRUB, et a priori ce dernier fait correctement son travail qui se limite à charger le noyau et l'initramfs. C'est après que ça se gâte.
Christophe Moille a écrit :
Est-ce que tu as un fichier /boot/grub/device.map ?
Quel rapport avec le problème exposé ? Ce fichier ne sert qu'à GRUB, et
a priori ce dernier fait correctement son travail qui se limite à
charger le noyau et l'initramfs. C'est après que ça se gâte.
Est-ce que tu as un fichier /boot/grub/device.map ?
Quel rapport avec le problème exposé ? Ce fichier ne sert qu'à GRUB, et a priori ce dernier fait correctement son travail qui se limite à charger le noyau et l'initramfs. C'est après que ça se gâte.
Yann Cohen
Le mardi 29 décembre 2015 à 12:08 +0100, Christophe Moille a écrit :
Le Tuesday 29 Dec 2015 à 11:48:43 (+0100), Yann COHEN a écrit : > > Bonjour, > > J'ai redémarré le serveur pour de nouveau avoir le problème... > Je joins le log de mdadm --assemble /dev/md2 > > Cordialement. >
> mdadm: looking for devices for /dev/md2 > mdadm: no RAID superblock on /dev/sdc > mdadm: /dev/sdc has wrong uuid.
Salut,
Est-ce que tu as un fichier /boot/grub/device.map ? Si oui, vérifie qu'il contient bien les bonnes indications pour ta configuration matérielle.
Bonjour,
Il y a 5 entrées dans ce fichier, dont une qui n'a rien à y faire : une clé USB qui devait être présente lors d'une action de mise à jour de grub je suppose... ----------- (hd0) /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WCAV5F179623 (hd1) /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WCAV5F179870 (hd2) /dev/disk/by-id/ata-WDC_WD10EARS-22Y5B1_WD-WCAV5F897292 (hd3) /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WCAV5H540738 (hd4) /dev/disk/by-id/usb-_USB_DISK_2.0_07811E510276-0:0 (hd5) /dev/disk/by-id/ata-ELITE_PRO_CF_CARD_4GB_20090410_0000DC7B -------------
Tu peux le mettre à jour avec la commande `grub-mkdevicemap`. Attention à bien sauvegarder /boot/grub/device.map avant de l'exécuter.
Une fois la commande passée, il n'y a plus que les 4 disques nécessaires... --------- (hd0) /dev/disk/by-id/ata-ELITE_PRO_CF_CARD_4GB_20090410_0000DC7B (hd1) /dev/disk/by-id/ata-WDC_WD10EARS-00MVWB0_WD-WMAZA6804796 (hd2) /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WCAV5F179623 (hd3) /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WCAV5F179870 (hd4) /dev/disk/by-id/ata-WDC_WD10EARS-22Y5B1_WD-WCAV5F897292 --------
Par contre l'ordre change, cela a-t-il une importance ?
Yann.
Le mardi 29 décembre 2015 à 12:08 +0100, Christophe Moille a écrit :
Le Tuesday 29 Dec 2015 à 11:48:43 (+0100), Yann COHEN a écrit :
>
> Bonjour,
>
> J'ai redémarré le serveur pour de nouveau avoir le problème...
> Je joins le log de mdadm --assemble /dev/md2
>
> Cordialement.
>
> mdadm: looking for devices for /dev/md2
> mdadm: no RAID superblock on /dev/sdc
> mdadm: /dev/sdc has wrong uuid.
Salut,
Est-ce que tu as un fichier /boot/grub/device.map ? Si oui, vérifie
qu'il contient bien les bonnes indications pour ta configuration
matérielle.
Bonjour,
Il y a 5 entrées dans ce fichier, dont une qui n'a rien à y faire : une
clé USB qui devait être présente lors d'une action de mise à jour de
grub je suppose...
-----------
(hd0) /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WCAV5F179623
(hd1) /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WCAV5F179870
(hd2) /dev/disk/by-id/ata-WDC_WD10EARS-22Y5B1_WD-WCAV5F897292
(hd3) /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WCAV5H540738
(hd4) /dev/disk/by-id/usb-_USB_DISK_2.0_07811E510276-0:0
(hd5) /dev/disk/by-id/ata-ELITE_PRO_CF_CARD_4GB_20090410_0000DC7B
-------------
Tu peux le mettre à jour avec la commande `grub-mkdevicemap`. Attention
à bien sauvegarder /boot/grub/device.map avant de l'exécuter.
Une fois la commande passée, il n'y a plus que les 4 disques
nécessaires...
---------
(hd0) /dev/disk/by-id/ata-ELITE_PRO_CF_CARD_4GB_20090410_0000DC7B
(hd1) /dev/disk/by-id/ata-WDC_WD10EARS-00MVWB0_WD-WMAZA6804796
(hd2) /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WCAV5F179623
(hd3) /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WCAV5F179870
(hd4) /dev/disk/by-id/ata-WDC_WD10EARS-22Y5B1_WD-WCAV5F897292
--------
Par contre l'ordre change, cela a-t-il une importance ?
Le mardi 29 décembre 2015 à 12:08 +0100, Christophe Moille a écrit :
Le Tuesday 29 Dec 2015 à 11:48:43 (+0100), Yann COHEN a écrit : > > Bonjour, > > J'ai redémarré le serveur pour de nouveau avoir le problème... > Je joins le log de mdadm --assemble /dev/md2 > > Cordialement. >
> mdadm: looking for devices for /dev/md2 > mdadm: no RAID superblock on /dev/sdc > mdadm: /dev/sdc has wrong uuid.
Salut,
Est-ce que tu as un fichier /boot/grub/device.map ? Si oui, vérifie qu'il contient bien les bonnes indications pour ta configuration matérielle.
Bonjour,
Il y a 5 entrées dans ce fichier, dont une qui n'a rien à y faire : une clé USB qui devait être présente lors d'une action de mise à jour de grub je suppose... ----------- (hd0) /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WCAV5F179623 (hd1) /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WCAV5F179870 (hd2) /dev/disk/by-id/ata-WDC_WD10EARS-22Y5B1_WD-WCAV5F897292 (hd3) /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WCAV5H540738 (hd4) /dev/disk/by-id/usb-_USB_DISK_2.0_07811E510276-0:0 (hd5) /dev/disk/by-id/ata-ELITE_PRO_CF_CARD_4GB_20090410_0000DC7B -------------
Tu peux le mettre à jour avec la commande `grub-mkdevicemap`. Attention à bien sauvegarder /boot/grub/device.map avant de l'exécuter.
Une fois la commande passée, il n'y a plus que les 4 disques nécessaires... --------- (hd0) /dev/disk/by-id/ata-ELITE_PRO_CF_CARD_4GB_20090410_0000DC7B (hd1) /dev/disk/by-id/ata-WDC_WD10EARS-00MVWB0_WD-WMAZA6804796 (hd2) /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WCAV5F179623 (hd3) /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WCAV5F179870 (hd4) /dev/disk/by-id/ata-WDC_WD10EARS-22Y5B1_WD-WCAV5F897292 --------
Par contre l'ordre change, cela a-t-il une importance ?
