technique:incidents:incident-17-05-19

Différences

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

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
technique:incidents:incident-17-05-19 [2020/02/06 16:28] – ↷ Page déplacée de incidents:incident-17-05-19 à technique:incidents:incident-17-05-19 qduchemitechnique: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.