Fedora 45 verschiebt sich wegen offener Blocker auf November

Fedora 45 erscheint frühestens am 3. November, ein festes Datum gibt es nicht. Beim Go/No-Go-Treffen am 22. Oktober wurde der Release Candidate 1.2 als NO-GO eingestuft. Das nächste Treffen findet am 29. Oktober um 17:00 UTC statt, das sind 18:00 MEZ.

Betroffen sind alle, die auf das Upgrade warten. Nach Stand der Blockerbugs-Seite vom 23. Oktober sind vier akzeptierte Blocker gelistet, darunter ein Zertifikatsupdate für eMudhra und ein Stratis-Fehler mit verschlüsseltem Pool. Zwei der vier akzeptierten Blocker sind noch nicht als behoben bestätigt: Der Eintrag zu eMudhra/ca-certificates steht auf ON_QA, der zu Stratis (verschlüsselter Pool) auf ASSIGNED.

Warum es schon zwei NO-GO-Entscheidungen gab

Fedora entscheidet über die Freigabe in einem Go/No-Go-Meeting. Dort prüfen Qualitätssicherung, Release Engineering und Entwicklung, ob ein Release Candidate (RC) die Release-Kriterien erfüllt. Ein RC ist ein Build, der als fertige Version erscheinen könnte, wenn kein Blocker mehr offen ist. Ein Blocker ist ein Fehler, der laut Kriterien die Veröffentlichung aufhält.

Die erste NO-GO-Entscheidung war eine Formalie. Laut der Ankündigung auf der Test-Announce-Liste (Nachricht „F45 Final NO-GO“) fiel sie „by default“, weil überhaupt kein Release Candidate vorlag. Das damalige Ziel war der 27. Oktober. Ein RC wurde also nicht abgelehnt, es gab schlicht keinen, über den sich entscheiden ließ.

Anders war es am 22. Oktober. Die Nachricht „F45 Final is NO-GO“ auf derselben Liste hält fest, dass RC-1.2 als NO-GO eingestuft wurde. Das ist die erste inhaltliche Ablehnung eines Release Candidate.

Als neues Ziel nennt die Ankündigung den 3. November, im Fedora-Kalender als zweiter Zieltermin geführt. Das Datum ist ein Planungsziel, keine Zusage. Ob es hält, entscheidet das nächste Go/No-Go am 29. Oktober um 17:00 UTC, also 18:00 MEZ. Das Meeting ist auf der Blockerbugs-Seite zum Final-Meilenstein geführt.

dm-Rechnung zur Zeitachse: Das ursprüngliche Ziel war der 27.10., der neue Zieltermin ist der 3.11. Daraus ergeben sich 27 → 3 über den Monatswechsel, also 7 Tage Verschiebung. Das Go/No-Go-Treffen am Donnerstag, 29.10., liegt 5 Tage vor dem Dienstag, 3.11. Es bleibt also eine knappe Woche, um Korrekturen in einen neuen Release Candidate zu bringen. Die Uhrzeit des Treffens ist 17:00 UTC. Weil in Europa am 25.10. die Sommerzeit endet, entspricht das dann 18:00 MEZ. Vor der Umstellung wären es 19:00 MESZ gewesen. Wer das Treffen verfolgen will, sollte die Zeit deshalb nicht aus früheren Terminen übernehmen.

Auch Phoronix ordnet das Ergebnis unter der Überschrift „Fedora 45 Hits A Second NO-GO: Not Releasing Until November“ als zweites NO-GO ein. Das Fedora-Projekt hat die Entscheidung in der Nachricht „F45 Final is NO-GO“ auf der Test-Announce-Liste bekanntgegeben.

Wer die Vorbereitung der Version verfolgt hat, kennt die Tests vor dem Freeze, etwa die Fedora-45-Testtage. Die jetzt offenen Punkte betreffen andere Bereiche.

dm-Einordnung: Das erste NO-GO beschreibt einen Prozessstand und kein Urteil über die Qualität. Das NO-GO für RC-1.2 am 22.10. betrifft dagegen ein konkretes Bauergebnis, das die Kriterien nicht erfüllte. Für Wartende zählt vor allem, ob der nächste Release Candidate die offenen Blocker enthält.

Welche Blocker Stand 23. Oktober offen sind

Die Blockerbugs-Seite führt für den Final-Meilenstein mit Stand 23. Oktober, 04:00 UTC (06:00 MESZ), vier akzeptierte Blocker. Akzeptiert heißt: Das Gremium hat entschieden, dass der Fehler gegen die Release-Kriterien verstößt und die Veröffentlichung aufhält. Der Bugzilla-Status zeigt, wie weit die Behebung ist.

ASSIGNED bedeutet, dass der Fehler einer Person zugewiesen ist und bearbeitet wird. ON_QA heißt, dass eine Korrektur vorliegt und von der Qualitätssicherung geprüft werden soll. VERIFIED bedeutet, dass die Korrektur bestätigt wurde. dm-Einordnung: Ein geprüfter Eintrag bleibt vermutlich so lange gelistet, bis die Korrektur nachweislich in einem Release Candidate enthalten ist. Ursachen und Details zu den Bugs nennt die Blockerbugs-Seite nicht.

eMudhra und ca-certificates (ON_QA)

Der Blocker betrifft ein Zertifikatsupdate für eMudhra, eine Zertifizierungsstelle. Fedora liefert deren Wurzelzertifikate im Paket ca-certificates mit, dem gemeinsamen Vertrauensspeicher des Systems. Die Korrektur liegt vor und wartet auf die Prüfung durch die Qualitätssicherung.

dm-Einordnung: Ein Fehler im Vertrauensspeicher für Zertifikate mehr als eine Randnotiz. Das Paket ca-certificates legt fest, welchen Zertifizierungsstellen ein System vertraut. Davon hängen TLS-Verbindungen ab, also verschlüsselte Zugriffe auf Websites und Dienste. Auch der Abruf von Paketquellen und damit Updates stützt sich darauf. Ein falscher Eintrag kann je nach Art zu abgelehnten Verbindungen oder zu unerwünschtem Vertrauen führen. Welche Folge hier zutrifft, ist nicht belegt.

LVM und LUKS (VERIFIED)

Dieser Eintrag betrifft verschlüsselte Datenträger. LUKS ist das übliche Verfahren zur Festplattenverschlüsselung unter Linux, LVM die logische Datenträgerverwaltung. Der Status VERIFIED zeigt, dass die Korrektur bestätigt ist.

Plasma Discover (VERIFIED)

Discover ist die Software-Verwaltung des KDE-Desktops Plasma. Auch hier gilt die Korrektur als bestätigt. Welche Funktion im Detail betroffen war, ist nicht belegt; die Statusangabe VERIFIED besagt lediglich, dass die Korrektur geprüft wurde.

Stratis mit verschlüsseltem Pool (ASSIGNED)

Stratis ist eine Speicherverwaltung, die Pools aus Datenträgern bildet und Dateisysteme darin anlegt. Der Fehler betrifft einen verschlüsselten Pool. Der Status ASSIGNED ist der früheste der vier: Der Bug ist zugewiesen, eine geprüfte Korrektur liegt laut Blockerbugs-Seite noch nicht vor. dm-Einordnung: Damit ist das der Punkt mit dem größten Abstand zur Freigabe.

dm-Rechnung: Von den vier akzeptierten Blockern sind zwei VERIFIED (LVM/LUKS und Plasma Discover), einer ON_QA (eMudhra/ca-certificates) und einer ASSIGNED (Stratis). Die Hälfte ist also geprüft, ein Viertel wartet auf Prüfung und ein Viertel auf eine Korrektur. Für das Treffen am 29.10. spricht das aus dm-Sicht dafür, dass vor allem Stratis und ein bestätigter Fix für ca-certificates im Fokus stehen. Ein Datum lässt sich daraus nicht ableiten.

Der AArch64-Blocker auf der Streichliste

Phoronix nannte zusätzlich einen Blocker zur Größe des AArch64-Server-Images. Dieser steht auf der aktuellen Liste nicht mehr. Warum der Eintrag verschwunden ist, ist nicht belegt; denkbar sind eine Lösung, eine Neubewertung oder eine andere Zuordnung. Fehlt der Eintrag, ist das noch kein Beleg dafür, dass das Problem gelöst wurde.

Was noch als Blocker vorgeschlagen ist

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptDeveloper at night reviewing a terminal with abstract test result lines on two monitors, focused expression, dim room lit by screens. Photorealistic editorial magazine photo, 16:9. Absolutely no text, no letters, no numbers, no logos, no brand marks.

Neben den akzeptierten Fehlern gibt es vorgeschlagene. Ein vorgeschlagener Blocker ist noch nicht entschieden. Das Gremium muss erst festlegen, ob er die Kriterien verletzt. Solche Einträge können die Lage ändern, bevor am 29. Oktober erneut abgestimmt wird.

PHP mit zwei CVE-Nummern

Vorgeschlagen ist ein Blocker zu PHP wegen der Sicherheitslücken CVE-2026-109618 und CVE-2026-109619. Dieselbe Angelegenheit ist zugleich als Freeze Exception akzeptiert. Eine Freeze Exception (FE) erlaubt es, trotz des Paketeinfrierens vor dem Release eine Änderung aufzunehmen. Technische Einzelheiten zu den beiden Lücken (CVE-2026-109618 und CVE-2026-109619) bleiben bewusst außen vor; wer PHP betreibt, sollte nach dem Release die aktualisierten Pakete einspielen.

Stratis-Root und Notfallmodus

Als Freeze Exception vorgeschlagen ist außerdem ein Fehler bei verschlüsselter Stratis-Root, der in den Notfallmodus führt. Root bezeichnet hier das Dateisystem, von dem das System startet. Bootet es nicht regulär, landet das System im Notfallmodus. Der Vorschlag ist nicht entschieden. Dass es zwei Stratis-Einträge gibt, einen akzeptierten Blocker und diese vorgeschlagene FE, spricht dafür, dass verschlüsseltes Stratis ein Problemfeld dieser Version ist. Das ist eine dm-Einordnung.

Der Unterschied zwischen Blocker und Freeze Exception ist praktisch wichtig. Ein Blocker hält die gesamte Veröffentlichung auf. Eine FE bringt lediglich eine Korrektur noch in die Version, ohne den Termin automatisch zu verschieben. Ein vorgeschlagener Blocker kann also zum Terminrisiko werden, eine akzeptierte FE nicht von sich aus.

Am 29.10. können vorgeschlagene Einträge akzeptiert oder abgelehnt werden. Wird etwa der PHP-Eintrag als Blocker akzeptiert, käme zu den vier bestehenden ein fünfter hinzu, und der nächste Release Candidate müsste ihn enthalten. Bei einer Ablehnung bliebe er außerhalb der Kriterien für den Termin. dm-Einordnung: Jede Annahme erhöht das Risiko einer weiteren Verschiebung, jede Ablehnung verringert es. Eine Zusage ergibt sich daraus nicht.

Was die Verschiebung für Upgrades bedeutet

Zu den Freeze Exceptions zählen unter anderem die Netzwerkoption ip=, freeipa und gdm. Sie sollen noch aufgenommen werden. Welche Änderungen im Einzelnen dahinterstehen, ist nicht belegt.

dm-Einordnung: Die drei Ausnahmen betreffen verschiedene Gruppen. Die Option ip= konfiguriert das Netzwerk schon beim Start und spielt vor allem bei Servern und Netzboot eine Rolle; wer so installiert, sollte nach dem Release den Start auf einem Testsystem prüfen. Freeipa dient der Identitätsverwaltung in Unternehmensnetzen; dort sollten Administrierende Anmeldung und Domänenbeitritt testen. Gdm ist die grafische Anmeldung; Desktop-Nutzende sollten nach dem Upgrade prüfen, ob der Login-Bildschirm und die Sitzungswahl normal funktionieren.

Für Sie heißt das: Die Version ist noch in Bewegung. Ob der 3. November hält, entscheidet sich am 29. Oktober um 18:00 MEZ. Auch danach ist ein Datum ein Ziel, kein Versprechen.

dm-Einordnung: Produktive Rechner und Server sollten nicht auf Fedora 45 wechseln, solange die Blocker offen sind. Das gilt besonders bei LUKS, LVM oder Stratis, weil Fehler dort den Start des Systems betreffen können. Wer Stratis mit Verschlüsselung nutzt, sollte das Upgrade bis zur Freigabe zurückstellen.

Auch das ist eine dm-Einordnung: Wer Beta- oder Vorabversionen testen will, sollte das nur mit aktuellem Backup und möglichst auf einem Zweitsystem tun. Ein Upgrade auf Ubuntu ist übrigens eine andere Baustelle, zu den Besonderheiten des Ubuntu-26.10-Upgrades gibt es eine eigene Übersicht.

Vor dem Upgrade auf verschlüsselten Systemen empfehlen sich einige Schritte. Prüfen Sie, ob das Backup vollständig ist und sich wiederherstellen lässt. Halten Sie ein Live-Medium bereit, mit dem Sie den verschlüsselten Speicher im Notfall entsperren können. Notieren Sie sich außerdem, wo die Passphrase oder der Wiederherstellungsschlüssel liegt.

Wer wissen will, wann es losgeht, verfolgt die Blockerbugs-Seite und die Test-Announce-Liste. Dort erscheint nach dem Treffen am 29. Oktober die nächste Entscheidung.