Si vous avez passé les premiers jours de juin à lutter contre les paniques du noyau dans Ubuntu 20.04, vous n’étiez pas seul – et nous savons maintenant pourquoi.
Un problème avec un correctif du noyau Linux spécifique à Ubuntu au début du mois dernier a rendu de nombreux systèmes, exécutant Docker sur cette version du système d’exploitation inutilisable, et ce ne sera probablement pas la dernière fois.
Toute la débâcle peut être attribuée à une mauvaise mise à jour du noyau spécifique à la distribution pour Ubuntu 20.04 – la version de support à long terme (LTS) de Canonical – qui a commencé à être déployée le 8 juin ou vers cette date. déposer.
La source du problème a été rapidement isolée des systèmes Ubuntu exécutant Docker avec la pile d’activation matérielle (HWE) activée. Comme son nom l’indique, HWE ajoute la prise en charge du matériel plus récent en expédiant des noyaux mis à jour – et Ubuntu sort régulièrement de nouveaux noyaux via ces mises à jour HWE. Bien que l’activation soit généralement un processus manuel pour les systèmes de serveur, il s’agit d’une fonctionnalité standard sur de nombreuses images Ubuntu disponibles dans le cloud. À cette fin, plusieurs utilisateurs ont signalé que des images de VM sur AWS, GCP, Azure et Oracle étaient affectées. HWE est également généralement activé par défaut pour les nouvelles installations de bureau.
Le bogue lui-même déclenchait une panique du noyau à chaque démarrage d’un conteneur Docker. Certains utilisateurs ont même signalé que la mise à jour entraînait une boucle de démarrage et que le seul remède consistait à revenir à un noyau de travail précédent lors du démarrage. C’est probablement parce que leurs conteneurs Docker ont été configurés pour démarrer avec le reste du système, provoquant un cercle vicieux dans lequel Ubuntu démarre, les conteneurs Docker démarrent, le noyau du système panique… rincez, répétez.
Pour aggraver les choses, le service de mises à jour sans surveillance d’Ubuntu, qui est chargé de maintenir les systèmes corrigés et généralement exempts de problèmes, a rendu cette mise à jour du noyau plus difficile à éviter.
L’accident est dû à un publier avec /proc/self/map_files et systèmes de fichiers d’environnement de conteneur overlayfs et shiftfs que le patch du noyau avait l’intention de corriger. Un noyau révisé a été publié quelques jours plus tard par Ubuntu pour résoudre le problème. L’impact de ce correctif bâclé est difficile à évaluer, mais Ubuntu 20.04 reste un choix populaire pour les environnements de production grâce à sa durée de vie relativement longue.
Ironiquement, les cinq années de support qui rendent les versions LTS si populaires étaient également en partie à blâmer, selon un une analyse cette semaine par Jordan Webb, partagé via LWN.
Un point crucial dans cette saga est qu’Ubuntu a jusqu’au 21.04 inclus un autre système de fichiers lié aux conteneurs, aufs, dans ses noyaux Linux spécifiques à la distribution ; ce code de système de fichiers n’a jamais été fusionné dans le noyau principal et a été maintenu hors de l’arborescence. Lorsque les développeurs d’Ubuntu sont venus rétroporter le shiftfs-correctif lié à Ubuntu 20.04, en raison d’une chaîne d’événements, une partie du code du correctif a été abandonnée car il dépendait de aufs qui n’était pas présent lors du processus de rétroportage – mais aufs était en fait dans le noyau 5.13 utilisé par Ubuntu 20.04 HWE.
À cause de cela, et des changements dans la façon dont overlayfs fonctionnait en interne, une référence à la mémoire déjà libérée() dans une structure de données du noyau serait publiée, déclenchant une panique. Cela se produirait à chaque fois qu’un conteneur Docker démarrerait. Selon Webb, ce conflit a été détecté presque immédiatement et corrigé dans la source du noyau 5.15 d’Ubuntu. Mais pour des raisons qui ne sont pas claires, le noyau 5.13 d’Ubuntu 20.04 HWE a été négligé et continuerait à planter.
Comme le dit Webb :
Ce problème particulier a depuis été résolu, et toute personne qui n’est revenue que maintenant pour trouver le démarrage de ses déploiements de machines virtuelles ou de serveurs doit revenir à un noyau antérieur et mettre à jour ses systèmes.
Malheureusement, des gremlins comme ceux-ci peuvent être difficiles à éviter compte tenu de la durée de vie des versions LTS de Canonical, ce qui a conduit les développeurs à jongler simultanément avec plusieurs branches du noyau.
“Maintenir un correctif de noyau hors arbre pendant une durée quelconque est une tâche ardue”, a écrit Webb, ajoutant qu’il est peu probable que la situation devienne plus facile pour les développeurs du noyau Ubuntu et qu’elle pourrait en fait devenir plus difficile avant longtemps. ®
