Fedora schickt RPM, OpenSSL und Bootmedien vor Version 45 auf den Prüfstand

Testtage ersetzen den stillen Automatik-Verlass

Fedora bittet vor Version 45 offen um Mithilfe: Mehrere Systemänderungen laufen erst dann rund, wenn echte Hardware und echte Nutzer sie durchprobiert haben. Details dazu bündelt der Testtage-Beitrag im Fedora Magazine, der für jede größere Änderung einen eigenen Termin ansetzt statt einer diffusen Bitte um Feedback irgendwann vor dem Release.

Automatisierte Tests fangen bekannte Regressionen zuverlässig ab. Sie sagen aber nichts darüber, ob das neue boot.iso auf einem bestimmten Laptop überhaupt startet, oder ob erzwungene RPM-Signaturprüfung einen Workflow zerschießt, an den im Entwicklerteam niemand gedacht hat. Genau deshalb braucht Fedora Rückmeldungen von Leuten, die reale Maschinen und reale Szenarien durchspielen, nicht nur CI-Läufe.

Diese Aufmerksamkeit für Details passt zu weiteren Paketentscheidungen bei Fedora, wo einzelne Komponenten ebenfalls erst nach genauer Prüfung aus dem Repository verschwinden oder bleiben. Test Days sind kein neues Format: Ein enger Kalender bündelt einzelne Tage auf jeweils eine Änderung, Entwickler stehen zeitgleich auf Matrix zur Fehlersuche bereit. Man muss dafür kein QA-Experte sein.

Wer schon einmal eine Beta-Version installiert hat, kennt das Prinzip. Neu ist hier die Bündelung: Statt vereinzelter Bugreports über Monate verteilt, sammelt Fedora die kritischen Änderungen in klar terminierten Fenstern und bittet dort gezielt um Ergebnisse, bevor die Version fertig geschnürt wird.

GNOME 51 eröffnet den Testreigen ab dem 17. August

Los geht es mit GNOME 51 Desktop, dem ersten Testtag dieses Zyklus vom 17. bis 21. August. Wer die Ankündigung rechtzeitig liest, kann direkt einsteigen: Desktop, Grafik, Peripherie und Kernanwendungen stehen im Fokus dieses ersten Termins, der zum Zeitpunkt der Veröffentlichung bereits läuft.

Danach folgen im Wochenrhythmus weitere Slots: eine Internationalisierungswoche vom 7. bis 13. September für Eingabemethoden, Gebietsschemata und Tastaturlayouts, dazu eigene Termine für Installationsmedien, für KDE (vermutlich Version 6.7), für Cockpit sowie für GRUB EFI im Kontext von Confidential Computing.

Die Liste ist ausdrücklich nicht final. kmscon, OpenSSL 4.0, CoreOS und Kernel 7.2 stehen laut Fedora Magazine noch zur Diskussion und könnten eigene Termine bekommen. Aktuelle Termine und Ergebnisse finden sich fortlaufend auf testdays.fedoraproject.org; wer nur kurz reinschauen will, sieht dort den kompletten Kalender auf einen Blick.

Diese Terminplanung geht auf ein Quality-Meeting vom 20. Juli zurück, bei dem das Team das ChangeSet durchgegangen ist und jene Änderungen herausgesucht hat, die am meisten von Community-Tests profitieren. Daraus wurde ein Planungsticket auf Forge mit einzelnen Unterpunkten je Ereignis.

RPM und Signaturen im Praxistest

Am gewichtigsten für den Serverbetrieb ist RPM 6.1: Update auf 6.1, erzwungene Signaturprüfung und DNF-Repo-Konfigurationen, die nach /usr wandern. Enforced signature checking heißt im Klartext: Ungesignete Pakete werden künftig härter abgelehnt. Wer eigene Repositories oder gepatchte Pakete betreibt, sollte diesen Punkt vor dem Upgrade testen, nicht erst danach entdecken.

Dazu kommt die Verlagerung der DNF-Repo-Konfigurationen nach /usr, was Skripte und Konfigurationsmanagement betrifft, die bisher fest auf /etc/yum.repos.d gesetzt haben. Wer Ansible-Rollen oder Kickstart-Dateien pflegt, die Repo-Pfade hart codieren, bekommt hier eine Stelle, die vor dem Umstieg geprüft gehört.

Positiv fällt auf: Die NSS-Unterstützung für Nutzer- und Gruppenabfragen ist zurück, Abfragen funktionieren wieder während laufender Transaktionen, es gibt neue Makromodifikatoren für Paketierer und eine bessere rpmkeys-Verifizierungsausgabe. Das klingt nach einem soliden Update. RPM berührt aber praktisch jedes System auf der Maschine, ein Grund mehr, genau hinzusehen, ob nichts durchgerutscht ist.

Fedora selbst spricht von einem Update, das reibungslos wirkt, aber gerade wegen seiner Reichweite eine gründliche Prüfung verdient. Wer Paketbau-Pipelines, Signierprozesse oder automatisierte Installationsskripte betreibt, testet diesen Bereich am besten mit den eigenen echten Artefakten statt mit einem sauberen Vanilla-System.

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellseedream_v4_5; quality=high; 5120x2880PromptEveryday hardware testing represented by blank modular components arranged around a soft diagnostic light beam on a neutral work mat, no ports with labels, no branded sticks, no writing, no letters, no numbers, no labels, no screens, no UI, no industrial factory setting, photorealistic editorial image. A tight documentary composition emphasizes hands-on consequences in a fully text-free scene with blank surfaces and no legible markings. Photorealistic style image. Mood: practical, focused, and investigative. Avoid: watermark, signature, blurry, low quality, distorted, deformed.

OpenSSL 4.0 und neu gebaute Bootmedien

Der zweite große Brocken ist OpenSSL 4.0, ein Major-Versionssprung, der laut Fedora Magazine alles betreffen kann, was TLS spricht. Für Betreiber mit eigenen Zertifikatsketten, speziellen Cipher-Suiten-Einstellungen oder älteren TLS-Bibliotheken im Einsatz ist das kein Randthema, sondern eine Zeile, die vor dem Produktivupdate auf einer Testmaschine laufen sollte.

Boot- und Live-Medien werden komplett neu mit image-builder erzeugt. Das ändert, wie die Images entstehen, weshalb sichergestellt werden muss, dass sie über verschiedene Hardware- und Virtualisierungssetups hinweg weiterhin starten und korrekt installieren.

Wer produktiv auf boot.iso oder Live-Umgebungen setzt, etwa für Rettungssysteme oder Erstinstallationen im Rechenzentrum, testet diesen Teil am besten auf genau der Hardware, auf der später tatsächlich installiert wird. Eine virtuelle Maschine allein deckt die interessanten Firmware- und Treiberfälle selten ab, gerade bei älteren oder exotischen Netzwerkkarten.

Beide Änderungen zusammen genommen, TLS-Bibliothek und Bootpfad, betreffen fast jeden produktiven Fedora-Server irgendwo im Stack. Wer beide isoliert testet, riskiert, eine Wechselwirkung zu übersehen, etwa wenn ein signierter Installer plötzlich gegen eine neue OpenSSL-Version geprüft wird.

Für Administratoren, die UEFI Secure Boot und eigene Zertifikate kombinieren, kommt eine dritte Variable hinzu: Der neue Image-Builder-Pfad muss dieselben Signaturketten sauber durchreichen wie der bisherige Bauprozess. Ein Test allein mit Standard-Secure-Boot verrät nichts über eigene Zertifikatsinfrastrukturen, die in vielen Unternehmensumgebungen längst produktiv laufen.

kmscon, Python 3.15 und der Wechsel der Konsole

Der Standardwechsel von fbcon zu kmscon als Kernel-VT-Konsole betrifft primär, wie das System vor dem Start des Grafikservers auf dem Bildschirm ausgibt. Wer Server ohne Desktop-Umgebung betreibt oder sich auf die Textkonsole verlässt, wenn X oder Wayland streiken, sollte kmscon auf der eigenen Hardware ausprobieren, bevor Fedora 45 zur Produktivversion wird.

Daneben bringt die Version Python 3.15 mit sowie GRUB EFI für Confidential Computing, relevant vor allem für bestimmte Hardware- und VM-Umgebungen mit Attestierungsanforderungen. Beide Änderungen sind für sich genommen unauffällig. Sie summieren sich aber zu einer Liste, die kein einzelner Nutzer allein vollständig abdecken kann, was den Aufruf zu verteilten Tests erst sinnvoll macht.

Für Entwickler, die auf Fedora Workstation arbeiten, dürfte Python 3.15 die spürbarste Änderung im Alltag sein. Virtuelle Umgebungen, gepinnte Abhängigkeiten und ältere C-Extension-Pakete verdienen vor dem Umstieg einen kurzen Testlauf, bevor ein produktives Projekt darauf umzieht.

kmscon ändert vor allem das Verhalten, wenn der Grafikserver noch nicht läuft oder abgestürzt ist, also genau in jenen Momenten, in denen Administratoren ohnehin schon unter Zeitdruck stehen. Ein kurzer Blick auf die Textkonsole nach einem erzwungenen Neustart zeigt schnell, ob Schriftgröße, Tastaturlayout und Sonderzeichen wie gewohnt funktionieren.

Wie Sie sich als Tester registrieren und Ergebnisse melden

Mitmachen erfordert ein Fedora-Konto. Danach folgt der übliche Dreischritt: einen Testtag aus dem Zeitplan wählen, den Wiki-Anweisungen folgen und das Ergebnis über die Test-Day-App melden. Wer etwas Ungewöhnliches findet, spricht die Entwickler direkt im Matrix-Raum #test-day:fedoraproject.org an.

Für alle, die lieber im Terminal bleiben statt eine Weboberfläche zu öffnen, gibt es fedora-easy-karma: ein CLI-Werkzeug, das bereits installierte Testupdates aufgreift und Karma direkt aus dem Terminal an Bodhi übermittelt. Wie die Test-Day-App ist auch dieses Tool Open Source und auf Forge gehostet, Fehlermeldungen und Feature-Wünsche landen dort als Ticket.

Wer selbst eine größere Änderung in einem gepflegten Paket hat, muss nicht auf das QA-Team warten. Ein Ticket unter forge.fedoraproject.org/quality/tickets mit dem Tag test days reicht; fertige Testfälle oder Wiki-Seiten sind zu diesem Zeitpunkt nicht nötig. Passend dazu zeigt die Analyse zu einem Fedora-Remix mit frischem Kernel für Gaming-Systeme, wie unterschiedlich die Hardwarebasis ausfällt, auf der solche Testfälle am Ende laufen müssen.

Testen jenseits fester Testtage ist ebenfalls ausdrücklich erwünscht. Wer eine Testversion ohnehin schon installiert hat, meldet über fedora-easy-karma Rückmeldungen fortlaufend, ohne auf den nächsten Termin zu warten. Für Teams mit mehreren Testmaschinen lohnt sich ein kurzes internes Rotationsschema, damit nicht alle dieselbe Hardware prüfen und andere Kombinationen unentdeckt bleiben.

Was vor dem Upgrade auf Fedora 45 zu klären bleibt

Wer Fedora produktiv einsetzt, sollte die Testtage nicht als Kür behandeln, sondern als letzte günstige Gelegenheit vor dem Rollout. Ein Upgrade-Test in einer Umgebung mit denselben Repository-Strukturen, denselben Signaturschlüsseln und derselben Bootmethode wie im Produktivsystem deckt die meisten der hier genannten Änderungen ab, bevor sie im Live-Betrieb auffallen.

Besonders die Kombination aus erzwungener RPM-Signaturprüfung und eigenen oder gespiegelten Repositories verdient vorab einen Blick in die Signaturkonfiguration. Wer Pakete außerhalb der offiziellen Fedora-Kanäle bezieht, sollte vor dem Umstieg klären, ob diese Quellen bereits korrekt signieren, sonst bricht die Installation an einer Stelle, die vorher nie ein Problem war.

Ein zweiter Blick lohnt sich für alle, die eigene Kickstart-Dateien oder Automatisierungsskripte für Neuinstallationen pflegen. Der Umzug der DNF-Repo-Konfigurationen nach /usr und der neue Bootmedien-Bauprozess können beide unabhängig voneinander bestehende Skripte brechen, selbst wenn jede Änderung für sich harmlos wirkt.

Für gemischte Flotten mit unterschiedlicher Hardware, etwa alten Laptops neben neuen Workstations mit NVMe-Boot, lohnt sich eine kleine Priorisierung: zuerst die Maschine mit der ungewöhnlichsten Firmware testen, danach die üblichen Standardsysteme. Genau solche Randfälle sind es, die in reinen CI-Pipelines gerne durchrutschen, weil dort meist nur ein einziges, gut bekanntes Referenzsystem läuft.

Wer zusätzlich signierte Third-Party-Repositories wie RPM Fusion nutzt, sollte deren Kompatibilität mit der neuen RPM-6.1-Signaturprüfung frühzeitig abklopfen. Ein Repository, das bislang unauffällig funktioniert hat, kann nach dem Wechsel plötzlich Fehlermeldungen werfen, wenn Metadaten oder Schlüssel nicht dem neuen Format entsprechen.

Am Ende bleibt der Aufruf schlicht: reale Hardware, reale Workflows, echte Rückmeldung. Die Testtage laufen über mehrere Wochen bis in den September, genug Zeit, um wenigstens jene Änderungen zu prüfen, die für das eigene System tatsächlich relevant sind, statt erst nach dem Rollout auf ein Problem zu stoßen, das ein einziger Testlauf vorab gezeigt hätte.