Greg Kroah-Hartman a publié sept noyaux Linux stables le vendredi vingt quatre juillet, couvrant d'un coup toutes les branches maintenues : 7.1.5, 6.18.40, 6.12.97, 6.6.145, 6.1.178, 5.15.212 et 5.10.261. C'est le volume qui rend cette fournée digne d'un plan plutôt que d'un tampon. La version candidate 7.1.5 portait plus de deux mille correctifs et la candidate 6.18.40 en portait 1 611, ce qui est lourd pour la série stable. Si vous gérez des parcs répartis sur plusieurs branches, la vraie question n'est pas de savoir s'il faut prendre cette mise à jour. C'est dans quel ordre la prendre, et quoi surveiller ensuite.
The short answer
Le vendredi vingt quatre juillet, Greg Kroah-Hartman a publié 7.1.5, 6.18.40, 6.12.97, 6.6.145, 6.1.178, 5.15.212 et 5.10.261, rafraîchissant la série stable et toutes les branches de support à long terme maintenues le même jour. Les deux plus récentes portaient une charge de correctifs inhabituellement lourde. Deux changements méritent un test ciblé : un correctif de corruption de données sur XFS, et une divergence du vérificateur BPF sur s390 signalée comme régression. Linux 7.2 en est à sa quatrième version candidate et sa publication stable est attendue en août, donc c'est bien cette fournée qu'il faut planifier maintenant.
La plupart des annonces de noyau stable tiennent en une ligne de liste de diffusion et une mise à jour de paquet trois jours plus tard. Celle ci mérite dix minutes d'attention, non parce qu'il s'est passé quelque chose de spectaculaire, mais à cause du volume. Le vendredi vingt quatre juillet, sept noyaux sont sortis d'un coup et deux d'entre eux portaient plusieurs fois le nombre habituel de changements.
Ce qui est sorti
La liste est 7.1.5, 6.18.40, 6.12.97, 6.6.145, 6.1.178, 5.15.212 et 5.10.261. Cela couvre la série stable courante et toutes les branches de support à long terme encore maintenues, rafraîchies le même jour. Les archives sont sur kernel.org, et pour la plupart des lecteurs le chemin de livraison réel sera un paquet de distribution qui arrivera sous quelques jours.
Le poids est l'élément notable. La candidate 7.1.5 portait plus de deux mille correctifs. La candidate 6.18.40 en portait 1 611. Une publication de maintenance ordinaire sur une branche installée en compte souvent quelques centaines, donc les deux branches les plus récentes ont pris plusieurs fois leur charge habituelle en un seul cycle. Les branches anciennes étaient bien plus légères, ce qui correspond exactement à ce que doit être une branche mûre, puisque les rétroportages qui s'appliquent encore proprement à 5.10 se raréfient chaque année.
Deux points à tester exprès
Une grosse fournée n'est pas automatiquement une fournée risquée, mais deux éléments sont ici assez précis pour être testés plutôt que supposés.
Le premier est un correctif de corruption de données sur XFS. Si vous exploitez XFS sous quoi que ce soit dont la perte vous ennuierait, traitez cette publication comme une chose à planifier plutôt qu'à reporter, et profitez en pour vérifier qu'une restauration depuis vos sauvegardes fonctionne réellement. Les correctifs de corruption sont la catégorie où le retard se paie en données, pas en temps d'arrêt.
Le second est une divergence du vérificateur affectant BPF sur s390, signalée comme régression. La surface est étroite, mais si vous faites tourner de l'outillage BPF sur IBM Z, c'est votre surface, et une régression est précisément ce qu'une grosse fournée peut emmener avec le reste. Sollicitez ce chemin délibérément sur un témoin avant de déployer sur un anneau.
Sur quelle branche vous devriez être
Si vous renouvelez du matériel ou standardisez un nouveau parc, 6.18 est la branche de support à long terme la plus récente, donc celle qui offre la plus longue marge. Les systèmes déjà posés sur 6.12 ou 6.6 sont sur un terrain raisonnable et n'ont pas à bouger pour cette publication.
Les branches auxquelles il faut réfléchir sont 5.15 et 5.10. Elles sont encore maintenues, elles reçoivent bien ces mises à jour, et elles sont aussi en fin de vie. Chaque mois passé dessus élargit le saut qu'il faudra faire, car plus deux branches divergent, plus vos modules hors arbre, vos particularités de pilotes et vos hypothèses de réglage doivent être revalidés en même temps. Si vous montez encore des machines neuves sur 5.10 à la mi 2026, c'est le choix de branche qui figure sur votre liste, pas cette publication de maintenance.
N'attendez pas 7.2
Linux 7.2 a atteint sa quatrième version candidate à peu près en même temps que cette fournée, et la publication stable est attendue en août. Ce noyau est en bonne voie pour devenir celui par défaut des distributions d'automne, dont Ubuntu 26.10.
C'est une raison de prendre cette mise à jour maintenant plutôt qu'une raison d'attendre plus récent. Les décisions de noyau en production suivent le calendrier de livraison de votre distribution, pas la date de l'étiquette dans la branche principale. Appliquez la publication stable de la branche que vous exploitez déjà, gardez un témoin dans chaque anneau, et évaluez 7.2 quand elle arrivera empaquetée et testée par ceux qui assurent le support de vos systèmes.
Sources et pour aller plus loin
- LWN : grosses mises à jour de noyaux stables pour ce vendredi
- Linux Compatible : le noyau 6.18.40 et cinq branches LTS publiés dans un large cycle stable de juillet
- Phoronix : Linux 7.2-rc3 publiée, proche de la nouvelle normale
- The New Stack : Linux 6.18, tout sur le nouveau noyau de support à long terme
Questions fréquentes
Quelles versions du noyau ont été publiées le vingt quatre juillet ?
Greg Kroah-Hartman a annoncé 7.1.5, 6.18.40, 6.12.97, 6.6.145, 6.1.178, 5.15.212 et 5.10.261 le vendredi vingt quatre juillet 2026. Cela couvre la série stable courante ainsi que toutes les branches de support à long terme encore maintenues, rafraîchies le même jour. Les archives sources sont disponibles sur kernel.org comme d'habitude, et les distributions intègrent normalement ces changements dans leurs propres paquets noyau dans les jours qui suivent, donc la plupart des utilisateurs rencontreront ces mises à jour via leur distribution plutôt qu'en compilant depuis les sources.
Cette fournée était elle plus grosse qu'une publication stable habituelle ?
Plus grosse que d'ordinaire sur les branches récentes. La version candidate 7.1.5 portait plus de deux mille correctifs, et la candidate 6.18.40 en portait 1 611. Une publication de maintenance courante sur une branche mûre compte souvent quelques centaines de correctifs, donc ces deux là pèsent plusieurs fois le poids habituel. Les branches plus anciennes étaient bien plus légères, ce qui est attendu, puisqu'une branche comme 5.10 est maintenue depuis des années et ne reçoit plus que des rétroportages qui s'appliquent encore proprement à une base de code figée.
Sur quelle branche LTS faut il se standardiser ?
6.18 est la branche de support à long terme la plus récente, ce qui en fait la cible sensée pour les parcs qui renouvellent leur matériel ou qui veulent la plus longue marge devant eux. 6.12 et 6.6 restent un intermédiaire raisonnable pour les systèmes déjà standardisés dessus. Les branches 5.15 et 5.10 sont encore maintenues mais elles sont en fin de vie, et chaque mois passé dessus élargit l'écart qu'il faudra franchir un jour. Si vous montez encore de nouveaux systèmes sur 5.10 à la mi 2026, c'est le choix de branche qu'il faut corriger, pas cette publication de maintenance.
Que faut il surveiller après avoir appliqué cette mise à jour ?
Deux points de cette fournée méritent un test ciblé. Il y a un correctif de corruption de données sur XFS, donc si vous utilisez XFS sur quoi que ce soit d'important, c'est une publication à planifier plutôt qu'à reporter, et un bon moment pour vérifier que vos sauvegardes se restaurent vraiment. Il y a aussi une divergence du vérificateur affectant BPF sur s390, signalée comme régression, donc si vous exploitez de l'outillage BPF sur IBM Z, testez ce chemin délibérément avant un déploiement large. Le reste suit la pratique habituelle : démarrer un témoin, surveiller les chemins de stockage et de réseau, puis avancer par anneau.
Quand Linux 7.2 arrive t il ?
Linux 7.2 est au stade des versions candidates, avec 7.2-rc4 sortie à peu près en même temps que cette fournée stable, et la publication stable est attendue en août 2026. Ce noyau devrait devenir celui par défaut des distributions d'automne, dont Ubuntu 26.10. Pour la planification en production, cela signifie que 7.2 n'est pas une décision à prendre maintenant. Prenez la mise à jour stable de la branche que vous exploitez, et évaluez 7.2 quand votre distribution la livrera, pas quand l'étiquette apparaît dans la branche principale.