2019/05/17 : plus assez de place pour le nouveau noyau

Le 17 mai 2019 au soir, une session technique est organisée pour permettre aux nouveaux de l’équipe technique de pratiquer en étant encadrés, et de découvrir l’infrastructure.

Lors de la session, une mise à jour des machines (VM + hyperviseurs) est lancée. Les noyaux devant être mis à jour, il est prévu de garder 15min à la fin de la session pour redémarrer les machines proprement (extinction des bases de donnnées puis des VM puis reboot des hyperviseurs pour éviter tout risque de corruption).

Lors de la mise à jour des hyperviseurs, le noyau est mis à jour. Sur un système debian normal, quand une mise à jour de noyau est faite, l’ancien est gardé en fallback, mais les précédents supprimés pour éviter de surcharger le /boot. Sur les machines physiques Picasoft, on note néanmoins que les anciens noyaux ne sont pas supprimés automatiquement. Ainsi, lors d’une mise à jour, si le système n’a pas la place nécessaire pour mettre à jour le noyau, il abandonne tout simplement la transaction et l’ancienne version est gardée. Il faut alors faire de la place à la main en désinstallant un ou deux noyaux obsolètes (attention de ne pas supprimer le noyau exécuté) Pour faire cela :

• Trouver la liste de noyaux installé : dpkg --list | grep pve-kernel
• Trouver le noyau qui est lancé : uname -a
• Utiliser apt purge pour enlever une ou deux des plus vieilles version présentes. Faire très attention de ne pas supprimer le noyau en cours d’exécution

Lors de cette mise à jour, les /boot des deux hyperviseurs étaient pleins. Par manque de concentration (bcp de choses à faire, de sollicitations…) le message d’erreur a été raté. Sur bob, la transaction a été abandonnée. Sur alice, chose qui ne devrait pas arriver, le noyau a été installé en partie

Les machines on ensuite été redémarrées à la suite l’une de l’autre. D’abord bob qui a redémarré normalement, puis alice. Néanmoins, cette dernière n’a jamais redémarré correctement

Puisqu’il s’agissait d’une machine physique qui n’a pas redémarré, nous avons essayé d’utiliser les accès VNC pour lancer le redémarrage à la main (sans savoir encore que la dernière version du noyau était corrompue). Néanmois, nous n’avons pas réussi à faire de rebond sur nagios.tetaneutral.net, les identifiants de Picasoft ayant sûrement été supprimés. Après quelques temps de recherche, et étant donné que bob était en marche, nous avons eu l’idée de passer par celui-ci pour le rebond. La commande devient alors pour avoir accès à alice :

ssh login@bob.picasoft.net -N \
-L 8081:192.168.128.151:16992 -L 5911:192.168.128.151:5900

Ce rebond nous a permis d’accéder à l’interface vPro d’alice et de tenter de lancer un redémarrage, en vain.

Nous avons alors décidé de lancer le redémarrage d’alice avec un VNC d’ouvert, pour voir ce qui se passait. Après une recherche relativement longue d’un client VNC fonctionnant correctement avec alice (tightVNC et tigerVNC ne fonctionnent pas) il s’est avéré que vinagre faisait l’affaire.

Après avoir ouvert la connexion, nous avons vu que le noyau ne voulait pas démarrer. Nous avons utilisé le vPro pour redémarrer alice encore un fois. Cette fois, le VNC nous a permis de choisir une ancienne version du noyau dans Grub, ce qui a permis de redémarrer alice et de refaire proprement la mise à jour.