Linux-Server sicher aktualisieren mit apt

Auf einem frischen Server ist ein Upgrade eine Formalität: Es gibt nichts, was kaputtgehen könnte. Sobald der Server Dienste trägt, entscheidet sich an Details, ob ein Upgrade unbemerkt durchläuft oder ob danach eine Konfigurationsdatei überschrieben ist, ein Dienst noch die alte Bibliothek im Speicher hält oder der laufende Kernel ein anderer ist als der auf der Platte. Dieser Artikel geht sie der Reihe nach durch. Die Kurzfassung für ein neu bereitgestelltes System steht in der Checkliste für einen neuen Rootserver.

Alle Angaben beziehen sich auf Debian 13 (trixie), Debian 12 (bookworm), Ubuntu 24.04 LTS und Ubuntu 22.04 LTS. Die Befehle sind für den Betrieb als root geschrieben. Als normaler Benutzer stellen Sie jedem Befehl sudo voran.

Bevor Sie den ersten Befehl absetzen: der Rückweg

Ein Upgrade kann auf drei Arten teuer werden: Eine Konfigurationsabfrage überschreibt die SSH-Konfiguration, ein neuer Kernel startet nicht, oder die Verbindung reißt mitten in einer dpkg-Transaktion ab. Alle drei sind beherrschbar, aber nur, wenn Sie vorher vorsorgen.

Eine Sitzung, die einen Verbindungsabbruch übersteht

Reißt die SSH-Verbindung während des Auspackens ab, bekommt der laufende Prozess ein SIGHUP und dpkg endet mitten in einer Transaktion. Das Ergebnis ist eine halb konfigurierte Paketdatenbank. Führen Sie längere Upgrades deshalb in einer Sitzung aus, die auf dem Server weiterläuft, auch wenn Ihr Terminal verschwindet:

apt install -y tmux
tmux new -s upgrade

Fällt die Verbindung aus, melden Sie sich neu an und holen die Sitzung mit tmux attach -t upgrade zurück. Der Vorgang lief in der Zwischenzeit weiter.

Der Weg auf den Server, wenn SSH nicht mehr antwortet

Bei KVM-Rootservern und Dedicated Servern von KernelHost erreichen Sie die VNC-Konsole im Kundenbereich. Sie hängt nicht am Netzwerkstack des Gastsystems und funktioniert auch dann, wenn kein Dienst mehr lauscht. Melden Sie sich einmal vorher darüber an und vergewissern Sie sich, dass Sie das root-Passwort kennen.

Für den Fall eines Kernels, der nicht startet, brauchen Sie außerdem ein sichtbares Startmenü. Auf Servern ist es häufig ausgeblendet:

grep -E '^GRUB_TIMEOUT|^GRUB_TIMEOUT_STYLE' /etc/default/grub

Stehen dort GRUB_TIMEOUT_STYLE=hidden oder GRUB_TIMEOUT=0, setzen Sie GRUB_TIMEOUT_STYLE=menu und GRUB_TIMEOUT=5 und rufen update-grub auf. Im Notfall wählen Sie in der VNC-Konsole unter "Advanced options" den vorherigen Kernel.

Zustand prüfen und festhalten

Drei Prüfungen vorab, die häufiger etwas finden, als man erwartet:

df -h / /boot /var
dpkg --audit
apt-get check

Erfolgskontrolle: dpkg --audit gibt nichts aus, apt-get check läuft ohne Fehlerzeile durch, und in /boot sind mindestens 300 MB frei. Ein volles /boot ist die häufigste Ursache für ein abgebrochenes Kernel-Upgrade, dazu mehr in Festplatte voll unter Linux. Meldet dpkg --audit etwas, reparieren Sie das zuerst mit dpkg --configure -a.

Danach den Ist-Zustand wegschreiben, damit Sie später vergleichen können:

dpkg --get-selections > /root/pakete-vor-upgrade.txt
apt-mark showhold > /root/holds-vor-upgrade.txt
cp -a /etc/apt /root/apt-config-$(date +%F)

update, upgrade, full-upgrade und dist-upgrade

Diese vier Wörter werden ständig verwechselt. Der Unterschied ist nicht kosmetisch, er entscheidet darüber, ob ein neuer Kernel installiert wird und ob Pakete verschwinden dürfen.

Zwei Punkte folgen daraus. Erstens: dist-upgrade hat nichts mit einem Wechsel auf eine neue Distributionsversion zu tun. Der Name ist historisch, der Befehl bleibt innerhalb Ihrer aktuellen Version.

Zweitens ist der Unterschied zwischen apt upgrade und apt-get upgrade genau der Grund, warum manche Server ohne neuen Kernel dastehen. Debian bindet den Kernel über das Metapaket linux-image-amd64 ein, Ubuntu über linux-image-generic beziehungsweise linux-image-virtual. Bei jedem ABI-Wechsel zeigt dieses Metapaket auf ein neues Paket, dessen Versionsnummer im Namen steht. apt-get upgrade installiert grundsätzlich keine neuen Pakete und lässt den Kernel deshalb liegen, apt upgrade installiert ihn, weil eine Abhängigkeit es verlangt. Wer apt-get upgrade in einem Wartungsskript verwendet, braucht dort zusätzlich --with-new-pkgs.

Zur Werkzeugwahl: Aus einem Skript heraus schreibt apt die Zeile WARNING: apt does not have a stable CLI interface. Use with caution in scripts. Das ist keine Fehlermeldung, aber ein berechtigter Hinweis. In Skripten und Ansible-Rollen gehört apt-get, interaktiv ist apt bequemer.

Der Ablauf mit Prüfung nach jedem Schritt

Schritt 1: Paketlisten holen.

apt update

Erfolgskontrolle: Die Ausgabe enthält keine Zeile, die mit Err: oder W: beginnt. Am Ende steht entweder All packages are up to date. oder eine Zahl gefolgt von packages can be upgraded. Jede Fehlerzeile hier bedeutet, dass Sie mit einem unvollständigen Bild weiterarbeiten würden.

Schritt 2: Ansehen, was kommen würde. Dieser Schritt fehlt in den meisten Anleitungen und ist der wichtigste des ganzen Ablaufs.

apt list --upgradable
apt full-upgrade -s

Der Schalter -s simuliert und verändert nichts. Zeilen unter The following packages will be REMOVED: sind die einzigen, die Sie wirklich prüfen müssen. Steht dort nichts, ist full-upgrade genauso harmlos wie upgrade. Steht dort ein Paket, das Sie brauchen, nehmen Sie apt upgrade und klären die Ursache getrennt.

Auf Debian lohnt sich zusätzlich apt install apt-listchanges. Das Paket zeigt vor dem Einspielen die Changelogs und, wichtiger, die NEWS-Dateien der Paketbetreuer. Dort steht genau das, was Handarbeit erfordert.

Schritt 3: Einspielen.

apt upgrade

Bleiben Sie dabei. Der Vorgang stellt Rückfragen, und ein -y beantwortet nur die apt-eigene Rückfrage, nicht die Abfragen zu Konfigurationsdateien. Die kommen von dpkg und warten geduldig, bis jemand antwortet.

Erfolgskontrolle:

apt list --upgradable
dpkg --audit
systemctl --failed
journalctl -p 3 -b --no-pager | tail -n 20

Erwartet wird: apt list --upgradable gibt außer Listing... nichts aus, dpkg --audit schweigt, systemctl --failed meldet 0 loaded units listed. Was tatsächlich passiert ist, steht dauerhaft in /var/log/apt/history.log, die vollständige dpkg-Ausgabe in /var/log/apt/term.log.

Zurückgehaltene Pakete: zwei verschiedene Ursachen

Wenn apt Pakete auslässt, gibt es dafür zwei grundverschiedene Gründe, die regelmäßig verwechselt werden.

Erstens eine echte Sperre. Jemand hat das Paket ausdrücklich festgenagelt:

apt-mark showhold

Gibt der Befehl etwas aus, war das eine bewusste Entscheidung, meist bei Datenbanken oder Kernel-Modulen. Aufheben mit apt-mark unhold PAKETNAME, setzen mit apt-mark hold PAKETNAME. Eine Sperre auf dpkg-Ebene sehen Sie mit dpkg --get-selections | grep -w hold.

Zweitens die Meldung The following packages have been kept back:. Das ist keine Sperre. Sie bedeutet: apt müsste für dieses Upgrade ein Paket zusätzlich installieren oder eines entfernen, und der verwendete Befehl darf das nicht. Der Nachweis in einer Zeile, ohne etwas zu verändern:

apt full-upgrade -s | head -n 20

Taucht das Paket dort auf, ist die Erklärung gefunden und apt full-upgrade löst es auf. Auf Debian 13 formatiert die neuere apt-Generation diese Ausgabe anders, inhaltlich ändert sich nichts.

Der Sonderfall Ubuntu. Ubuntu liefert Aktualisierungen gestaffelt aus, nicht alle Server bekommen sie am selben Tag. Ein Paket kann also zurückgehalten werden, obwohl weder eine Sperre besteht noch eine Abhängigkeit im Weg ist. Die Diagnose läuft über Ausschluss: apt-mark showhold ist leer, apt full-upgrade -s zeigt keine Entfernung, und apt-cache policy PAKETNAME nennt trotzdem einen neueren Kandidaten. Dann warten Sie ein paar Tage, oder Sie holen die Aktualisierung vorzeitig:

apt -o APT::Get::Always-Include-Phased-Updates=true upgrade

Auf Debian 13 und Debian 12 gibt es die gestaffelte Auslieferung nicht, dort entfällt diese Ursache von vornherein.

Wenn apt nach einer Konfigurationsdatei fragt

Diese Abfrage erscheint nur, wenn zwei Bedingungen gleichzeitig zutreffen: Die Datei wurde seit der Installation lokal geändert, und das Paket bringt eine neue Fassung mit. Sie sieht so aus:

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** sshd_config (Y/I/N/O/D/Z) [default=N] ?

Die Voreinstellung ist N, also Ihre Fassung behalten. Das ist die sichere, aber nicht in jedem Fall die richtige Antwort.

Bei /etc/ssh/sshd_config ist besondere Vorsicht angebracht: Ein Y kann PermitRootLogin und PasswordAuthentication auf die Paketvorgabe zurücksetzen, und genau daran hängt Ihr Zugang. Deshalb gehören eigene SSH-Einstellungen in eine eigene Datei unter /etc/ssh/sshd_config.d/, wie in SSH absichern und Key-Login einrichten beschrieben. Eine Datei, die es im Paket gar nicht gibt, löst nie eine Abfrage aus.

Egal wie Sie antworten, dpkg wirft nichts weg. Bei N landet die neue Fassung als .dpkg-dist daneben, bei Y Ihre alte als .dpkg-old. Diese Dateien durchzusehen ist die eigentliche Nacharbeit:

find /etc -name '*.dpkg-dist' -o -name '*.dpkg-old' -o -name '*.dpkg-new' -o -name '*.ucf-dist'
diff -u /etc/ssh/sshd_config /etc/ssh/sshd_config.dpkg-dist

Für unbeaufsichtigte Läufe, etwa in einem Wartungsskript, legen Sie das Verhalten vorher fest. Diese Kombination behält Ihre Fassung und fragt nicht nach:

DEBIAN_FRONTEND=noninteractive apt-get -y \
  -o Dpkg::Options::="--force-confdef" \
  -o Dpkg::Options::="--force-confold" \
  upgrade

--force-confnew wäre das Gegenteil und nimmt immer die Paketfassung. Auf einem Server mit eigener Konfiguration ist das selten das, was Sie wollen.

Kernel-Updates und die Frage nach dem Neustart

Ein neuer Kernel landet bei der Installation in /boot und im Startmenü. Der laufende Kernel bleibt bis zum Neustart unverändert im Speicher. Ein Server kann also gleichzeitig auf dem neuesten Stand und verwundbar sein. Der einfachste Nachweis ist ein Vergleich:

uname -r
ls -1 /boot/vmlinuz-*

Steht in /boot eine höhere Version, als uname -r meldet, ist ein Neustart fällig. Auf Ubuntu 24.04 und 22.04 gibt es zusätzlich eine Markierungsdatei, die auch Bibliotheks-Updates berücksichtigt:

test -f /var/run/reboot-required && cat /var/run/reboot-required.pkgs

Die zweite Datei nennt die Pakete, die den Neustart angefordert haben. Auf Debian 13 und Debian 12 wird diese Markierung nicht zuverlässig angelegt, dort ist needrestart der richtige Weg.

needrestart: welche Dienste noch die alte Bibliothek benutzen

Ein Update von OpenSSL oder glibc tauscht die Datei auf der Platte aus. Jeder Prozess, der sie bereits geladen hat, arbeitet mit der alten Fassung weiter. needrestart findet genau diese Prozesse. Auf Ubuntu 24.04 und 22.04 ist es vorinstalliert und meldet sich nach jedem Upgrade mit einer Vollbildabfrage, auf Debian installieren Sie es nach:

apt install -y needrestart
needrestart -b

Die Betriebsart -b liefert eine maschinenlesbare Ausgabe. Zwei Angaben daraus sind entscheidend: NEEDRESTART-KSTA mit dem Wert 1 bedeutet, dass der laufende Kernel der erwartete ist, jeder andere Wert bedeutet, dass ein neuerer bereitliegt. Jede Zeile NEEDRESTART-SVC nennt einen Dienst, der neu gestartet werden sollte.

Das Verhalten steuern Sie über die Umgebungsvariable NEEDRESTART_MODE: a startet Dienste automatisch neu, l listet nur auf, i fragt nach. Dauerhaft steht dasselbe in /etc/needrestart/needrestart.conf. Für Skripte ist die Variable die bessere Wahl, weil sie nichts an der Konfiguration verändert:

NEEDRESTART_MODE=a DEBIAN_FRONTEND=noninteractive apt-get -y upgrade

Eine Grenze sollten Sie kennen: needrestart betrachtet die Prozesse des Wirtssystems. Dienste in Containern erneuert es nicht, dort brauchen Sie neue Abbilder.

Der Versionswechsel ist eine eigene Kategorie

Ein Wechsel von Debian 12 auf Debian 13 oder von Ubuntu 22.04 auf 24.04 ist kein Upgrade im obigen Sinn. Er tauscht die Paketquellen aus und ersetzt praktisch jedes Paket. Drei Regeln gelten dabei immer: eine Version pro Durchgang, keine übersprungenen Zwischenversionen, und vorher eine Sicherung, aus der sich der Server wiederherstellen lässt.

Auf Debian stellen Sie zuerst die Quellen um. Debian 12 verwendet dafür /etc/apt/sources.list, Debian 13 die Datei /etc/apt/sources.list.d/debian.sources im neueren Format. Danach folgt ein bewusst zweistufiger Ablauf, den die Veröffentlichungshinweise so vorgeben:

apt update
apt-get upgrade --without-new-pkgs
apt full-upgrade

Der mittlere Schritt aktualisiert zuerst die Pakete, die ohne Umbau auskommen. Das hält die Zahl der gleichzeitig bewegten Pakete klein und macht einen Abbruch reparierbar. Vergessen Sie die Komponente non-free-firmware nicht, sie ist seit Debian 12 eigenständig und fehlt in alten Quellendateien. Wenn Ihr apt den Befehl apt modernize-sources kennt (prüfbar mit apt --version), überführt er die alte Quellendatei in das neue Format.

Auf Ubuntu gibt es dafür ein eigenes Werkzeug, und Sie sollten ausschließlich dieses verwenden:

apt install -y ubuntu-release-upgrader-core
do-release-upgrade -c
do-release-upgrade

Der Schalter -c prüft nur und ändert nichts. Ob ein Wechsel angeboten wird, hängt von Prompt in /etc/update-manager/release-upgrades ab: Bei lts erscheint nur der Sprung zur nächsten LTS-Version, und zwar erst nach deren erster Zwischenveröffentlichung. Der Weg von 20.04 auf 24.04 führt zwingend über 22.04.

Ein Detail, das viele überrascht: Läuft do-release-upgrade über SSH, startet es einen zusätzlichen SSH-Dienst auf Port 1022 als Rückfallebene und weist darauf hin, dass Sie diesen Port gegebenenfalls in der Firewall öffnen müssen. Nutzen Sie das, aber verlassen Sie sich nicht darauf. Die tmux-Sitzung und der Zugang über die VNC-Konsole sind verlässlicher.

Aufräumen nach dem Upgrade

Nach einem größeren Durchgang liegen drei Arten von Resten herum: heruntergeladene Paketdateien, verwaiste Pakete und Konfigurationsreste entfernter Pakete.

apt autoremove --purge
apt autoclean

autoclean löscht aus /var/cache/apt/archives nur die Dateien, die ohnehin nicht mehr angeboten werden. apt clean leert den Zwischenspeicher vollständig, bringt also mehr Platz, macht dafür jede erneute Installation zu einem neuen Download.

Konfigurationsreste erkennen Sie am dpkg-Status rc, also entfernt, aber Konfiguration noch vorhanden:

dpkg -l | awk '/^rc/ {print $2}'

Was dort steht, entfernen Sie mit apt purge PAKETNAME endgültig. Bei alten Kerneln ist mehr Sorgfalt angebracht, weil ein Fehlgriff den Server unbootbar macht:

uname -r
dpkg -l 'linux-image-*' | awk '/^ii/ {print $2}'

Entfernen Sie niemals den Kernel, den die erste Zeile nennt, und behalten Sie zusätzlich einen älteren funktionierenden, damit das Startmenü eine Rückfallebene hat. Meist erledigt apt autoremove --purge das ohnehin korrekt.

Häufige Fehler und Lösungen

E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 1234 (unattended-upgr): Ein zweiter Paketvorgang läuft bereits, meist die automatische Sicherheitsaktualisierung. Nicht abbrechen, sondern zu Ende laufen lassen. Das vollständige Vorgehen samt Reparatur steht in apt konnte Sperre nicht aufheben.

E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem.: Ein vorheriger Lauf wurde unterbrochen, typischerweise durch einen Verbindungsabbruch. Führen Sie genau diesen Befehl aus und wiederholen Sie danach das Upgrade.

E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).: Ein Paket ist installiert, seine Abhängigkeiten fehlen. apt --fix-broken install holt sie nach. Kommt der Fehler wieder, liegt es fast immer an einer Fremdquelle, die Pakete für eine andere Distributionsversion anbietet.

E: Release file for http://deb.debian.org/debian/dists/trixie/InRelease is not valid yet (invalid for another 5h 3min 2s).: Die Uhr des Servers geht nach. Prüfen Sie mit timedatectl status, ob System clock synchronized: yes gemeldet wird, korrigieren Sie die Zeit und wiederholen Sie apt update. Am Repository liegt es nicht.

W: GPG error: ... The following signatures couldn't be verified because the public key is not available: NO_PUBKEY ..., gefolgt von E: The repository '...' is not signed.: Der Signaturschlüssel einer Fremdquelle fehlt oder wurde ausgetauscht. Der Schlüssel gehört heute nach /etc/apt/keyrings/ und wird in der Quellenangabe über signed-by beziehungsweise über das Feld Signed-By: referenziert. apt-key ist abgekündigt und sollte nicht mehr verwendet werden.

E: Repository '... InRelease' changed its 'Suite' value from 'stable' to 'oldstable': Das passiert regulär, wenn eine neue Debian-Version erscheint und Ihre Quellen auf stable statt auf den Codenamen zeigen. Einmalig bestätigen mit apt update --allow-releaseinfo-change, danach die Quellen auf den Codenamen umstellen. Ein Server, der stable folgt, wechselt sonst irgendwann unbeabsichtigt die Distributionsversion.

E: The repository 'http://... Release' does not have a Release file.: Die Quelle bietet für Ihre Version nichts an, meist weil eine Fremdquelle den Codenamen noch nicht unterstützt oder weil die Distribution ihr Lebensende erreicht hat. Deaktivieren Sie die betroffene Zeile und prüfen Sie die Quelle.

No space left on device mitten im Auspacken: /boot oder /var sind voll. Mit dpkg --configure -a aufräumen, Platz schaffen, wiederholen. Vor jedem Kernel-Upgrade lohnt der Blick auf df -h /boot.

debconf: unable to initialize frontend: Dialog: Nur ein Hinweis, keine Störung. Er erscheint ohne voll ausgestattetes Terminal, etwa in einem Skript. Mit DEBIAN_FRONTEND=noninteractive verschwindet er.

Die vier Systeme im Vergleich

Die Abschlusskontrolle

Dass ein Befehl ohne Fehler zurückkam, heißt nicht, dass das System in Ordnung ist. Diese sechs Prüfungen sagen etwas aus:

1. apt list --upgradable gibt außer Listing... nichts aus.
2. apt-mark showhold enthält nur, was Sie bewusst gesperrt haben.
3. dpkg --audit schweigt.
4. needrestart -b meldet NEEDRESTART-KSTA: 1 und keine offenen Dienste.
5. systemctl --failed listet nichts auf.
6. find /etc -name '*.dpkg-dist' findet nichts mehr, weil Sie jede Abweichung abgearbeitet haben.

Verlangt Punkt vier einen Neustart, planen Sie ihn und führen Sie ihn durch. Ein Server, der monatelang auf einen ausstehenden Neustart wartet, sammelt genau die Lücken ein, gegen die Sie eigentlich aktualisiert haben. Prüfen Sie danach ein letztes Mal uname -r und systemctl --failed. Der Neustart ist der Moment, in dem sich zeigt, ob alles wieder hochkommt.