„continue os update.“

Es begann, peinlicherweise, mit drei Worten. Ich öffnete eine frische Sitzung und tippte „continue os update“ — in einen Kontext, der keine Erinnerung daran hatte, was ich getan hatte. Was genau fortsetzen?

Also, bevor ich irgendetwas anfasste, Archäologie. dnf history ist ein Tagebuch, von dem du nicht wusstest, dass du es führst:

dnf history list | head

Das Tagebuch sagte: vor ein paar Tagen ein system-upgrade download, heute Morgen ein dnf upgrade --refresh, gleich danach ein kmod-v4l2loopback-Rebuild. Abgeglichen mit rpm -E %fedora und dem laufenden Kernel war das Urteil klar: ich war bereits auf Fedora 43, frisch gebootet. Das große Upgrade hatte stattgefunden. „Fortsetzen“ hieß nicht das Upgrade machen — es hieß danach aufräumen und dann das nächste aufstellen. Lektion null: hinterlässt das frühere Ich eine vage Notiz, lass das gegenwärtige Ich die Logs lesen, bevor es der Notiz glaubt.

Die Reste, die kein Müll waren

Jedes Release-Upgrade hinterlässt Sediment: Pakete, die für ein älteres Fedora gebaut und nie neu gebaut wurden, mit einem veralteten .fc42- oder .fc41-Tag. Der faule Zug ist dnf autoremove und weggehen. Der ehrliche Zug ist, jedes einzelne zu fragen: wer braucht dich noch?

rpm -qa | grep -E '\.fc4[12]\.'

Ein Dutzend Verdächtige. Aber eine Rückwärts-Abhängigkeitsprüfung machte die Hälfte von ihnen aus „Waise“ zu „tragend“:

• webkit2gtk4.0 (fc42) ← wird noch von meinem Remote-Desktop-Client hereingezogen
• javascriptcoregtk4.0 (fc42) ← von jenem webkit benötigt
• vamp-plugin-sdk (fc42) ← von Audacity benötigt, das selbst aktuell ist

„Rest“ ist kein Synonym für „Müll“. Keines davon war sicher herauszureißen; die Apps, die davon abhängen, waren völlig aktuell und nur noch nicht gegen neuere Bibliotheken neu gebaut. (Behalt die webkit-Kette im Auge — sie hat am Ende eine stille Belohnung.) Das einzig wirklich tote Gewicht war ein alter Kernel-Satz, und selbst der würde bei der nächsten Kernel-Installation automatisch beschnitten. Ich entfernte ihn von Hand, rein für das Aufräum-Dopamin.

Die Konfig-Marker und eine übernehmenswerte Direktive

Upgrades streuen .rpmnew- und .rpmsave-Dateien — die Art des Paketmanagers zu sagen „Ich hatte eine Meinung zu dieser Konfig, wollte deine aber nicht überschreiben.“ Zwei waren es wert, gelesen statt reflexhaft gelöscht zu werden:

• cups-browsed.conf: ein Scriptlet nach dem Upgrade hatte still BrowseRemoteProtocols none gesetzt — eine Härtungs-Voreinstellung aus dem cups-browsed-CVE-Nachspiel. Meine alte gespeicherte Kopie hatte das gesprächigere dnssd cups. Ich behielt das abgeriegelte none und löschte den Marker. „Restauriere“ hier nicht hilfsbereit deinen alten Wert.
• chrony.conf: meine eigene NTP-Server-Zeile war intakt, aber die neue Voreinstellung ersetzte eine veraltete Schaltsekunden-Direktive durch eine moderne:

  # old, deprecated
  leapsectz right/UTC
  # new
  leapseclist /usr/share/zoneinfo/leap-seconds.list
  

Sie zu übernehmen schien harmlos. Leser, sie war nicht harmlos.

Der Abstand, der nicht da war

Um die Direktive einzusetzen, griff ich zu sed. Und sed gab mir dies:

leapseclist/usr/share/zoneinfo/leap-seconds.list

Sieh genau hin. Nach leapseclist ist kein Leerzeichen. Eine Ein-Zeichen-Wunde — eine fehlerhafte Direktive, die chrony beim nächsten Parsen rundweg ablehnen würde. Das Schlüsselwort und sein Argument waren zu einem einzigen bedeutungslosen Token verschmolzen.

Ich bemerkte es nur, weil ich früher auf dieser Reise einen Reflex aufgebaut hatte: verifizieren, bevor du den Sieg verkündest. Nicht mit den Augen — Augen gleiten über ein fehlendes Leerzeichen hinweg — sondern mit einem Werkzeug, das Leerraum sichtbar macht:

cat -A /etc/chrony.conf | grep leap
# leapseclist/usr/share/zoneinfo/leap-seconds.list$

cat -A kommentiert nicht. Die fehlende Lücke war direkt da, kein $-verankertes Leerzeichen in Sicht. Ein Leerzeichen ist unsichtbar, bis es zubeißt; cat -A lässt es zuerst zubeißen.

…und die Konfig, die ich „reparierte“, war nie geladen

Dann die zweite Falle, auf die erste gestapelt, als hätte sie gewartet. Selbst wenn meine Bearbeitung sauber gewesen wäre, hätte es nichts geändert — denn das chronyd, das auf meinem System lief, war noch das vom Boot. Sein Log sagte stolz, es „verwende die Zeitzone right/UTC, um Schaltsekundendaten zu beziehen“ — die alte Direktive. Ich hatte eine Änderung „übernommen“, die (a) fehlerhaft und (b) nicht einmal geladen war.

Eine Konfig-Datei zu bearbeiten ändert keinen laufenden Daemon. Offensichtlich, wenn man es ausspricht; unsichtbar im Moment. Der Fix brauchte beide Hälften:

sed -i 's|^leapseclist/usr|leapseclist /usr|' /etc/chrony.conf   # the space
systemctl restart chronyd                                        # the reload

Und erst dann sagte das Log die Wahrheit:

chronyd[34630]: Using leap second list /usr/share/zoneinfo/leap-seconds.list

Ein Neustart ist kein Reload, und eine Datei ist kein Prozess. Prüfe das, was läuft, nicht das, was auf der Platte liegt.

fritz.box ist ein Ort, kein Server

Während chrony schon offen war, stellte ich die Frage, die ich vor Jahren hätte stellen sollen: synchronisiert das Ding überhaupt? Tat es nicht.

chronyc sources
chronyc tracking   # Leap status : Not synchronised

Meine Konfig zeigte auf server fritz.box iburst — meinen Heim-Router. Und fritz.box löst nur auf, wenn ich zu Hause bin. Das ist ein Laptop. Seine Uhr an den Wohnzimmer-Router zu koppeln heißt, dass es überall sonst auf der Welt gar keine Zeitquelle hat. Also gab ich ihm Server, die existieren, egal in welchem Café ich sitze:

pool 2.fedora.pool.ntp.org iburst
sourcedir /run/chrony-dhcp     # still let the home router chime in as a bonus

Eine mobile Maschine sollte nicht von Möbeln abhängen.

Den nächsten Stock wählen, auf dem man steht

Jetzt das eigentliche Upgrade. Erste Frage: 43 → was? Ich traute den Release-Daten aus dem Gedächtnis nicht, also ließ ich das Mirror-Netz abstimmen. Ein Generally-Available-Release hat eine volle Flotte an Mirrors; ein noch Branched eines ist spärlich. Beim Abtasten der Metalinks hatte F44 eine gesunde Mirror-Zahl, und F45 war noch dünn und vorab. 43 → 44 wurde es — entschieden von der Infrastruktur, nicht von meiner Erinnerung an einen Kalender.

Dann der Teil, den alle zu schnell wegklicken — der GPG-Schlüssel-Import:

Importing key 0x6D9F90A6:
 Userid     : "Fedora (44) <fedora-44-primary@fedoraproject.org>"
 Fingerprint: 36F6 12DC F27F 7D1A 48A8 35E4 DBFC F71C 6D9F 90A6

Das ist der Moment, in dem du gebeten wirst, der Signatur eines Fremden auf allem zu vertrauen, was gleich dein OS überschreibt. Also prüfte ich sie, bevor ich y tippte: die Schlüsseldatei gehörte dem offiziellen Paket fedora-gpg-keys, rpm -V sagte, sie sei auf der Platte unverändert, und der Fingerabdruck stimmte Zeichen für Zeichen mit dem Prompt überein. Dreißig Sekunden, um einen Schlüssel nicht blind zu akzeptieren. Es lohnt sich.

Der dnf5-Hinweis

Eine Kleinigkeit machte mich mitten im Upgrade stutzig. Die Statuszeile kam als „Offline-Transaktion testen“ zurück — und genau diese deutsche Formulierung war nicht, wie das dnf sprach, das ich kannte. Es war der Verräter, dass dnf auf dieser Kiste jetzt dnf5 ist, während das alte dnf4 als dnf-3-Binary lauert. Dieses eine Detail erklärte ein früheres Rätsel (warum all die dnf4-State-Verzeichnisse, die ich durchsucht hatte, leer waren — ich hatte die falsche Ära ausgegraben) und beruhigte mich beim Upgrade selbst: in dnf5s system-upgrade scheitern Paketkonflikte zur Resolve-Zeit, bevor eine einzige Datei heruntergeladen wird. Dass es überhaupt staged, war der Beweis, dass meine tragenden Waisen nichts blockiert hatten.

Bereitgestellt, Licht aus

Der Download hinterließ eine geparkte, fertige Offline-Transaktion. Der eigentliche Tausch geschieht in einer minimalen Umgebung nach einem Neustart, mit angehaltenem echten System — kein laufendes Dateisystem, das unter laufenden Programmen umgeschrieben wird. Pre-Flight-Checkliste: am Strom, Arbeit gespeichert, tief durchatmen.

dnf system-upgrade download --releasever=44   # already done, days ago
dnf system-upgrade reboot                      # commit

Dann geht der Bildschirm in diesen kargen Offline-Updater mit Fortschrittsbalken auf Schwarz, sechstausend-und-ein-paar Pakete marschieren vorbei, und die Maschine bootet in ein Fedora, das sie nie zuvor war. Upgrade im Dunkeln, wörtlich.

Ist es sauber gelandet?

Das tat es. Und weil mich diese Serie gelehrt hat, den ruhig wirkenden Teilen nicht zu trauen, nahm ich dem Anmeldebildschirm sein Wort nicht ab. Der Gesundheitscheck, der Reihe nach:

cat /etc/fedora-release      # Fedora release 44 (Forty Four)
systemctl --failed           # 0 loaded units listed
dnf check                    # (silence — no broken deps, no duplicates)

Keine fehlgeschlagenen Dienste. Kein Abhängigkeits-Trümmerfeld. Der neue Kernel (7.0.12-200.fc44) bootete beim ersten Versuch, mit zwei fc43-Kerneln als Rückfallebene.

Es gab einen herzstillstehenden Moment im Upgrade-Log:

systemd ... Failed to start jobs: Invalid argument
systemd ... Remote peer disconnected

Reines Adrenalin — bis ich mich erinnerte, wo das lief. Paket-Scriptlets, die in der Offline-Upgrade-Umgebung feuern, können nicht mit einem System-Manager reden, der noch nicht voll lebendig ist. Diese Fehler sind erwartet und harmlos; der ruhig wirkende Anmeldebildschirm sagte die Wahrheit, und das beängstigend wirkende Log war das unschuldige. Dieselbe Lektion wie die schwarze Arbeitsfläche und die tadellosen Lautstärketasten, diesmal im Sysadmin-Kostüm.

Und die zwei Fragen, die die Notizdatei am dringendsten beantwortet wollte:

• Überlebte chrony den Sprung? Vollständig. Nach dem Upgrade: Leap status: Normal, vier Pool-Server alle mit voller Reichweite, ein Offset unter einer Millisekunde, und das Log liest noch Using leap second list /usr/share/zoneinfo/leap-seconds.list. Die Direktive, für deren fehlendes Leerzeichen ich gekämpft hatte, kam durch das Release-Upgrade unversehrt.
• Brachen die Waisen endlich? Besser als das — einige lösten sich selbst auf. Die ganze fc42-webkit-Kette, um deren Behalt ich gerungen hatte — webkit2gtk4.0, javascriptcoregtk4.0, vamp-plugin-sdk — war schlicht weg, still ersetzt durch fc44-Builds, die die alten Bibliotheken nicht mehr brauchten. Die sorgfältige „nicht entfernen“-Detektivarbeit vom Morgen wurde durch das Upgrade selbst hinfällig. Zwei Nachzügler bleiben bei fc42 (xl2tpd, hfsutils), reine Leaf-Apps ohne fc44-Rebuild — genau die harmlose Sorte Rest, für deren Behalt ich plädiert hatte.

Was ich meinem früheren Ich sagen würde (Upgrade-Edition)

1. Lies die Logs, bevor du der Notiz traust. „Fortsetzen“ bedeutete nichts, bis dnf history mir sagte, was ich tatsächlich schon getan hatte. Das frühere Ich ist ein unzuverlässiger Erzähler; das Transaktions-Log nicht.
2. Verifiziere eine Konfig-Änderung mit cat -A. Leerzeichen sind unsichtbar, bis sie zubeißen. Eine Direktive, die richtig aussieht, und eine, die richtig ist, unterscheiden sich um Zeichen, die deine Augen zu rendern verweigern.
3. Ein Neustart ist kein Reload, und eine Datei ist kein Prozess. Ich hatte eine Konfig „repariert“, die der laufende Daemon nie gelesen hatte. Prüfe immer den lebenden Prozess, nicht nur die Datei auf der Platte.
4. Kopple die Uhr eines mobilen Laptops nicht an dein Wohnzimmer. fritz.box ist ein Ort. Gib einer mobilen Maschine Quellen, die überall existieren, wohin sie geht.
5. Lies GPG-Fingerabdrücke, bevor du ihnen traust. Dreißig Sekunden Prüfen schlagen es, root einer Signatur zu übergeben, die du nie angesehen hast.
6. Wisse, welches dnf du tatsächlich ausführst. dnf4 und dnf5 halten State an verschiedenen Orten und formulieren Dinge anders. Ich verschwendete echte Zeit damit, die Verzeichnisse der falschen Ära zu durchwühlen.