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...
Le mardi 29 décembre 2015 à 12:07 +0100, Pascal Hambourg a écrit :
Yann COHEN a écrit : > > 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.
Certes je n'y avais pas songé,
mais les logs sont dans /var/log/syslog alors que lorsque on passe la commande le volume /var n'est pas monté (il est dans le volume raid5).
Donc lorsque le serveur est redémarré /var pointe sur le raid5 et je ne pense pas que les traces générées avant le montage de /var soient accessibles...
Yann.
Le mardi 29 décembre 2015 à 12:07 +0100, Pascal Hambourg a écrit :
Yann COHEN a écrit :
>
> 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.
Certes je n'y avais pas songé,
mais les logs sont dans /var/log/syslog alors que lorsque on passe la
commande le volume /var n'est pas monté (il est dans le volume raid5).
Donc lorsque le serveur est redémarré /var pointe sur le raid5 et je ne
pense pas que les traces générées avant le montage de /var soient
accessibles...
Le mardi 29 décembre 2015 à 12:07 +0100, Pascal Hambourg a écrit :
Yann COHEN a écrit : > > 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.
Certes je n'y avais pas songé,
mais les logs sont dans /var/log/syslog alors que lorsque on passe la commande le volume /var n'est pas monté (il est dans le volume raid5).
Donc lorsque le serveur est redémarré /var pointe sur le raid5 et je ne pense pas que les traces générées avant le montage de /var soient accessibles...
Le Tuesday 29 Dec 2015 à 13:27:55 (+0100), Pascal Hambourg a écrit :
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.
l'initramfs a une copie du mdadm.conf. S'il n'est pas à jour avec les bonnes infos, les raids ne vont pas être directement montés.
J'ai déjà eu un souci auquel cette problématique m'avait fait penser. Quand j'ai ce genre de pb, je fais ces commandes, et ça le règle:
cp /boot/grub/device.map /boot/grub/device.map.backup grub-mkdevicemap grub-install "(hdx)" # avec x les chiffres des disques de la partition /bo ot update-initramfs -u update-grub
Si tout ça passe, je suis à peu près certain que le soucis seront réglés.
-- « Le vieux monde se meurt, le nouveau monde tarde à apparaître, et dans ce clair-obscur surgissent les monstres » - Gramsci
--r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature
Le Tuesday 29 Dec 2015 à 13:27:55 (+0100), Pascal Hambourg a écrit :
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.
l'initramfs a une copie du mdadm.conf. S'il n'est pas à jour avec les
bonnes infos, les raids ne vont pas être directement montés.
J'ai déjà eu un souci auquel cette problématique m'avait fait penser.
Quand j'ai ce genre de pb, je fais ces commandes, et ça le règle:
cp /boot/grub/device.map /boot/grub/device.map.backup
grub-mkdevicemap
grub-install "(hdx)" # avec x les chiffres des disques de la partition /bo ot
update-initramfs -u
update-grub
Si tout ça passe, je suis à peu près certain que le soucis seront
réglés.
--
« Le vieux monde se meurt, le nouveau monde tarde à apparaître, et
dans ce clair-obscur surgissent les monstres »
- Gramsci
--r5Pyd7+fXNt84Ff3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Le Tuesday 29 Dec 2015 à 13:27:55 (+0100), Pascal Hambourg a écrit :
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.
l'initramfs a une copie du mdadm.conf. S'il n'est pas à jour avec les bonnes infos, les raids ne vont pas être directement montés.
J'ai déjà eu un souci auquel cette problématique m'avait fait penser. Quand j'ai ce genre de pb, je fais ces commandes, et ça le règle:
cp /boot/grub/device.map /boot/grub/device.map.backup grub-mkdevicemap grub-install "(hdx)" # avec x les chiffres des disques de la partition /bo ot update-initramfs -u update-grub
Si tout ça passe, je suis à peu près certain que le soucis seront réglés.
-- « Le vieux monde se meurt, le nouveau monde tarde à apparaître, et dans ce clair-obscur surgissent les monstres » - Gramsci
--r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature
Le Tuesday 29 Dec 2015 à 13:27:55 (+0100), Pascal Hambourg a écrit :
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.
l'initramfs a une copie du mdadm.conf. S'il n'est pas à jour avec les bonnes infos, les raids ne vont pas être directement montés.
Pas forcément. Les ensembles RAID qui n'ont pas été assemblés par l'initramfs peuvent encore l'être par le script d'init mdadm lors de l'initialisation normale du système. Et quand bien même, cela ne nous dit toujours pas quel est le rapport avec le fichier device.map de GRUB.
Christophe Moille a écrit :
Le Tuesday 29 Dec 2015 à 13:27:55 (+0100), Pascal Hambourg a écrit :
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.
l'initramfs a une copie du mdadm.conf. S'il n'est pas à jour avec les
bonnes infos, les raids ne vont pas être directement montés.
Pas forcément. Les ensembles RAID qui n'ont pas été assemblés par
l'initramfs peuvent encore l'être par le script d'init mdadm lors de
l'initialisation normale du système. Et quand bien même, cela ne nous
dit toujours pas quel est le rapport avec le fichier device.map de GRUB.
Le Tuesday 29 Dec 2015 à 13:27:55 (+0100), Pascal Hambourg a écrit :
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.
l'initramfs a une copie du mdadm.conf. S'il n'est pas à jour avec les bonnes infos, les raids ne vont pas être directement montés.
Pas forcément. Les ensembles RAID qui n'ont pas été assemblés par l'initramfs peuvent encore l'être par le script d'init mdadm lors de l'initialisation normale du système. Et quand bien même, cela ne nous dit toujours pas quel est le rapport avec le fichier device.map de GRUB.
Yann Cohen
Le lundi 28 décembre 2015 à 17:58 +0100, Jean-Michel OLTRA a écrit :
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 ?
Hum...
Les dernières modifications sur ce serveur datent de plusieurs mois (par paquet de 12) lorsqu'un disque de la grappe RAID5 a lâché...
Ensuite (cet automne), j'ai rencontré des Pb de démarrage que j'ai identifiés comme étant dus à des problèmes d'alimentation : suite à des coupures d'énergie les fonctions "protection anti-surtension" du bios (asus M4A88TDV EVO/USB3) se déclenchaient => passage par le bios obligé...
Pour l'instant j'ai mis cela sur le compte de l'onduleur (ellipse premium 650)...
Ensuite ce serveur a été mis à jour régulièrement, mais redémarré que très rarement : sur arrêt énergie et involontairement (une fois par an max jusqu'à cet automne). Par contre les VM hébergées elles l'ont été plus souvent en fonction des mises à jour.
Yann.
Le lundi 28 décembre 2015 à 17:58 +0100, Jean-Michel OLTRA a écrit :
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 ?
Hum...
Les dernières modifications sur ce serveur datent de plusieurs mois (par
paquet de 12) lorsqu'un disque de la grappe RAID5 a lâché...
Ensuite (cet automne), j'ai rencontré des Pb de démarrage que j'ai
identifiés comme étant dus à des problèmes d'alimentation : suite à des
coupures d'énergie les fonctions "protection anti-surtension" du bios
(asus M4A88TDV EVO/USB3) se déclenchaient => passage par le bios
obligé...
Pour l'instant j'ai mis cela sur le compte de l'onduleur (ellipse
premium 650)...
Ensuite ce serveur a été mis à jour régulièrement, mais redémarré que
très rarement : sur arrêt énergie et involontairement (une fois par an
max jusqu'à cet automne). Par contre les VM hébergées elles l'ont été
plus souvent en fonction des mises à jour.
Le lundi 28 décembre 2015 à 17:58 +0100, Jean-Michel OLTRA a écrit :
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 ?
Hum...
Les dernières modifications sur ce serveur datent de plusieurs mois (par paquet de 12) lorsqu'un disque de la grappe RAID5 a lâché...
Ensuite (cet automne), j'ai rencontré des Pb de démarrage que j'ai identifiés comme étant dus à des problèmes d'alimentation : suite à des coupures d'énergie les fonctions "protection anti-surtension" du bios (asus M4A88TDV EVO/USB3) se déclenchaient => passage par le bios obligé...
Pour l'instant j'ai mis cela sur le compte de l'onduleur (ellipse premium 650)...
Ensuite ce serveur a été mis à jour régulièrement, mais redémarré que très rarement : sur arrêt énergie et involontairement (une fois par an max jusqu'à cet automne). Par contre les VM hébergées elles l'ont été plus souvent en fonction des mises à jour.
Yann.
Yann Cohen
Le mardi 29 décembre 2015 à 12:06 +0100, Pascal Hambourg a écrit :
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.
Oups, il va falloir que je lise un peu mieux les messages d'erreur...
Donc pas de problème sur l'array raid5 ; il me faut me concentrer sur la cause de la détection tardive des autres disques par rapport à la tentative de démarrer le raid5...
Le mardi 29 décembre 2015 à 12:06 +0100, Pascal Hambourg a écrit :
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.
Oups, il va falloir que je lise un peu mieux les messages d'erreur...
Donc pas de problème sur l'array raid5 ; il me faut me concentrer sur la
cause de la détection tardive des autres disques par rapport à la
tentative de démarrer le raid5...
Le mardi 29 décembre 2015 à 12:06 +0100, Pascal Hambourg a écrit :
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.
Oups, il va falloir que je lise un peu mieux les messages d'erreur...
Donc pas de problème sur l'array raid5 ; il me faut me concentrer sur la cause de la détection tardive des autres disques par rapport à la tentative de démarrer le raid5...
