Es ist rund 4 Jahre her, dass ich hier beschrieben hatte, wie ich meinen Server von Debian 9 auf Debian 10 aktualisiert hatte. Und das Update von Version 10 auf 11 habe ich gar nicht beschrieben. Upsa!
Hier will ich nun möglichst kurz & knapp darstellen, wie ich meine Systeme von Debian 11 auf Debian 12 aktualisiert habe, und was es dabei für mich zu beachten gab.
Im Wesentlichen folge ich dabei dem Kapitel Upgrade von Debian 11 (Bullseye) für die AMD64-Architektur der „Hinweise zur Debian-Veröffentlichung Version 12 (Bookworm) auf 64-Bit PC“ (den Release Notes).
Vorbereitung
Eine gute Datensicherung sollte obligat sein. Insofern mache ich mir keine besondere Mühe, vor dem Upgrade irgendwelche Daten speziell zu sichern. Im Zweifel kann ich in mein reguläres Backup schauen.
Liste der „fremden“ Pakete prüfen:
apt list '?narrow(?installed, ?not(?origin(Debian)))'
Konfigurationsdateien prüfen, gibt es „Überbleibsel“ früherer Aktualisierungen? Diese sollten wir zunächst aufräumen!
sudo find /etc -name '*.dpkg-*' -o -name '*.ucf-*' -o -name '*.merge-error'
Sicherstellen, dass gpgv
in der richtigen Version installiert ist:
sudo apt install gpgv
Status der installierten Pakete und „hold“-Markierungen prüfen:
sudo dpkg --audit
sudo apt-mark showhold
Wenn hier Pakete genannt werden, sollte deren Status vor dem Upgrade auf jeden Fall geprüft und ggf. bereinigt werden!
Paketquellen für Debian 12 „Bookworm“ aktualisieren
Zunächst mache ich das mit dem „Holzhammer“ und ersetze in allen Paketquellen-Definitionen den Wert „bullseye“ von Debian 11 durch „bookworm“ für Debian 12 – siehe sources.list(5):
sudo sed -i'' -e 's/bullseye/bookworm/g' \
/etc/apt/sources.list \
/etc/apt/sources.list.d/*.list
APT (Advanced Packaging Tool) anpassen
APT Konfiguration: /etc/apt/apt.conf.d/
prüfen
Wenn man die Konfiguration von APT – siehe apt.conf(5) – in /etc/apt/apt.conf
oder (besser!) durch ein „Drop-in File“ in /etc/apt/apt.conf.d/
angepasst hat, so sollte man prüfen, ob hier irgendwo der Distributionsname verwendet wird und diesen gegebenenfalls anpassen (es könnte z. B. APT::Default-Release
gesetzt sein):
sudo sed -i'' -e 's/bullseye/bookworm/g' \
/etc/apt/apt.conf \
/etc/apt/apt.conf.d/*
Fehlermeldungen zu nichtexistierenden Dateien können hierbei ignoriert werden, da diese Dateien alle optional sind.
APT Preferences: /etc/apt/preferences.d/
prüfen
In den „APT preferences“ – siehe apt_preferences(5) – wird konfiguriert, nach welchen Regeln APT verschiedene Versionen ein und desselben Pakets gegeneinander bevorzugt.
Wenn dieser Mechanismus genutzt wird (in einer Standard-Installation ist dies zunächst nicht der Fall), so sollte man auch hier prüfen, ob Anpassungen vor dem Update notwendig sind. Die relevanten Dateien befinden sich in:
/etc/apt/preferences
/etc/apt/preferences.d/*
Bevor es wirklich los geht …
- Ist das Root-Dateisystem (und alle anderen für das Update benötigten Dateisysteme) schreibbar?
Evtl. kann einsudo mount -o remount,rw /
notwendig sein! - Wie sieht es mit dem verfügbaren Speicherplatz aus?
Paketquellen aktualisieren
Nachdem wir die Konfiguration von APT bearbeitet haben, muss die lokale Datenbank der verfügbaren Pakete aktualisiert werden:
sudo apt update
Achtung: Alle Fehler, die hier evtl. angezeigt werden, müssen vor dem Update behoben werden!
Testlauf
Mit folgendem Befehl wird ein Upgrade simuliert:
sudo apt -o APT::Get::Trivial-Only=true full-upgrade
Sollten Fehler angezeigt werden, müssen diese vor dem eigentlichen Upgrade behoben werden!
Die Meldung „»–trivial-only« wurde angegeben, aber dies ist keine triviale Operation“ (o. ä.) ist hingegen kein Fehler sondern hier zu erwarten.
Upgrade durchführen
Das eigentliche System-Upgrade wird in zwei Schritten durchgeführt:
Minimales System-Upgrade
sudo apt upgrade --without-new-pkgs
Upgrade des Systems
sudo apt full-upgrade
Bei diesem Befehl sollte vor allem die Sektion kontrolliert werden, in welcher die zu entfernenden Pakete gelistet werden! Es ist normal, dass Pakete entfernt werden (z. B. weil PHP 7.4 oder Python 3.9 durch neuere Versionen ersetzt werden), aber es sollte in sich schlüssig sein 🙂
System neutralen
sudo reboot
Aufräumen
Veraltete Konfigurationsdateien
Pakete auflisten und dann entfernen, die bereits deinstalliert worden sind, von denen jedoch noch Konfigurationsdateien übrig geblieben sind:
apt list '~c'
sudo apt purge '~c'
Veraltete Pakete
Veraltete („lokal installierte“) Pakete auflisten und – nach eingehender Prüfung und ggf. Migration! – vom System löschen:
apt list '~o'
sudo apt purge '~o'
Konfigurationsdateien prüfen & aktualisieren
Mit folgendem Befehl können alle Konfigurationsdateien in /etc
aufgelistet werden, die entweder aktualisiert wurde sind (und eine Sicherungskopie erstellt wurde), oder von denen neuere Versionen neben die existierende „alte“ Version angelegt wurde:
sudo find /etc -name '*.dpkg-*' -o -name '*.ucf-*' -o -name '*.merge-error'
Beinhaltet die Dateiendung hierbei „new“ oder „dist“ (z. B. /etc/pam.d/sudo.dpkg-new
oder /etc/mailman3/mailman.cfg.ucf-dist
), so handelt es sich um eine neue Version der Datei, die der Debian-Paketbetreuer zur Verfügung gestellt hat, die jedoch nicht automatisch die vorhandene lokale Version überschrieben hat.
Ist „old“ in der Dateiendung enthalten (wie z. B. in /etc/apt/sources.list.d/zabbix.list.dpkg-old
), so ist dies eine Sicherungsversion einer lokalen Konfigurationsdatei, die durch eine neuere Version des Paketbetreuers ersetzt worden ist.
Alle diese Dateien hier sollten sorgfältig mit ihren „aktiven“ Versionen (ohne die *.dpkg-*
, *.ucf-*
, … Dateiendungen) abgeglichen, gegebenenfalls die aktiven Dateien aktualisiert und anschließend die neuen bzw. alten Varianten gelöscht werden!
Logs prüfen
Auf jeden Fall sollte man noch einen Blick (oder gerne auch nach einige Zeit weitere!) in die Protokolle des Systems werfen und prüfen, ob hier Warn- oder Fehlermeldungen enthalten sind.
Folgender Befehl gibt z. B. alle Meldungen mit dem Level „Warnung oder schlimmer“ (-p warning
) seit dem Systemstart (-b
) aus:
journalctl -b -p warning
Alle „Warnungen oder schlimmer“ seit Mitternacht kann man so ausgeben lassen:
journalctl --since today -p warning
Und wie immer verrät die Manual Page zu journalctl(1) mehr 😉
Und fertig!
Das ist es nun eigentlich gewesen. Auf meinen Systemen hat das Upgrade eigentlich überall problemlos funktioniert. Nacharbeiten waren vor allem an meinem Mailman-Setup notwendig, zudem musste ich einige Logcheck-Regeln anpassen, da hier neue Meldungen dazugekommen sind und bestehende ihre Syntax geändert haben – aber das war beides zu erwarten.
0 Kommentare