Différences
Ci-dessous, les différences entre deux révisions de la page.
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/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' | ||
+ | |||
+ | 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, | ||
+ | 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' | ||
+ | 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' | ||
+ | |||
+ | 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' | ||
+ | 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' | ||
+ | Néanmoins, cette dernière n'a jamais redémarré correctement | ||
+ | |||
+ | ## Résolution du problème | ||
+ | |||
+ | Puisqu' | ||
+ | Néanmois, nous n' | ||
+ | Après quelques temps de recherche, et étant donné que `bob` était en marche, nous avons eu l' | ||
+ | ``` | ||
+ | ssh login@bob.picasoft.net -N \ | ||
+ | -L 8081: | ||
+ | ``` | ||
+ | |||
+ | Ce rebond nous a permis d' | ||
+ | |||
+ | Nous avons alors décidé de lancer le redémarrage d' | ||
+ | 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:// | ||
+ | |||
+ | 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. |