apt update/upgrade schlägt fehl nach Debian-Release-Wechsel: Paketkonflikte manuell auflösen

Vor einiger Zeit hing mein eigener Mailserver an genau diesem Punkt: ein Debian-System, das über Jahre nie komplett aktualisiert worden war, sondern irgendwo zwischen Stretch und Bookworm feststeckte – mit einem wilden Mix aus Paketversionen, die eigentlich nie gemeinsam auf einem System existieren sollten. apt weigerte sich, irgendetwas zu tun, dpkg --configure -a brach immer wieder an derselben Stelle ab, und Mails kamen währenddessen nicht mehr zu. Am Ende half kein Standardbefehl mehr – ich musste die betroffenen .deb-Pakete manuell mit Python entpacken, um überhaupt zu verstehen, was der Paketmanager eigentlich installieren wollte und was davon schon in welcher Version auf dem System lag.

Genau dieses Szenario – ein Release-Wechsel, der nicht sauber durchgezogen wurde, und der einen Monate oder Jahre später in Form von kryptischen apt-Fehlern einholt – ist der Klassiker, um den es in diesem Artikel geht.

Du hast in der /etc/apt/sources.list von stretch auf bullseye oder von bullseye auf bookworm umgestellt, apt update lief noch durch – aber bei apt upgrade oder apt full-upgrade bricht alles mit kryptischen Fehlermeldungen ab. Das Problem ist deutlich häufiger, als man denkt, gerade auf länger laufenden Servern, die über mehrere Debian-Generationen „mitgewachsen“ sind, statt sauber neu aufgesetzt zu werden.

Warum das passiert

Ein Debian-Release-Wechsel ist kein einfacher Versions-Bump. Zwischen zwei Debian-Generationen ändern sich:

  • Paketnamen und -aufteilungen – ein Paket wird in zwei aufgeteilt, oder zwei Pakete werden zusammengelegt
  • Abhängigkeitsversionen – ein Paket verlangt jetzt eine libc-Version, die noch nicht installiert ist
  • Config-Dateiformate – dpkg fragt beim Upgrade nach, ob eine geänderte Config-Datei überschrieben werden soll, und bricht bei nicht-interaktiven Läufen (z. B. über SSH mit -y) genau an dieser Stelle ab
  • Reste aus alten Repos – wenn in der sources.list noch Zeilen vom alten Release stehen (typischer Fehler: nur die Haupt-Zeile angepasst, aber -updates oder -security vergessen), mischt apt Pakete aus zwei Generationen

Das Ergebnis sind meist eine von drei Fehlerklassen:

  1. trying to overwrite '/usr/lib/xyz', which is also in package abc
  2. The following packages have unmet dependencies
  3. dpkg: error processing package xyz (--configure): dependency problems - leaving unconfigured

Schritt 1: Bestandsaufnahme statt Panik

Bevor du irgendetwas installierst oder entfernst, verschaff dir einen sauberen Überblick:

apt list --upgradable 2>/dev/null
apt-cache policy | head -20
cat /etc/apt/sources.list /etc/apt/sources.list.d/*.list

Prüfe hier gezielt, ob wirklich alle Zeilen (main, updates, security, evtl. backports) konsistent auf dasselbe Release zeigen. Das ist die häufigste Ursache und in 5 Minuten behoben – bevor du dich in komplexere Fehlerbilder verrennst, die eigentlich nur Symptome dieses einen Fehlers sind.

Schritt 2: dpkg in einen sauberen Zustand bringen

Wenn dpkg mitten in der Konfiguration abbricht, hilft zuerst:

sudo dpkg --configure -a

Das versucht, alle halb-installierten Pakete zu Ende zu konfigurieren. Kommt hier ein Fehler zu einem bestimmten Paket, notiere dir den Paketnamen – das ist dein Einstiegspunkt für die gezielte Fehlersuche.

Schritt 3: apt die Abhängigkeiten selbst reparieren lassen

sudo apt --fix-broken install

Das ist der Befehl, der in den meisten Fällen greift: apt sucht selbstständig nach einer Kombination aus Installieren/Entfernen, die die Abhängigkeitskette wieder konsistent macht. Wichtig: Lies dir vor der Bestätigung die vorgeschlagene Liste an Änderungen durch – manchmal schlägt apt vor, ein Paket zu entfernen, das du eigentlich brauchst, weil es (noch) keine kompatible Version dafür findet.

Schritt 4: Der „trying to overwrite“-Fall

Diese Fehlermeldung bedeutet: Zwei Pakete wollen dieselbe Datei installieren, weil sich die Paketstruktur zwischen den Releases geändert hat (z. B. wurde ein Paket in paket-common und paket-bin aufgeteilt). Die schnelle, aber gefährliche Lösung wäre dpkg -i --force-overwrite. Tu das nicht als ersten Schritt. Prüfe stattdessen zuerst, ob es sich um ein bekanntes Split-Problem handelt:

dpkg -S /pfad/zur/konfliktdatei
apt-cache policy <betroffenes-paket>

Meist reicht es, das ältere, jetzt überflüssige Paket vorher sauber zu entfernen (apt remove <altes-paket>), statt das neue mit Gewalt drüberzuinstallieren. Force-Installationen hinterlassen sonst gerne inkonsistente dpkg-Statusdatenbanken, die dich Wochen später erneut einholen.

Schritt 5: Wenn gar nichts mehr geht – manuelle .deb-Analyse

In hartnäckigen Fällen, in denen apt/dpkg sich gegenseitig blockieren (z. B. bei einem Mix aus zwei nicht mehr unterstützten Zwischenversionen), hilft es, das betroffene Paket manuell zu extrahieren und zu inspizieren, statt dem Paketmanager weiter zu vertrauen:

apt-get download <paketname>
dpkg-deb -R <paketname>*.deb /tmp/paket-inhalt

So siehst du exakt, welche Dateien das Paket mitbringen will, und kannst manuell abgleichen, was davon schon (evtl. unter anderem Namen) auf dem System liegt. Das ist der letzte Rettungsanker, wenn der reguläre Weg über apt --fix-broken install in einer Sackgasse endet – etwa wenn die Paketdatenbank durch einen Mix aus zwei, drei Debian-Generationen so zerrüttet ist, dass apt keinen gültigen Lösungspfad mehr berechnen kann.

Prävention für’s nächste Mal

  • Release-Wechsel immer mit do-release-upgrade (bei Ubuntu) bzw. dem offiziellen Debian-Upgrade-Guide durchführen, nicht durch manuelles Editieren der sources.list mit anschließendem dist-upgrade
  • Vor jedem Upgrade ein Snapshot/Backup des Systems (LVM-Snapshot, VM-Snapshot, oder zumindest dpkg --get-selections > pakete-backup.txt)
  • sources.list nach jedem Wechsel komplett neu schreiben statt zeilenweise zu editieren – das vermeidet die „vergessene -security-Zeile“

Fazit

Die meisten „apt kaputt nach Release-Wechsel“-Fälle sind keine echten Systemschäden, sondern inkonsistente Zwischenzustände, die sich mit dpkg --configure -a gefolgt von apt --fix-broken install in über 80 % der Fälle sauber auflösen lassen. Nur in den hartnäckigen Restfällen lohnt sich der Griff zur manuellen .deb-Analyse – aber dann hast du zumindest volle Kontrolle darüber, was genau auf deinem System passiert, statt mit --force-overwrite zu würfeln.

Bei meinem Mailserver-Fall damals war genau das am Ende der einzige Weg zurück zu einem funktionierenden System: Paket für Paket manuell extrahieren, vergleichen, entscheiden, was bleibt und was weg muss – statt dem Paketmanager blind zu vertrauen, der in diesem zerrütteten Zwischenzustand schlicht keinen gültigen Lösungspfad mehr finden konnte. Die Lehre daraus war weniger technisch als organisatorisch: Ein Release-Wechsel, der „mal eben nebenbei“ gemacht wird, rächt sich fast immer erst Monate später – dann aber richtig.

more posts: