Fedora 45 Beta ist da: Was sich für Umsteiger ändert, und warum mein Rechner noch auf 44 bleibt

Fedora 45 gibt es seit gestern als Beta, und mein Hauptrechner läuft seit Anfang August auf Fedora 44. Der Reflex, sofort zu aktualisieren, sitzt tief, ich habe im Sommer drei Distributionen in einem Monat installiert. Diesmal bleibt er aus, aus einem einfachen Grund: Die Beta ist kein Kandidat für die Maschine, auf der ich arbeite, und das Final kommt laut Plan am 20. Oktober.

Trotzdem habe ich die Änderungsliste gelesen, wie man den Beipackzettel eines Medikaments liest, das man in vier Wochen nehmen wird. Drei Einträge betreffen genau das Setup, das ich in den letzten Wochen hier beschrieben habe.

Kein Beta-Test auf meinem Rechner. Dieser Text stützt sich auf die Ankündigung im Fedora Magazine, die offiziellen Change-Seiten im Fedora-Wiki und die Diskussionsfäden dazu. Was davon in der Praxis hakt, weiß ich erst nach dem Upgrade auf das Final.

Fedora 45 Beta läuft seit gestern, mein Hauptrechner bleibt auf 44

Die Beta kam am 15. September, pünktlich laut Fedora Magazine, als ISO für Workstation, KDE und die Atomic-Varianten oder per dnf system-upgrade auf einem bestehenden System. Das Final ist für den 20. Oktober geplant, mit dem 27. Oktober als Ausweichtermin, falls die Release-Kriterien nicht rechtzeitig erfüllt sind. Fedora verschiebt gern um eine Woche, das gehört dazu.

Warum ich nicht sofort umsteige, hat mit einer Regel zu tun, die ich mir im Sommer selbst aufgeschrieben habe. Nach dem Distro-Hopping war die ehrliche Bilanz, dass jeder Wechsel mehr Zeit gefressen hat als das Problem, das er lösen sollte. Also: eine langweilige, stabile Version nehmen und bleiben, auch wenn etwas klemmt. Eine Beta auf dem Arbeitsrechner ist das Gegenteil davon, egal wie gut sie läuft.

Was ich stattdessen mache: die Änderungen gegen mein eigenes Setup lesen. Das ist ein Rechner mit RTX 4070 Ti Super, NVIDIA-Treiber aus RPM Fusion, aktivem Secure Boot mit eigenem Signatur-Schlüssel und Windows 11 auf der zweiten NVMe. Drei der Fedora-45-Änderungen treffen genau diese Stellen.

Paketsignaturen werden Pflicht: die Frage, die ich vor dem Upgrade beantwortet haben will

Bisher hat RPM Signaturen geprüft, wenn welche da waren, aber nie welche verlangt. Ab Fedora 45 gilt laut Change-Seite die Regel aus RPM 6: Ein Paket ohne gültige Signatur wird nicht installiert, es sei denn, man setzt ausdrücklich --nosignature. Eine Paketsignatur ist der kryptografische Nachweis, dass ein Installationspaket von dem stammt, der es zu sein behauptet, und unterwegs nicht verändert wurde. Für alles aus den offiziellen Fedora-Quellen und aus RPM Fusion ändert sich laut Fedora nichts, die Pakete dort sind längst signiert.

Mein Sonderfall ist der NVIDIA-Treiber. Der kommt als akmod, also als Paket, das den eigentlichen Treiber bei jedem Kernel-Update lokal auf meinem Rechner neu baut und das Ergebnis wieder als Paket installiert. Diese lokal gebauten Pakete signiert niemand außer meinem eigenen Rechner. Die Signatur, um die ich mich im NVIDIA-Artikel gekümmert habe, ist eine andere: Sie gilt für das Kernel-Modul und für Secure Boot, nicht für das RPM-Paket drumherum.

Auf der Change-Seite stehen die Bausysteme, die angepasst wurden: mock, koji, COPR. akmods steht da nicht. Ich lese das nicht als Alarm, denn die Regel ist seit Februar in Rawhide aktiv, und ein akmod-nvidia, das seit sieben Monaten auf keinem Entwickler-System mehr installiert, wäre aufgefallen.

Fedora nennt außerdem den Notausgang gleich mit: eine Zeile in /etc/rpm/macros.verify stellt das alte Verhalten wieder her. Trotzdem ist das die eine Frage, die ich vor dem Upgrade in einem Forum beantwortet sehen will, nicht danach an meinem eigenen Bildschirm.

DNF tauscht keine Anbieter mehr: RPM-Fusion-Nutzer bekommen einen neuen Fehlertext

Die zweite Änderung ist unscheinbarer und wird vermutlich mehr Leute treffen. Bisher durfte DNF ein installiertes Paket bei einem Update still durch ein gleichnamiges Paket eines anderen Anbieters ersetzen, etwa ein Fedora-Paket durch die Variante aus RPM Fusion. Ab Fedora 45 ist das per Voreinstellung aus, Fedora nennt RPM Fusion als Beispiel: Steht so ein Tausch an, bricht DNF die Transaktion ab und sagt, welches Paket den Anbieter wechseln wollte.

Für Umsteiger, die nach der Anleitung Codecs aus RPM Fusion nachinstalliert haben, heißt das: Irgendwann in den nächsten Monaten taucht ein Fehlertext auf, den es vorher nicht gab. Gewollt ist er, der Tausch passiert dann mit --from-vendor= und dem Namen des Anbieters, oder man schaltet die Sperre in einer Konfigurationsdatei wieder ab.

Ich finde die Änderung richtig, weil sie genau die stillen Paketwechsel verhindert, nach denen man abends eine Stunde sucht. Aber sie gehört auf die Liste der Dinge, die man einmal gesehen haben muss, um nicht zu erschrecken.

oo7 löst GNOME Keyring ab, und kmscon die Konsole, die du nur im Notfall siehst

Die dritte Änderung sitzt an der Stelle, an der es weh tut, wenn sie schiefgeht: beim Passwortspeicher. GNOME Keyring ist der Tresor, in dem der Desktop WLAN-Passwörter und Browser-Logins ablegt und beim Anmelden entsperrt. Fedora 45 ersetzt ihn auf allen Desktops durch oo7, das dasselbe für GNOME und KDE erledigt und zusätzlich FIDO2-Schlüssel versteht. Vorhandene Daten sollen laut Change-Seite automatisch migrieren, ohne Zutun.

Zwei Dinge beruhigen mich dabei. Ein funktionierender Schlüsselbund steht in den Release-Kriterien für das Final, ohne ihn darf Fedora 45 nicht erscheinen. Und einer der Entwickler schreibt im Diskussionsfaden, dass oo7 in den Nachtbauten von GNOME OS schon Standard ist und die bekannten Fehler dort vorher rausgeflogen sind. Was ich trotzdem vor dem Upgrade mache: die WLAN-Passwörter und den Passwort-Manager-Zugang einmal irgendwo notieren, wo kein Schlüsselbund dazwischen sitzt.

Die vierte Änderung merkst du im Normalbetrieb nie. kmscon ersetzt laut Fedora die alte Kernel-Konsole fbcon auf den Text-Terminals, also auf den Bildschirmen, die man mit Strg, Alt und F3 erreicht, wenn der Desktop nicht startet. Genau dort landet man nach einem schiefgegangenen Treiber-Update, deshalb ist mir das nicht egal.

Die Konsole soll Schriften und Unicode sauber darstellen und wieder scrollen können, was fbcon vor Jahren aus Sicherheitsgründen verloren hat. Startet kmscon nicht, fällt das System auf fbcon zurück, das weiter im Kernel steckt.

Mein Upgrade-Plan bis zum Final: zwei Befehle vorher, ein Backup dazwischen

Ich werde in der Woche nach dem 20. Oktober aktualisieren, nicht am Tag selbst. Vorher will ich wissen, wie mein NVIDIA-Paket heute aussieht, damit ich nach dem Upgrade einen Vergleich habe. Dafür reichen zwei Zeilen im Terminal:

rpm -q --qf '%{NAME} %{SIGPGP:pgpsig}\n' kmod-nvidia-$(uname -r)
modinfo -F signer nvidia

Die erste Zeile zeigt, ob das lokal gebaute Treiberpaket eine Paketsignatur trägt, bei mir erwarte ich ein (none). Die zweite zeigt den Aussteller der Modul-Signatur, das muss mein eigener Schlüsselname sein, sonst stimmt schon vor dem Upgrade etwas nicht. Dazwischen kommt ein Backup des Home-Verzeichnisses auf die Windows-Platte, die ich beim Umstieg ohnehin behalten habe, genau für solche Tage.

Wer die Beta ausprobieren will, sollte das auf einem zweiten Rechner oder in einer virtuellen Maschine tun. Fedora selbst nennt die Beta ausdrücklich Vorabversion, und die Signatur- und Keyring-Änderungen sind genau die Sorte, die im Fehlerfall den Login kostet.

Termin, Upgrade, NVIDIA: die kurzen Antworten

Ein Release für Leute, die schon umgestiegen sind

Fedora 45 ist kein Release, das jemanden zum Umstieg bewegt, es hat kein Feature, das man auf einen Screenshot packen kann. Es ist ein Release für Leute, die schon da sind und deren Setup älter als ein halbes Jahr ist: Signaturpflicht und Anbieter-Sperre räumen Dinge auf, die man als Einsteiger nicht sieht und als Umsteiger irgendwann verflucht. Deshalb finde ich es gut, und deshalb warte ich trotzdem bis nach dem 20. Oktober.

Wer heute frisch umsteigt, installiert Fedora 44 und aktualisiert später, das ist der bequemere Weg als eine Beta-Installation. Und wer wie ich mit RPM Fusion und NVIDIA unterwegs ist, notiert sich die zwei Befehle von oben. Nicht weil etwas kaputtgehen wird, sondern weil man hinterher wissen will, was vorher galt.