Fedora 45 misses its second Go/No-Go and slips to November 3
On October 22, 2026, Fedora’s Go/No-Go meeting declared a second NO-GO: the distribution will not ship next week, held back by blockers touching the eMudhra mitigation, LVM on LUKS, and KDE Discover. Target November 3 as the new date, and read the blocker list as a lesson in release discipline.
October 22, 2026. Fedora 45’s Go/No-Go meeting ends in a NO-GO: the distribution will not ship next week, for the second time in a row. October 22, 2026. The accepted blocker list touches the eMudhra mitigation, LVM on LUKS-encrypted volumes, and KDE Plasma Discover installing stale packages from the Fedora 44 repository. October 22, 2026. The new target date is November 3. Why it matters: a release slip is not a failure — it is the quality process working, and the blocker list spells out exactly what would have broken machines in production.
Two slips, and a release process that holds
Fedora runs on a strict release schedule, punctuated by Go/No-Go meetings where maintainers collectively decide whether the distribution is ready. Fedora 45 was ideally meant to ship this week, but it already missed its window because there was no candidate build in time for the previous meeting. On October 22, the meeting decided again: NO-GO, with at least another week of delay.
That is not a sign of dysfunction. It is the opposite: the Go/No-Go process exists precisely to keep a distribution from shipping with known regressions. That a slip is declared — rather than ignored or worked around — is proof the machinery works. Distributions that ship “no matter what” push the cost of quality onto their users; Fedora chooses to absorb it upstream.
The useful reading for an administrator is less “Fedora 45 is late” than “here is the list of bugs we refused to ship you.” Every accepted blocker is an outage avoided across thousands of users. It is also a reminder that a release date is a promise of quality first and a calendar event second.
Four accepted blockers, four avoided outages
Fedora 45’s accepted blocker list reads like an inventory of the costliest possible regressions. The first is an update needed to mitigate the eMudhra issues — the direct follow-up to the guessable intermediate keys that forced eMudhra out of the TLS certificate market in October. In practice, the distribution must ship the fix that removes or replaces the compromised roots before it can present itself to users.
The second blocker is more mundane: the Fedora Server 45 AArch64 image exceeds its maximum size. An oversized image does not fit on its intended media and breaks automated deployments — trivial on the surface, but blocking when it hits an entire platform.
The third is the most dangerous: LVM auto-activation fails after upgrading to Fedora 45 when the physical volume sits on LUKS. In plain terms, a user who upgrades an encrypted machine can end up with a system whose volumes no longer mount — a loss-of-data-access scenario that justifies a slip on its own. The fourth concerns KDE Plasma Discover, which installs stale native RPM packages from the Fedora 44 repository: an update regression that would hand outdated versions to KDE users.
Three proposed blockers still under review
The list is not closed. Three proposed blockers remain under review, and all three point at the same sensitive zones. First: no network interface is configured via the ip= kernel parameter during installation — a regression that breaks automated headless deployments. Second: an encrypted Stratis pool fails to boot. Third: an encrypted Stratis root drops to emergency mode after an unanswered passphrase prompt.
The recurrence is instructive. LUKS, Stratis, encrypted boot: the blockers cluster around the encrypted boot path — the part of the system where a bug cannot be fixed by a simple package update, because you have to reboot, sometimes from rescue media. That is exactly the category of bug a Go/No-Go is meant to catch, because its post-release cost is disproportionate.
What Fedora 45 was supposed to ship
The slip has a concrete cost: Fedora 45 was meant to carry improvements already delivered in beta. The beta that shipped earlier introduced GNOME 51, a KMSCON console, and assorted adjustments, along with a smoother experience on Snapdragon X1 laptops. In other words, what sits behind the Go/No-Go is not just a version number but a real update to the desktop environment and to ARM hardware support.
The delay does not void those features — it postpones them for everyone. That is the nature of a monolithic release schedule: one blocking bug in LVM or Stratis freezes the entire feature set, including parts that have been ready for weeks. Users waiting on GNOME 51 will have to hold until November 3, at best.
That dynamic also explains why some ecosystems are exploring more granular delivery models. As long as Fedora ships on a six-month cadence, the Go/No-Go discipline remains the only wall between an attractive new feature and a destructive regression. Fedora’s choice is clear: better to delay GNOME 51 by ten days than to ship a distribution that can no longer mount its encrypted volumes.
What the slip says about the ecosystem
The eMudhra blocker deserves special attention. It ties Fedora 45 to a security event that shook the whole TLS chain: guessable intermediate keys at a certificate provider forced the ecosystem to withdraw trust roots. That a distribution must delay its release to carry this mitigation shows how much root certificate management has become a release-calendar concern — and not just a browser concern.
The other blockers tell a more prosaic but equally important story: the fragmentation of storage paths (LVM, LUKS, Stratis, Btrfs) multiplies the combinations to test, and regressions nest in the intersections — here LVM on LUKS, there encrypted Stratis. The more combinations a distribution supports, the longer its test phase runs, and the more structural slips of this kind become. Each slip is the visible price of that combinatorial surface, and it is rising as new storage layers join the stack.
Verdict
If you were waiting for Fedora 45, schedule no migration this week: the target is November 3, and it remains conditional on the blockers being resolved by next Thursday. If you are on Fedora 44, there is no rush: stay on the stable release, apply security updates, and do not force an early move to a release whose encrypted boot bugs are still open. If you test encrypted configurations — LVM on LUKS, Stratis — this is the moment to join the validation effort, because those are precisely the paths holding up the release today. Fedora 45’s second NO-GO is not bad news: it is proof that a distribution can still choose quality over the date.