Ubuntu 24.04 auf 26.04 upgraden: Termin und Ablauf

Wann können Sie Ubuntu 24.04 auf 26.04 aktualisieren?

Sie können Ubuntu 24.04 auf einem VPS auf 26.04 aktualisieren, sobald die Point-Release-Version 26.04.1 veröffentlicht wird. Das ist für den 27. August 2026 geplant. Bis dahin wird ein 24.04-Server die neue Version absichtlich nicht angeboten bekommen. Ubuntu 26.04 LTS (Resolute Raccoon) wurde am 23. April 2026 veröffentlicht. Canonical aktiviert den Upgrade-Pfad von LTS zu LTS jedoch erst mit der ersten Point-Release-Version, weil diese die in den ersten Monaten gefundenen Fehler bei Installation und Upgrade bündelt. Falls Ihnen die neue Nummerierung nicht vertraut ist: 26.04.1 ist kein anderes Ubuntu, sondern dasselbe 26.04 mit vier Monaten Fehlerbehebungen, die in die Installationsmedien eingeflossen sind. Genau deshalb ist dies die erste Version, die Canonical für einen bestehenden Server freigibt.

Führen Sie die Prüfung Anfang August 2026 auf einem 24.04-System aus, erhalten Sie Folgendes:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

Das ist kein Fehler auf Ihrem Server. /etc/update-manager/release-upgrades enthält unter Ubuntu Server Prompt=lts. Das bedeutet, dass das Tool nur die nächste Long-Term-Support-Version anbietet, und zwar erst, sobald deren .1-Point-Release verfügbar ist. Mit Prompt=normal würden Sie stattdessen nacheinander durch 24.10, 25.04 und 25.10 geführt. Diese Zwischenversionen haben inzwischen alle ihr End of Life erreicht. Lassen Sie die Einstellung auf lts und warten Sie. Die Termine in Canonicals Zeitplan können sich ändern. Prüfen Sie den Status daher erneut, wenn der angegebene Tag ohne Änderung verstreicht.

Jeden der folgenden Befehle führen Sie selbst auf Ihrem eigenen Server in der angegebenen Reihenfolge aus. Ein Release-Upgrade kann auf dem System, das Sie aktualisieren, nicht probeweise durchgeführt werden. Es ersetzt den Kernel und die C-Bibliothek und benötigt zum Abschluss einen Reboot.

Sollten Sie überhaupt aktualisieren?

Ubuntu 24.04 erhält bis 2029 reguläre Sicherheitsupdates. Für einen funktionierenden Produktionsserver besteht daher kein Zeitdruck. Aktualisieren Sie, wenn Sie etwas benötigen, das 26.04 mitbringt: PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 oder den 7.0-Kernel. „Die Nummer ist höher“ ist kein Grund, eine Maschine anzufassen, die Kunden bedient.

Führen Sie kein In-Place-Upgrade durch, wenn eine der folgenden Bedingungen zutrifft:

• Sie haben noch nie die Konsole Ihres Providers (VNC oder seriell) geöffnet und sich darüber angemeldet. Diese Konsole ist der einzige Rückweg auf den Server, wenn SSH ausfällt. Wenn Sie erst während der Aussperrung feststellen, dass sie nicht funktioniert, ist es zu spät.
• Sie können sich keine Stunde Ausfallzeit leisten und haben keinen Rollback.
• Ihr Stack hängt von einem Drittanbieter-Repository ab, das noch keine Pakete für resolute veröffentlicht hat.
• Der Server wurde vor mehr als zwei Jahren manuell eingerichtet, und niemand weiß, was darauf installiert ist.

Die Alternative ist oft besser: Erstellen Sie eine neue 26.04-VPS, installieren Sie Ihren Stack, stellen Sie die Daten wieder her und ändern Sie anschließend den DNS-Eintrag, sobald der neue Server korrekt antwortet. Der alte Server bleibt in Betrieb, bis sich der neue bewährt hat. Für ein Rollback müssen Sie dann lediglich den DNS-Eintrag ändern, statt eine Wiederherstellung durchzuführen. Wenn Sie diesen Weg wählen, beginnen Sie mit den ersten zehn Minuten auf einer neuen VPS und richten Sie den neuen Server ordnungsgemäß ein.

Schritt 1: Erstellen Sie ein wiederherstellbares Backup

Verwenden Sie zwei Ebenen, weil sie auf unterschiedliche Weise ausfallen. Ein Provider-Snapshot erfasst die gesamte Festplatte und lässt sich innerhalb weniger Minuten wiederherstellen. Er wird jedoch erstellt, während Ihre Datenbanken Schreibvorgänge ausführen. Daher ist er nur crash-konsistent und nicht anwendungskonsistent. Ein dateibasiertes Backup mit restic, das außerhalb des Servers gespeichert wird stellt einzelne Dateien bereit und enthält eine Kopie, die auch bei einer Sperrung Ihres Kontos erhalten bleibt.

Erstellen Sie zuerst manuell einen Dump der Datenbanken. Ein Dump ist die einzige Datenbanksicherung, der Sie vertrauen können, ohne die Datenbank anzuhalten.

sudo -u postgres pg_dumpall | sudo tee /var/backups/pg-all.sql > /dev/null
sudo mysqldump --all-databases --single-transaction --routines | sudo tee /var/backups/mysql-all.sql > /dev/null
sudo tar czf /var/backups/etc-before-upgrade.tgz -C / etc
sudo chmod 600 /var/backups/pg-all.sql /var/backups/mysql-all.sql

--single-transaction erstellt nur für InnoDB-Tabellen einen konsistenten Dump. Für MyISAM-Tabellen muss die Datenbank angehalten werden. Das /etc-Tarball ist das Archiv, auf das Sie tatsächlich zurückgreifen werden, weil es jede Konfigurationsdatei enthält, zu der das Upgrade Sie gleich Fragen stellen wird.

Ein Backup, das Sie noch nie wiederhergestellt haben, ist nur eine Vermutung. Stellen Sie jetzt eine Datei daraus wieder her, bevor Sie sie unter Zeitdruck benötigen.

Schritt 2: Aktualisieren Sie 24.04 zunächst vollständig

do-release-upgrade wird auf einem System mit einem fehlerhaften Paketstatus nicht ausgeführt. Ein nur teilweise aktualisiertes 24.04 erschwert die Diagnose aller späteren Fehler.

sudo apt update
sudo apt full-upgrade
sudo apt --purge autoremove
sudo dpkg --audit
apt-mark showhold

Wenn dpkg --audit keine Ausgabe erzeugt, ist kein Paket nur teilweise konfiguriert. Wenn apt-mark showhold keine Ausgabe erzeugt, ist kein Paket auf eine Version festgelegt, die das Upgrade blockiert. Geben Sie alle dort aufgeführten Pakete mit sudo apt-mark unhold und dem Paketnamen frei. Alternativ können Sie davon ausgehen, dass die Sperre einen Grund hat, und hier abbrechen.

Starten Sie das System neu, wenn sich der Kernel geändert hat. So führen Sie das Upgrade auf einem System aus, das den Code verwendet, von dem es ausgeht, dass er ausgeführt wird.

[ -f /var/run/reboot-required ] && sudo reboot

Prüfen Sie anschließend den verfügbaren Speicherplatz. Das Upgrade-Programm lädt den vollständigen neuen Paketsatz herunter, bevor es etwas installiert. Wenn der Speicherplatz nicht ausreicht, bricht es mit einer Meldung ab, die das betroffene Dateisystem nennt.

df -h / /boot

Bei weniger als etwa 5 GB freiem Speicherplatz auf / treten die Probleme meist auf. Ein /boot mit weniger als 300 MB freiem Speicherplatz schlägt später während der Kernel-Installation mit No space left on device fehl. Alte Kernel sind meist die Ursache. sudo apt --purge autoremove entfernt sie.

Beenden Sie vor dem Start außerdem die automatischen Sicherheitsaktualisierungen. Wenn sie während des Upgrades ausgeführt werden, belegen sie die dpkg-Sperre. Das Upgrade-Programm bricht dann mit Could not get lock /var/lib/dpkg/lock-frontend ab. Führen Sie zuerst sudo systemctl stop unattended-upgrades aus und starten Sie das Upgrade anschließend erneut.

Schritt 3: Drittanbieter-Repositorys und festgelegte Pakete prüfen

do-release-upgrade deaktiviert jede APT-Quelle, die nicht von Ubuntu stammt, weil ein für noble erstelltes Paket ein resolute-System beschädigen kann. Anschließend aktiviert das Tool die erkannten Quellen wieder und lässt die übrigen auskommentiert. Prüfen Sie, welche Quellen und Pakete Sie verwenden, bevor das Tool diese Entscheidung für Sie trifft.

ls /etc/apt/sources.list.d/
grep -rhE '^(deb |Types:|URIs:|Suites:)' /etc/apt/sources.list.d/
ubuntu-security-status --thirdparty
ls /etc/apt/preferences.d/

Ubuntu 24.04 verwendet in diesem Verzeichnis zwei Formate: die alten einzeiligen .list-Dateien und deb822-.sources-Dateien mit den Feldern Types: und Suites:. Das Upgrade deaktiviert beide Formate. ubuntu-security-status --thirdparty listet die installierten Pakete auf, für die kein Ubuntu-Archiv eine Version bereitstellt. Das ist die tatsächliche Anzahl der Pakete, die Sie zusätzlich installiert haben. Jeder Eintrag in /etc/apt/preferences.d/ ist eine Paketpräferenz. Eine für noble geschriebene Paketpräferenz sorgt dafür, dass auf der neuen Version weiterhin ein altes Paket ausgewählt wird.

Prüfen Sie für jedes Drittanbieter-Repository, ob der Anbieter vor Beginn eine Version für den neuen Codenamen veröffentlicht hat. Die Suiten von Docker sind unter https://download.docker.com/linux/ubuntu/dists/ aufgeführt. Andere Anbieter stellen dasselbe Verzeichnis bereit. Eine Quelle, die auf eine nicht vorhandene Suite verweist, führt beim ersten apt update nach dem Upgrade zu dieser Ausgabe:

E: The repository 'https://download.docker.com/linux/ubuntu resolute Release' does not have a Release file.

Lassen Sie diese Quelle deaktiviert, bis der Anbieter sie veröffentlicht. Wenn Sie den Codenamen auf eine Suite ändern, für die der Anbieter tatsächlich Pakete erstellt hat, installieren Sie Pakete, die gegen die falschen Systembibliotheken gelinkt sind.

Schritt 4: Führen Sie das Upgrade in tmux aus, nicht in einer einfachen SSH-Shell

Wenn die Verbindung abbricht, während do-release-upgrade in einer einfachen Login-Shell läuft, empfängt der Prozess SIGHUP und wird während des Entpackens beendet. Dadurch bleibt dpkg teilweise konfiguriert. Außerdem kann der Server anschließend möglicherweise keinen funktionierenden Netzwerk-Stack mehr haben, über den Sie sich erneut verbinden können. Führen Sie den Vorgang stattdessen innerhalb eines Terminal-Multiplexers aus. Dadurch bleibt der Prozess auf dem Server aktiv, wenn die Verbindung Ihres Clients abbricht.

sudo apt install -y tmux
tmux new -s upgrade

Führen Sie innerhalb dieser Sitzung Folgendes aus:

sudo ufw allow 1022/tcp
sudo do-release-upgrade

Das Upgrade-Programm startet einen zweiten SSH-Daemon auf Port 1022, bevor es Änderungen vornimmt, und weist darauf hin:

To make recovery in case of failure easier, an additional sshd will be started on port '1022'. If anything goes wrong with the running ssh you can still connect to the additional one.

Es öffnet diesen Port nicht in Ihrer Firewall. Ohne Nachfrage ein Loch in eine Firewall zu öffnen, wäre eine unerwartete und problematische Änderung. Öffnen Sie Port 1022 selbst, bevor Sie beginnen, und schließen Sie ihn wieder, wenn Sie mit sudo ufw delete allow 1022/tcp fertig sind. Denken Sie daran, dass Ihr Provider möglicherweise eine zweite Firewall in seinem Control Panel betreibt, die sich außerhalb des Servers befindet.

Wenn die Verbindung trotzdem abbricht, melden Sie sich erneut an und führen Sie tmux attach -t upgrade aus. Das Upgrade wurde während Ihrer Abwesenheit fortgesetzt. Falls dies nicht geschehen ist und Sie zu einer teilweise konfigurierten dpkg-Installation oder zu apt-Quellen zurückkehren, die teils aus noble und teils aus resolute bestehen, beschreibt die Wiederherstellung nach einem fehlgeschlagenen Release-Upgrade, wie Sie den Paketstatus reparieren und erkennen, wann Sie die Reparatur abbrechen und stattdessen den Snapshot wiederherstellen sollten.

Schritt 5: Beantworten Sie die Aufforderungen zu Konfigurationsdateien bewusst

dpkg fordert nur bei Dateien nach, die Sie oder ein Skript geändert haben. Jede Aufforderung bezieht sich daher auf eine Datei, die Sie absichtlich bearbeitet haben. Wenn Sie einfach die Eingabetaste drücken, damit die Aufforderung verschwindet, wird aus einem gehärteten Server unbemerkt wieder ein System mit Standardeinstellungen.

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] ?

Drücken Sie jedes Mal zuerst D. Lesen Sie, was sich geändert hat, und behalten Sie dann Ihre Version mit N. Die Voreinstellung ist bereits N. Das ist die sichere Antwort, weil Ihre Datei heute funktioniert und die paketierte Version auf diesem Rechner noch nie ausgeführt wurde.

Ihre Datei zu behalten, hat einen Nachteil: Sie erhalten die neuen Standardeinstellungen nicht. Führen Sie den Abgleich später durch, wenn das System wieder läuft und Sie nicht unter Zeitdruck stehen.

sudo find /etc -name '*.dpkg-dist' -o -name '*.dpkg-new'

Jede Datei, die als Liste angezeigt wird, ist die Version des Paketbetreuers und wurde neben Ihrer Version gespeichert. Vergleichen Sie die Dateien einzeln und übernehmen Sie die wichtigen Einstellungen. Bei zwei Dateien ist besondere Sorgfalt erforderlich: /etc/ssh/sshd_config, weil die falsche Antwort Ihre Sitzung beendet, und Ihre Webserver-Konfiguration, weil die falsche Antwort die Websites außer Betrieb nimmt.

Das Upgrade fragt über needrestart auch, welche Dienste neu gestartet werden sollen. Übernehmen Sie die vollständige Liste. Ein Daemon, der weiterhin eine gemeinsam verwendete Bibliotheksdatei nutzt, die bereits von der Festplatte gelöscht wurde, stürzt bei einer späteren Anfrage möglicherweise ab. Dann überwachen Sie ihn unter Umständen gerade nicht.

Schritt 6: Neustart durchführen und anschließend den Rechner prüfen

sudo reboot

Nach dem Neustart:

lsb_release -a
uname -r
systemctl --failed
journalctl -p err -b --no-pager | head -50
sudo apt update && sudo apt full-upgrade
sudo apt --purge autoremove

lsb_release -a sollte Release: 26.04 und Codename: resolute melden. uname -r sollte einen 7.0-Kernel anzeigen. systemctl --failed sollte null Units auflisten. Jede dort aufgeführte Unit ist Ihre nächste Aufgabe. Der abschließende Befehl apt update lädt die Updates herunter, die seit der Erstellung der Release-Images veröffentlicht wurden.

PostgreSQL 16 auf 18: Der Cluster bleibt unbemerkt zurück

Ubuntu 24.04 enthält PostgreSQL 16, Ubuntu 26.04 PostgreSQL 18. Das Upgrade installiert 18 zusätzlich zu 16 und verschiebt Ihre Daten nicht. Die Debian-postgresql-common-Schicht erstellt für die neue Hauptversion auf dem nächsten freien Port einen neuen leeren Cluster. Dadurch verwendet 16 weiterhin Port 5432 mit allen Ihren Daten, während 18 leer auf Port 5433 läuft. Ihre Anwendung verwendet weiterhin Port 5432, und es scheint alles ordnungsgemäß zu funktionieren. Deshalb wird dieses Problem oft erst Monate später entdeckt.

pg_lsclusters

Wenn zwei Cluster aufgeführt sind, wurde die Migration noch nicht durchgeführt. Führen Sie sie durch, sobald Sie die Anwendung anhalten können:

sudo pg_dropcluster --stop 18 main
sudo pg_upgradecluster 16 main
pg_lsclusters
sudo -u postgres vacuumdb --all --analyze-only

Löschen Sie zuerst den leeren 18-Cluster, weil pg_upgradecluster nicht in einen bereits vorhandenen Ziel-Cluster schreibt. Die Standardmethode erstellt einen Dump von 16 und lädt ihn in 18, daher benötigen Sie ungefähr so viel freien Speicherplatz wie die Datenbank groß ist. -m upgrade verwendet stattdessen pg_upgrade und ist bei einer großen Datenbank deutlich schneller. Lesen Sie nach Abschluss die Spalte Port: Der neue Cluster übernimmt Port 5432, und der alte Cluster bleibt angehalten. Führen Sie den Analyze-Lauf selbst aus, weil ein frisch geladener Cluster noch keine Statistiken besitzt und die ersten Abfragen langsam sind.

Testen Sie die Anwendung einige Tage lang mit dem neuen Cluster. Entfernen Sie den alten Cluster erst danach:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

Das Datenverzeichnis des alten Clusters ist Ihre schnellste Möglichkeit für ein Rollback. Löschen Sie es am Tag des Upgrades nicht.

MySQL 8.0 auf 8.4: Die entfernte Option, die den Server am Start hindert

26.04 aktualisiert MySQL von 8.0 auf 8.4 LTS. Dabei führen zwei Änderungen bei Servern zu Problemen.

Erstens startet mysqld nicht, wenn die Konfiguration eine Option enthält, die in der neuen Version entfernt wurde. default_authentication_plugin ist die häufigste dieser Optionen, weil viele ältere Anleitungen empfehlen, sie zu setzen. Der Dienst schlägt fehl, und journalctl -u mysql -n 50 nennt die unbekannte Variable direkt. Löschen Sie die betreffende Zeile aus der Datei unter /etc/mysql/mysql.conf.d/. Führen Sie anschließend sudo systemctl start mysql aus.

Zweitens ist das Plugin mysql_native_password in 8.4 standardmäßig nicht mehr aktiviert. Ein Konto, das dieses Plugin weiterhin verwendet, kann sich daher überhaupt nicht anmelden. Prüfen Sie dies, solange Sie noch 8.0 verwenden:

sudo mysql -e "SELECT user, host, plugin FROM mysql.user;"

Stellen Sie alle Konten mit mysql_native_password vor dem Upgrade um. Aktualisieren Sie anschließend das Kennwort in der Anwendungskonfiguration:

ALTER USER 'appuser'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'a new password';

Wenn eine Clientbibliothek zu alt ist, um caching_sha2_password zu verwenden, können Sie das alte Plugin in 8.4 wieder aktivieren. Fügen Sie dazu mysql_native_password=ON unter [mysqld] hinzu. Betrachten Sie dies als Übergangslösung mit einem festgelegten Enddatum, da das Plugin vollständig entfernt werden soll.

PHP 8.3 auf 8.5: Ihre VHosts verweisen auf einen nicht mehr vorhandenen Socket

24.04 liefert PHP 8.3, 26.04 liefert PHP 8.5. Die Pakete werden in versionsspezifischen Pfaden installiert. Ihre Webserver-Konfiguration wird dabei nicht angepasst. Ein nginx-VHost mit fastcgi_pass unix:/run/php/php8.3-fpm.sock; verweist jetzt auf einen Socket, den kein Prozess erstellt. Jede PHP-Anfrage liefert daher 502, und das nginx-Error-Log enthält:

connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)

Verweisen Sie auf den neuen Socket, prüfen Sie die Konfiguration und laden Sie nginx neu:

sudo sed -i 's/php8.3-fpm.sock/php8.5-fpm.sock/' /etc/nginx/sites-available/example.com
sudo nginx -t
sudo systemctl reload nginx

Bei Apache mit mod_php ist das Fehlerbild anders: Apache startet überhaupt nicht, und sudo apache2ctl -t meldet, dass libphp8.3.so nicht geladen werden kann, weil die Datei nicht existiert. Das aktivierte Modul ist ein Symlink auf ein nicht mehr vorhandenes Paket.

sudo a2dismod php8.3
sudo a2enmod php8.5
sudo systemctl restart apache2

Wenn Sie das System anhand von einem LAMP-Stack auf Ubuntu 24.04 eingerichtet haben, sollten Sie beide Pfade prüfen. Die Anleitung hinterlässt einen versionsspezifischen Modulnamen und einen versionsspezifischen Socket.

Auch Ihre php.ini-Konfiguration wird nicht übernommen. memory_limit, upload_max_filesize und alle weiteren Einstellungen befinden sich in /etc/php/8.3/. Der neue Verzeichnisbaum verwendet die Standardwerte. Vergleichen Sie die beiden Dateien und übertragen Sie die Werte manuell. Wenn Sie die alte Datei vollständig über die neue kopieren, übernehmen Sie 8.3-Standardwerte in eine 8.5-Installation. Führen Sie anschließend php -m aus und vergleichen Sie die Ausgabe: Eine Erweiterung, die als php8.3-redis installiert ist, benötigt das Paket php8.5-. Wenn sie aus einem PPA stammt, hat das Upgrade-Programm diese Quelle deaktiviert und die Erweiterung fehlt einfach.

Zertifikate sollten Sie separat prüfen. Führen Sie nach dem Upgrade sudo certbot renew --dry-run aus. Dadurch wird der gesamte Erneuerungspfad einschließlich des Hooks zum Neuladen des Webservers getestet, ohne das aktive Zertifikat zu verändern. Ein Hook, der einen Dienstnamen oder eine geänderte Binärdatei aufruft, schlägt hier sichtbar fehl und nicht erst nach 60 Tagen unbemerkt. Certbot mit Let's Encrypt auf nginx beschreibt, wie diese Hooks aussehen sollten.

SSH: Der Fehler, der die gerade verwendete Sitzung beendet

Die Eingabeaufforderung sshd_config ist der Punkt, an dem sich Administratoren aussperren. Mit Y installieren Sie die Datei des Paketbetreuers. Dadurch werden Ihr PermitRootLogin, PasswordAuthentication, AllowUsers, Port und alle weiteren von Ihnen hinzugefügten Zeilen verworfen. Wenn Ihre Firewall nur einen benutzerdefinierten Port zulässt und die mitgelieferte Konfiguration auf 22 lauscht, wird die nächste Verbindung abgewiesen. Die Sitzung, in der Sie gerade arbeiten, ist dann Ihre letzte.

Verhindern Sie das vor dem Upgrade. /etc/ssh/sshd_config beginnt unter 24.04 mit Include /etc/ssh/sshd_config.d/*.conf. OpenSSH verwendet für jede Einstellung den ersten gelesenen Wert. Ein am Anfang eingebundenes Drop-in hat daher Vorrang vor allen nachfolgenden Einträgen. Verschieben Sie Ihre Einstellungen in eine Datei, die nicht von dpkg verwaltet wird:

sudo tee /etc/ssh/sshd_config.d/99-local.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy
EOF
sudo chmod 644 /etc/ssh/sshd_config.d/99-local.conf
sudo sshd -t && sudo systemctl restart ssh

Sobald sich in /etc/ssh/sshd_config keine eigenen Einträge mehr befinden, ist diese Eingabeaufforderung unerheblich. Beide Antworten bewahren Ihre Einstellungen, weil diese in einer anderen Datei liegen.

Ein benutzerdefinierter Port erfordert eine zusätzliche Prüfung, weil er möglicherweise nicht dort definiert ist, wo Sie ihn erwarten:

systemctl is-enabled ssh.socket

Wenn dort enabled ausgegeben wird, verwaltet systemd den Listening-Port. Die Zeile Port in sshd_config wird ignoriert. Ubuntu verwendet für sshd seit 22.10 die Socket-Aktivierung. Deshalb scheint eine Änderung an Port 2222 wirkungslos zu sein. Setzen Sie den Port stattdessen auf der Socket-Unit mit sudo systemctl edit ssh.socket:

[Socket]
ListenStream=
ListenStream=2222

Der leere Wert ListenStream= ist erforderlich. Er löscht den geerbten Wert. Ohne ihn lauscht der Socket zusätzlich zu 2222 auch auf 22. Wenden Sie die Änderung mit sudo systemctl daemon-reload && sudo systemctl restart ssh.socket an.

Nach dem Upgrade und bevor Sie die aktuelle Sitzung schließen:

sudo sshd -t
sudo systemctl status ssh.socket --no-pager
sudo ss -lntp | grep -E ':(22|2222)'

Öffnen Sie anschließend auf Ihrem eigenen Rechner ein zweites Terminal und melden Sie sich erneut an. Eine funktionierende Shell in diesem zweiten Terminal ist der einzige aussagekräftige Nachweis. Lassen Sie die erste Sitzung geöffnet, bis das funktioniert. SSH auf einem VPS absichern erläutert die Einstellungen, die Sie in diesem Drop-in beibehalten sollten.

Wenn es bereits zu spät ist, bietet die Webkonsole Ihres Providers eine Anmeldung, die SSH nicht verwendet. Melden Sie sich dort an, korrigieren Sie die Konfiguration, führen Sie sudo sshd -t aus und starten Sie den Dienst neu. Genau deshalb prüfen Sie den Zugriff auf die Konsole vor einem Upgrade und nicht erst währenddessen.

FAQ

Warum meldet do-release-upgrade unter Ubuntu 24.04 „No new release found“?

Weil /etc/update-manager/release-upgrades auf Ubuntu Server Prompt=lts enthält. Diese Einstellung bietet das nächste Long-Term-Support-Release erst an, wenn dessen erste Point-Release verfügbar ist. Ubuntu 26.04 LTS wurde am 23. April 2026 veröffentlicht. 26.04.1 ist für den 27. August 2026 geplant. Bis zu diesem Tag sieht ein 24.04-Server kein neues Release. Lassen Sie die Einstellung unverändert, statt auf Prompt=normal umzuschalten. Andernfalls würden Sie stattdessen über die Zwischenversionen aktualisieren.

Muss ich den Server neu starten, um das Upgrade abzuschließen?

Ja. Das Upgrade installiert einen neuen Kernel, eine neue C-Bibliothek und ein neues Init-System. Das laufende System verwendet die alten Versionen weiter, bis es neu gestartet wird. do-release-upgrade fordert am Ende zu einem Neustart auf. Ein System, das bis „später“ weiterläuft, verwendet dann eine Mischung aus zwei Releases. Prüfen Sie nach dem Neustart uname -r auf den neuen Kernel und systemctl --failed auf Dienste, die den Neustart nicht überstanden haben.

Sollte ich ein Upgrade im laufenden Betrieb durchführen oder einen neuen 26.04-Server erstellen?

Erstellen Sie nach Möglichkeit einen neuen Server. Auf einem neuen VPS können Sie den Stack installieren, die Daten wiederherstellen und alles testen, während der alte Server weiterhin Netzwerkverkehr verarbeitet. Ein Rollback besteht dann aus einer DNS-Änderung und nicht aus einer Wiederherstellung aus dem Backup. Führen Sie das Upgrade im laufenden Betrieb durch, wenn der Server schwer verschiebbaren Zustand enthält, der Anbieter pro Maschine abrechnet oder Sie über einen Snapshot und nachweislich funktionierenden Konsolenzugriff verfügen. Der direkte Upgrade-Pfad ist gut erprobt. Für die Dauer des Upgrades ist er jedoch unumkehrbar.

Was passiert, wenn meine SSH-Verbindung während des Upgrades abbricht?

In einer einfachen Login-Shell empfängt der Prozess SIGHUP und wird während des Upgrades beendet. Dadurch bleibt dpkg teilweise konfiguriert. Starten Sie den Vorgang innerhalb von tmux oder screen. Dann bleibt der Prozess aktiv und Sie können die Verbindung wiederherstellen und mit tmux attach -t upgrade fortfahren. Das Upgrade-Programm startet außerdem einen zusätzlichen SSH-Daemon auf Port 1022 als zweiten Zugangsweg. Es öffnet die Firewall für diesen Port jedoch nicht. Erlauben Sie Port 1022 daher zuerst selbst und schließen Sie ihn anschließend wieder.

Meine PHP-Site liefert nach dem Upgrade 502. Was ist fehlgeschlagen?

Der Pfad des PHP-FPM-Sockets hat sich mit der Version geändert. Ubuntu 24.04 verwendet PHP 8.3, Ubuntu 26.04 PHP 8.5. Daher existiert /run/php/php8.3-fpm.sock nicht mehr, während Ihr nginx-vhost weiterhin darauf verweist. Das nginx-Fehlerprotokoll zeigt connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory). Aktualisieren Sie fastcgi_pass auf den Socket für 8.5, führen Sie sudo nginx -t aus und laden Sie nginx anschließend neu. Bei Apache mit mod_php lautet die entsprechende Korrektur sudo a2dismod php8.3. Führen Sie danach sudo a2enmod php8.5 aus und starten Sie Apache neu.