Différences

Ci-dessous, les différences entre deux révisions de la page.

--- technique:incidents:incident-17-05-19 [2020/02/14 21:26] – qduchemi
+++ technique:incidents:incident-17-05-19 [2021/01/19 23:06] (Version actuelle) – qduchemi
@@ Ligne 1: / Ligne 1: @@
+# 2019/05/17 : plus assez de place pour le nouveau noyau
+## Contexte
+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).
+## Problème survenu
+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
+## Résolution du problème
+Puisqu'il s'agissait d'une machine physique qui n'a pas redémarré, nous avons essayé d'utiliser les [accès VNC](https://wiki.picasoft.net/doku.php?id=infrastructure:installationmachines&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](https://fr.wikipedia.org/wiki/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.