Fedora 45 rate son second Go/No-Go et repousse sa sortie au 3 novembre
Le 22 octobre 2026, la réunion Go/No-Go de Fedora déclare un second NO-GO : la distribution ne sortira pas la semaine prochaine, plombée par des bugs bloquants qui touchent la mitigation eMudhra, LVM sur LUKS et KDE Discover. Retenez le 3 novembre comme nouvelle cible, et lisez la liste des blocages comme une leçon de discipline de release.
22 octobre 2026. La réunion Go/No-Go de Fedora 45 se conclut par un NO-GO : la distribution ne sortira pas la semaine prochaine, pour la deuxième fois consécutive. 22 octobre 2026. La liste des bug bloquants acceptés touche à la mitigation eMudhra, à LVM sur des volumes chiffrés LUKS, et à KDE Plasma Discover qui installe des paquets périmés du dépôt Fedora 44. 22 octobre 2026. La nouvelle date cible est fixée au 3 novembre. Pourquoi c’est important : un retard de release n’est pas un échec — c’est le processus de qualité qui fonctionne, et la liste des blocages dit précisément ce qui aurait cassé des machines en production.
Deux reports, une mécanique de release qui tient
Fedora suit un calendrier de sortie strict, rythmé par des réunions Go/No-Go où les mainteneurs décident collectivement si la distribution est prête. La sortie de Fedora 45 visait idéalement cette semaine, mais elle a déjà manqué sa fenêtre faute de build candidat à temps pour la réunion précédente. Le 22 octobre, la réunion tranche à nouveau : NO-GO, avec un report d’au moins une semaine.
Ce n’est pas un signe de dysfonctionnement. C’est exactement l’inverse : le processus Go/No-Go existe pour empêcher qu’une distribution sorte avec des régressions connues. Le fait qu’un report soit déclaré — plutôt qu’ignoré ou contourné — est la preuve que la mécanique fonctionne. Les distributions qui sortent « quoi qu’il arrive » déplacent le coût de la qualité vers leurs utilisateurs ; Fedora assume de le garder en amont.
La lecture utile pour un administrateur est moins « Fedora 45 est en retard » que « voici la liste des bugs qu’on a refusé de vous livrer ». Chaque blocage accepté est une panne évitée chez des milliers d’utilisateurs.
Quatre blocages acceptés, quatre pannes évitées
La liste des bloqueurs acceptés pour Fedora 45 se lit comme un inventaire des régressions les plus coûteuses possibles. Le premier est une mise à jour nécessaire pour atténuer les problèmes eMudhra — la suite directe de l’affaire des certificats intermédiaires devinables qui a forcé eMudhra à quitter le marché des certificats TLS en octobre. Concrètement, la distribution doit embarquer la correction qui retire ou remplace les racines compromises avant de se présenter devant ses utilisateurs.
Le deuxième blocage est plus terre-à-terre : l’image Fedora Server 45 AArch64 dépasse sa taille maximale. Une image trop lourde ne se grave pas sur les supports prévus et casse les déploiements automatisés — un bug banal en apparence, mais bloquant quand il touche une plateforme entière.
Le troisième est le plus dangereux : l’auto-activation de LVM échoue après une mise à niveau vers Fedora 45 sur une configuration où le volume physique repose sur un LUKS. Traduit : un utilisateur qui met à niveau une machine chiffrée peut se retrouver avec un système qui ne monte plus ses volumes — un scénario de perte d’accès aux données qui justifie à lui seul un report. Le quatrième concerne KDE Plasma Discover, qui installe des paquets RPM natifs périmés depuis le dépôt Fedora 44 : une régression de mise à jour qui livrerait des versions obsolètes aux utilisateurs KDE.
Trois blocages proposés encore en discussion
La liste n’est pas close. Trois bloqueurs proposés restent en cours d’examen, et tous trois pointent vers les mêmes zones sensibles. Le premier : aucune interface réseau n’est configurée via le paramètre noyau ip= pendant l’installation — une régression qui casse les déploiements headless automatisés. Le deuxième : un pool chiffré Stratis ne démarre pas. Le troisième : une racine Stratis chiffrée retombe en mode de secours après une invite de phrase de passe restée sans réponse.
La récurrence des sujets est instructive. LUKS, Stratis, le chiffrement au démarrage : les blocages se concentrent sur le chemin de démarrage chiffré, c’est-à-dire la partie du système où un bug ne se corrige pas par une simple mise à jour de paquet — il faut redémarrer, parfois depuis un média de secours. C’est précisément la catégorie de bugs qu’un Go/No-Go est censé attraper, car leur coût post-sortie est démesuré.
Ce que Fedora 45 était censé apporter
Le report a un coût concret : Fedora 45 devait embarquer des nouveautés déjà livrées en bêta. La version bêta publiée en amont introduisait GNOME 51, une console KMSCON et divers ajustements, ainsi qu’une expérience plus fluide sur les portables Snapdragon X1. Autrement dit, ce qui attend derrière le Go/No-Go n’est pas un simple numéro de version, mais une vraie mise à jour de l’environnement de bureau et du support matériel ARM.
Le décalage ne rend pas ces fonctionnalités caduques, il les retarde pour tout le monde. C’est la nature d’un calendrier de release monolithique : un bug bloquant dans LVM ou Stratis gèle l’ensemble des nouveautés, y compris celles qui sont prêtes depuis des semaines. Les utilisateurs qui attendaient GNOME 51 devront patienter jusqu’au 3 novembre — au mieux.
Cette mécanique explique aussi pourquoi certains écosystèmes explorent des modèles de livraison plus granulaires. Tant que Fedora publie en versions semestrielles, la discipline du Go/No-Go reste le seul rempart entre une nouveauté attractive et une régression destructrice. Le choix de Fedora est clair : mieux vaut décaler GNOME 51 de dix jours que de livrer une distribution qui ne remonte plus ses volumes chiffrés.
Ce que le report dit de l’état de l’écosystème
Le blocage eMudhra mérite une attention particulière. Il relie Fedora 45 à un événement de sécurité qui a secoué toute la chaîne TLS : des clés intermédiaires devinables chez un fournisseur de certificats ont forcé l’écosystème à retirer des racines de confiance. Qu’une distribution doive retarder sa sortie pour embarquer cette mitigation montre à quel point la gestion des certificats racine est devenue un enjeu de calendrier de release — et pas seulement un sujet de navigateurs.
Les autres blocages racontent une histoire plus prosaïque mais tout aussi importante : la fragmentation des chemins de stockage (LVM, LUKS, Stratis, Btrfs) multiplie les combinaisons à tester, et les régressions se nichent dans les intersections — ici, LVM sur LUKS, là Stratis chiffré. Plus une distribution supporte de combinaisons, plus sa phase de test est longue, et plus les reports de ce type deviennent structurels.
Verdict
Si vous attendiez Fedora 45, ne planifiez aucune migration cette semaine : la cible est le 3 novembre, et elle reste conditionnée à la résolution des blocages d’ici jeudi prochain. Si vous êtes sur Fedora 44, rien ne presse : restez sur la version stable, appliquez les mises à jour de sécurité, et ne forcez pas un passage anticipé vers une release dont les bugs de chiffrement au démarrage ne sont pas encore clos. Si vous testez des configurations chiffrées — LVM sur LUKS, Stratis — c’est le moment de participer aux tests de validation, car ce sont précisément les chemins qui retiennent aujourd’hui la sortie. Le second NO-GO de Fedora 45 n’est pas une mauvaise nouvelle : c’est la preuve qu’une distribution peut encore choisir la qualité plutôt que la date.