Pb de RAID au re démarrage d'un serveur XEN : le RAID5 ne voit plus qu'un disque sur 4.

Le
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

Merci de vos conseils.

Yann.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal Hambourg
Le #26382312
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.
Yann Cohen
Le #26382332
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
Le #26382338
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.
Jean-Michel OLTRA
Le #26382341
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
Yann COHEN
Le #26382425
--=-yrphLpQLOgsHVjdrT7rM
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit


Bonjour,

J'ai redémarré le serveur pour de nouveau avoir le problème...
Je joins le log de mdadm --assemble /dev/md2

Cordialement.

Le lundi 28 décembre 2015 à 16:42 +0100, Pascal Hambourg a écrit :
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.





--=-yrphLpQLOgsHVjdrT7rM
Content-Disposition: attachment; filename="assemble.txt"
Content-Transfer-Encoding: base64
Content-Type: text/plain; name="assemble.txt"; charset="UTF-8"

bWRhZG06IGxvb2tpbmcgZm9yIGRldmljZXMgZm9yIC9kZXYvbWQyCm1kYWRtOiBubyBSQUlEIHN1
cGVyYmxvY2sgb24gL2Rldi9zZGMKbWRhZG06IC9kZXYvc2RjIGhhcyB3cm9uZyB1dWlkLgptZGFk
bTogbm8gUkFJRCBzdXBlcmJsb2NrIG9uIC9kZXYvc2RkCm1kYWRtOiAvZGV2L3NkZCBoYXMgd3Jv
bmcgdXVpZC4KbWRhZG06IG5vIFJBSUQgc3VwZXJibG9jayBvbiAvZGV2L3NkZQptZGFkbTogL2Rl
di9zZGUgaGFzIHdyb25nIHV1aWQuCm1kYWRtOiBjYW5ub3Qgb3BlbiBkZXZpY2UgL2Rldi9tZC8x
OiBEZXZpY2Ugb3IgcmVzb3VyY2UgYnVzeQptZGFkbTogL2Rldi9tZC8xIGhhcyB3cm9uZyB1dWlk
LgptZGFkbTogbm8gUkFJRCBzdXBlcmJsb2NrIG9uIC9kZXYvbWQvMAptZGFkbTogL2Rldi9tZC8w
IGhhcyB3cm9uZyB1dWlkLgptZGFkbTogbm8gUkFJRCBzdXBlcmJsb2NrIG9uIC9kZXYvc2RiCm1k
YWRtOiAvZGV2L3NkYiBoYXMgd3JvbmcgdXVpZC4KbWRhZG06IGNhbm5vdCBvcGVuIGRldmljZSAv
ZGV2L3NkYTI6IERldmljZSBvciByZXNvdXJjZSBidXN5Cm1kYWRtOiAvZGV2L3NkYTIgaGFzIHdy
b25nIHV1aWQuCm1kYWRtOiBjYW5ub3Qgb3BlbiBkZXZpY2UgL2Rldi9zZGExOiBEZXZpY2Ugb3Ig
cmVzb3VyY2UgYnVzeQptZGFkbTogL2Rldi9zZGExIGhhcyB3cm9uZyB1dWlkLgptZGFkbTogY2Fu
bm90IG9wZW4gZGV2aWNlIC9kZXYvc2RhOiBEZXZpY2Ugb3IgcmVzb3VyY2UgYnVzeQptZGFkbTog
L2Rldi9zZGEgaGFzIHdyb25nIHV1aWQuCm1kYWRtOiAvZGV2L3NkYzEgaXMgaWRlbnRpZmllZCBh
cyBhIG1lbWJlciBvZiAvZGV2L21kMiwgc2xvdCAwLgptZGFkbTogL2Rldi9zZGQxIGlzIGlkZW50
aWZpZWQgYXMgYSBtZW1iZXIgb2YgL2Rldi9tZDIsIHNsb3QgMS4KbWRhZG06IC9kZXYvc2RlMSBp
cyBpZGVudGlmaWVkIGFzIGEgbWVtYmVyIG9mIC9kZXYvbWQyLCBzbG90IDIuCm1kYWRtOiAvZGV2
L3NkYjEgaXMgaWRlbnRpZmllZCBhcyBhIG1lbWJlciBvZiAvZGV2L21kMiwgc2xvdCAzLgptZGFk
bTogYWRkZWQgL2Rldi9zZGQxIHRvIC9kZXYvbWQyIGFzIDEKbWRhZG06IGFkZGVkIC9kZXYvc2Rl
MSB0byAvZGV2L21kMiBhcyAyCm1kYWRtOiBhZGRlZCAvZGV2L3NkYjEgdG8gL2Rldi9tZDIgYXMg
MwptZGFkbTogYWRkZWQgL2Rldi9zZGMxIHRvIC9kZXYvbWQyIGFzIDAKbWRhZG06IC9kZXYvbWQy
IGhhcyBiZWVuIHN0YXJ0ZWQgd2l0aCA0IGRyaXZlcy4K


--=-yrphLpQLOgsHVjdrT7rM--
Pascal Hambourg
Le #26382430
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.
Pascal Hambourg
Le #26382431
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.
Christophe Moille
Le #26382432
--r5Pyd7+fXNt84Ff3
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.

Tu peux le mettre à jour avec la commande `grub-mkdevicemap`. Attention
à bien sauvegarder /boot/grub/device.map avant de l'exécuter.


--
J'utilise PGP pour améliorer la confidentialité de mes correspondances.
Défendez-vous contre la surveillance: https://emailselfdefense.fsf.org/fr/

--r5Pyd7+fXNt84Ff3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJWgmm3AAoJEPtelkJAfN5EojAQALSbayav9SlCTeYMmWw698f5
YocDEahTxW7y90UVER/pvFjD/DWEbzfsLKzyHcJMImg64ssUrB1S0VdCqmb0oPUN
SVlGVkVmO7GTJANrXHSA/gbvw+n/VhldgBlgi9W8dT5fSeyzzk5LQXLJx1NqtZiQ
KQJMuaSrBkDgf3Ze8uwma0jWgONXVIebW/4cS+TXacOnOU1ALiqMynY+Ve8DbGhE
NL5l7JBFc2i4g/2kTdzqtObUtokldof8HNglzHos/a0M0RkTFNrkBrAse0cCxtqg
c/k6P5FM2lnWpT12erNmGF8LarNhopeEqxhGRrdk7KjUp2G7IxFicIQs5ctH9DP5
bwDrobZ7GOG2ldQOArBrIhcd3h2wpMWC94JoDzAHE0pdb6sBBrFPub4ThVcZPQqC
rVNFdIIY6YFFDRJmU6Qifk8bibjo2/WVDTQtiN99nuKplryUyOP6uc+t4gcRcKUv
stDWHdb1Bs9xvtCEPH0NFClCNcsuy+sbk7gLxI0EI0xCbFoLz3QiiCc5uQpCZhxM
XElzxb6jMRvx1J5ru4wmEqP7szhp5wxRehXsMKNXNYxFT/f8lASTxRwtOWV6+cB3
JyqG8eI8BAidPqq2b+za0zspYbexlJTp5eTzAPG1ie0jRPDWYURNMHiZEfyAM6M8
8YCmSCHmlxwqdupjllmq
=r8qg
-----END PGP SIGNATURE-----

--r5Pyd7+fXNt84Ff3--
Pascal Hambourg
Le #26382439
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.
Yann Cohen
Le #26382442
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.


Publicité
Poster une réponse
Anonyme