Das Symptom
Du willst nur schnell sudo dnf upgrade laufen lassen, doch statt einer
Paketliste kommt: Failed to download metadata for repository '...'. dnf
verweigert die Arbeit, obwohl an deinem System eigentlich alles unverändert ist.
Die „Layer 8“-Wahrheit
Fedora zieht seine Pakete nicht von einem einzelnen Server, sondern aus einem
weltweiten Netz aus Spiegeln. dnf fragt zuerst nach einer Liste passender
Spiegel und lädt die Metadaten von dort. Ein einzelner halb aktualisierter oder
überlasteter Spiegel legt das normalerweise nicht lahm, denn ein gewöhnlicher Lauf
probiert weitere Spiegel der Liste; nur der sparsame Hintergrundlauf
makecache --timer gibt laut Handbuch nach dem ersten Fehlschlag auf. Kommt die
Meldung trotzdem, war für dieses Repository keine brauchbare Quelle zu erreichen.
Das ist selten ein Defekt deines Rechners – ein dnf clean all gefolgt von
makecache holt die Metadaten komplett neu, und hat nur kurz etwas gehakt, ist der
Fehler weg. Bleibt er, wird die Ursache banaler statt exotischer: kein DNS, ein
Captive-Portal-WLAN, das noch
auf deinen Login wartet, oder ein einziges kaputtes Fremd-Repository, das du
irgendwann mal hinzugefügt hast und das die ganze Kette blockiert. Der Fehler
sagt selten „Fedora ist kaputt“, sondern fast immer „der Weg dorthin ist gerade
versperrt“.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.Den Cache leeren und neu aufbauen
Der schnellste erste Versuch: dnf den alten, halb heruntergeladenen Cache wegwerfen lassen und die Metadaten frisch holen. Hat ein Repository nur kurz gehakt, läuft der neue Durchgang durch.
sudo dnf clean all
sudo dnf makecache
2.Prüfen, welches Repository klemmt
Die Fehlermeldung nennt den Repo-Namen in Anführungszeichen. Lass dir alle aktivierten Repositories anzeigen und finde heraus, ob es ein Fedora-Standardrepo oder ein selbst hinzugefügtes Fremd-Repo ist:
dnf repolist --enabled
3.Die Netzverbindung testen
Bevor du an den Repos schraubst: Ist überhaupt ein Weg nach draußen frei? Der erste Befehl prüft Namensauflösung und Erreichbarkeit, der zweite tatsächlich HTTPS – und nur der zweite entlarvt ein Captive-Portal-WLAN oder einen Proxy, denn ein Ping kann dort durchaus gelingen, während jede HTTPS-Verbindung umgebogen wird. Antwortet das nicht sauber, ist nicht dnf schuld, sondern das Netzwerk.
ping -c3 fedoraproject.org
curl -I https://mirrors.fedoraproject.org
4.Ein defektes Fremd-Repository vorübergehend deaktivieren
Stammt der Fehler von einem Zusatz-Repository mit toter URL, kannst du es für den Moment aussparen, um zumindest mit den Fedora-Quellen weiterzuarbeiten. Ersetze <repo-id> durch die ID aus der Fehlermeldung:
sudo dnf --disablerepo=<repo-id> upgrade
5.Uhrzeit prüfen, wenn HTTPS scheitert
Geht die Systemuhr grob falsch, lehnt der Server das TLS-Zertifikat ab und der Metadaten-Download bricht ab. Stelle sicher, dass die Zeit automatisch synchronisiert wird:
timedatectl status