Nopping

Il est peu probable, vu la fréquentation du site, que vous ayez
remarqué ces quelques jours d'absence totale du site.

Vu que j'ai un peu galéré a trouver ce qu'il se passait, je vais vous
en faire profiter histoire de ne pas faire la même erreur que moi.

L'histoire de la panne du serveur

Il y a environs 40 jours maintenant, le serveur tournait sur un kernel en
version 2.6.31-r5 et tout se passait bien. Une coupure de courant avait
eu lieu mais sans conséquences, le serveur étant repartis sans le
moindre problème. Je met à jour le serveur quasiment tous les jours,
sauf le kernel afin d'éviter de rebooter trop fréquemment. Je prend
tout de même les versions de chaque kernel en laissant passer une ou
deux révision. Ainsi, sur Gentoo, il y a eu les kernels 2.6.31-r6,
2.6.32 et 2.6.32-r1 que j'ai laissé passé, mais je me suis décider a
installer le 2.6.32-r2. Tout se passe bien, comme d'habitude, viens le
moment de rebooter le serveur pour qu'il passe sur l'autre kernel.

Et là c'est le drame

En bon serveur, il n'a pas d'interface graphique, d'ailleur si je pouvais
réussir a le faire démarrer sans carte graphique du tout ca
m'arrangerait. Il n'a donc même pas d'écran. Je fais tout par SSH. Sauf
que cette fois, il n'a pas démarré. Il a donc fallut que je me motive
à déplacer le serveur pour y connecter écran, clavier, .... tout ce
qu'il faut pour dépanner quand même SSH ne fonctionne plus.
Évidemment, comme le serveur n'a pas non plus de lecteur CD, il m'a
d'abord fallut transformer le LiveCD d'installation minimal de Gentoo, en
LiveUSB. Un des problème de ce LiveCD c'est qu'il demande l'intervention
humaine pour démarrer les bonnes choses. J'aurais aimé qu'il lance tout
seul SSH une fois démarré, en définissant un mot de passe root bateau
(genre "root" ou "password", on s'en fout, c'est pour dépanner) et qu'il
obtienne une config réseau correcte par DHCP. Ainsi, je n'aurait pas a
déplacer le serveur en cas de panne, j'ai juste a mettre la clef usb et
faire un hard reboot. Quelques temps plus tard le serveur serait donc
accessible par ssh pour me permettre d'en faire la maintenance sans avoir
a le déplacer et connecter écran/clavier/... dessus.

Mais bon, le LiveCD d'origine ne fait pas tout ca, il faut passer
manuellement des paramètre au boot, ce qui veux dire qu'il faut quand
meme connecter au moins un écran et un clavier. J'ai donc entreprit de
modifier le liveCD afin qu'il réponde a mes besoins. Raison pour
laquelle le dépannage à mis autant de temps. Je reviendrai dans un
prochain article sur comment modifier un LiveCD/LiveUSB.

Des symptômes trompeurs

Me voilà donc prêt à dépanner le serveur. Première étape : trouver
les symptômes. Direction /var/log, c'est ici qu'on trouve tout ce qui
s'est passé. Très vite je me rend compte que la très grande majorité
des services ne démarrent pas (apache, mysql, ntp, ...). Les logs
donnent des erreurs qui sur le coup m'ont semblé étrange : "impossible
d'ouvrir le fichier /usr/lib/...." (et beaucoup d'autres fichiers posés
ailleurs).

Si on réfléchit on doit se dire que s'il n'y arrive pas, c'est que le
fichier n'existe pas. Donc soit, le fichier à été supprimé pour une
raison inconnue (donc il faut réinstaller le programme ou recréer le
fichier si on peut), soit il n'arrive pas a lire le fichier parce que le
système de fichier (ext4 en l'occurrence) est corrompue (et donc il
faudrait faire un fsck). Mais en fait il y a une autre raison possible :
la partition n'est pas montée.

Pour le savoir, j'ai tout de même été contraint de déplacer le
serveur comme je le disais plus haut, car via le liveCD je peut monter
les partitions sans le moindre problème.

Et là, surprise, le serveur boot visiblement correctement en fait. Les
services ne démarrent pas, comme l'indiquait le log, mais c'est tout, je
peux quand même me loguer. Très vite je constate qu'effectivement il
n'a pas monté mes partitions. Ces partitions sont des volumes logiques
sur LVM, j'en ai rapidement conclut que LVM avait un problème. Après
lui avoir dit de rechercher les volumes logiques (vgchange -a y) j'ai
constaté qu'il n'en a trouvé aucun...

Pas étonnant qu'il ne trouve rien, mes /dev/sd* (disques et partitions)
n'existent pas !

Voilà, on a trouvé la conséquence du problème qui induit tous les
autres problèmes. Si je résous le mystère de la disparition de ces
périphérique, alors tout rentrera dans l'ordre.

L'incompréhension

Bon, mes périphériques n'existent pas, j'ai du modifié quelque chose
dans mon nouveau kernel, donc je reprend le dernier fonctionnel (le
2.6.31-r5) mais la, j'ai exactement le même problème, ce n'est donc pas
le kernel. La preuve :

serveur log # tail -25 /var/log/dmesg | head -12
ata3.00: HPA detected: current 976771055, native 976773168
ata3.00: ATA-8: WDC WD5000AAKS-00YGA0, 12.01C02, max UDMA/133
ata3.00: 976771055 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata3.00: configured for UDMA/133
scsi 2:0:0:0: Direct-Access ATA WDC WD5000AAKS-0 12.0 PQ: 0 ANSI: 5
sd 2:0:0:0: [sda] 976771055 512-byte logical blocks: (500 GB/465 GiB)
sd 2:0:0:0: Attached scsi generic sg0 type 0
sd 2:0:0:0: [sda] Write Protect is off
sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: sda1 sda2 sda3 sda4
sd 2:0:0:0: [sda] Attached SCSI disk

Comme on peut le voir, le kernel à correctement détecté mes partitions
et les à nommées comme il se doit. Alors pourquoi les périphériques
n'existent pas ? A cause d'udev évidemment ! Pour ceux qui ne savent
pas, udev est un service qui tourne dans l'espace utilisateur et dont le
but est de créer les fichier devices en fonctions d'évènements. Ainsi,
quand vous branchez une clef usb, udev créer un fichier associé. S'il
n'était pas la, il faudrait le faire nous même via mknod. Cependant il ne faut pas que le device reste
présent alors qu'on a enlevé la clef, donc udev supprimera le fichier
dès lors que la clef ne sera plus présente. Et il fait de même avec
tous les périphériques.

La solution

Mais alors, comment ca se fait qu'udev supprime les devices ? Celà vient
en réalité de sysfs. Il s'agit d'un pseudo système de fichier qui
permet, entre autre, la communication entre udev et le kernel. Or, les
nouvelle versions sysfs ont changé de "disposition". C'est à dire qu'il
n'est plus organisé de la même manière. Du coup, les nouvelles version
d'udev ont été également mises à niveau pour prendre en compte la
nouvelle disposition. Et c'est là où ca se complique. Le temps de la
transition, le kernel à implémenté une option de support de l'ancienne
version de sysfs, tout comme udev. Cependant, la toute dernière version
d'udev a totalement abandonné cette option de compatibilité et demande
donc maintenant un sysfs de nouvelle génération. Résultat, l'option de
compatibilité présente dans le kernel s'est transformée en option
d'incompatibilité. En effet, activer le support de l'ancien sysfs
empêche udev de fonctionner correctement. Il faut donc désactiver cette
option et recompiler le kernel, à ce moment, tout rentre dans l'ordre.

C'est ainsi que www.nopping.fr renait !