# 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.