Gros problème avec Debian Jessie 8.4 chez OVH

Des problèmes avec Debian stable ça n’existe pas? Eh ben si, maintenant c’est fait chez OVH, on n’arrête pas le progrès…

Après mise à jour de Debian vers Jessie 8.4 en début de semaine, 2 serveurs ne rebootent pas. Le ping est OK, mais aucun service n’est démarré. Panique à bord, redémarrage en mode Rescue et réinstallation des paquets antérieurs à la mise à jour, ça occupe mais ouf les serveurs redémarrent!

Je signale le problème à OVH, qui le classe en « Requête générique » et ne me donne aucune réponse. Bizarre, d’habitude le support est plus réactif.

Après quelques recherches je me rends compte que le problème est lié à une incompatibilité entre le kernel OVH et la nouvelle version de systemd. C’est bien embêtant, les noyaux OVH sont optimisés pour leurs serveurs et on en a besoin, et comme systemd est le nouveau système d’init par défaut de Debian c’est compliqué de s’en passer.

Je ne suis pas un expert de systemd loin de là, et je ne sais pas déterminer la cause de cette incompatibilité, d’autant que rien ne s’inscrit dans les logs. Le problème se produit aussi bien en netboot qu’avec le noyau OVH installé sur le disque. Par contre aucun problème avec un noyau Debian standard. J’espère qu’OVH sortira rapidement un correctif et communiquera un peu plus sur le sujet. Je suis surpris de ne pas avoir trouvé plus de retours sur le sujet, je serais le seul à rebooter mes serveurs???

En attendant, voilà ce qu’on peut faire:

Si la mise à jour vers Jessie 8.4 n’a pas encore été faite, bloquer le paquet systemd dans sa version actuelle, 215-17+deb8u3 pour Jessie 8.3. Selon le gestionnaire de paquets utilisé:

sudo aptitude hold systemd

ou

sudo apt-mark hold systemd

Si la mise à jour a déjà été faite et que le serveur est planté, ça se complique un peu. Il faut d’abord sélectionner le mode « Rescue » via le manager OVH, et faire un reboot hard. Se connecter ensuite en root via ssh au serveur.

Monter la partition de démarrage du serveur, ici /dev/md2 :

mount -t ext4 /dev/md2 /mnt/

Monter les fichiers système:

mount -t proc proc /mnt/proc
mount -t sysfs /sys /mnt/sys
mount -o bind /dev /mnt/dev/

Ouvrir un shell sur le système du serveur:

chroot /mnt

Réinstaller les paquets systemd à leur version antérieure. Si le cache apt a été nettoyé et qu’ils ne sont plus là, il faudra d’abord les récupérer sur les dépôts Debian. Ici c’est pour l’architecture amd64, à adapter:

cd /var/cache/apt/archives/
dpkg -i libsystemd-login0_215-17+deb8u3_amd64.deb systemd_215-17+deb8u3_amd64.deb systemd-sysv_215-17+deb8u3_amd64.deb

Selon la config il peut y avoir des dépendances à réinstaller, par exemple libpam-systemd_215-17+deb8u3_amd64.deb.

Bloquer la mise à jour de systemd:

aptitude hold systemd

Dans le manager, remettre le boot en Netboot ou disque.
Faire un reboot soft depuis le shell Rescue et ça devrait repartir.

Edit-de-quelques-heures-plus-tard

J’ai eu une réponse de l’assistance OVH 4h après la publication de ce billet. Le problème ne concernerait que les machines utilisant lvm avec une partition /usr séparée. Ils proposent une solution permettant de booter sur le disque du serveur, mais pas par le netboot. La seule opération à faire est de créer une image initramfs pour le noyau OVH:

update-initramfs -tuk 3.14.32-xxxx-std-ipv6-64
update-grub

Ça fonctionne, mais il ne faudra pas oublier de créer l’image initramfs à chaque changement de kernel OVH.

Tout ça reste un peu bricolo, j’espère qu’OVH trouvera rapidement une solution pour rendre ses noyaux pleinement compatible avec systemd ET lvm.

Rating: 0.0/5 (0 votes cast)