Ubuntu 24.04 auf 26.04 aktualisieren: Anleitung für VPS

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 das Point-Release 26.04.1 veröffentlicht wurde. Dies ist für den 27. August 2026 geplant. Bis dahin wird ein Server mit 24.04 die neue Version absichtlich nicht erkennen. Ubuntu 26.04 LTS (Resolute Raccoon) wurde am 23. April 2026 veröffentlicht. Canonical öffnet den Upgrade-Pfad von LTS zu LTS jedoch erst mit dem ersten Point-Release. Dieses enthält die Installations- und Upgrade-Fehler, die in den ersten Monaten gefunden wurden.

Führen Sie die Prüfung Anfang August 2026 auf einem Server mit 24.04 aus. Dann 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 auf Ubuntu Server Prompt=lts. Das bedeutet, dass das Tool nur das nächste Long-Term-Support-Release anbietet, und auch erst, sobald dessen .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. Belassen Sie die Einstellung auf lts und warten Sie. Die Termine im Zeitplan von Canonical können sich verschieben. Prüfen Sie die Verfügbarkeit erneut, wenn der genannte Tag ohne Änderung verstreicht.

Jeden folgenden Befehl führen Sie selbst auf Ihrem eigenen Server in der angegebenen Reihenfolge aus. Ein Release-Upgrade kann auf dem Server, den Sie aktualisieren, nicht testweise durchgeführt werden. Es ersetzt den Kernel und die C-Bibliothek. Außerdem ist ein Reboot erforderlich, um den Vorgang abzuschließen.

Sollten Sie überhaupt aktualisieren?

Ubuntu 24.04 erhält bis 2029 reguläre Sicherheitsupdates. Ein funktionierender Produktionsserver steht daher nicht unter 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 Kernel 7.0. „Die Versionsnummer 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 die Konsole Ihres Providers (VNC oder seriell) noch nie geöffnet und sich darüber angemeldet. Diese Konsole ist der einzige Weg zurück auf den Server, wenn SSH ausfällt. Wenn Sie erst während einer Aussperrung feststellen, dass sie nicht funktioniert, ist es zu spät.
• Sie können sich eine Stunde Ausfallzeit nicht leisten und haben keine Möglichkeit zum Rollback.
• Ihre Umgebung 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 von Hand eingerichtet, und niemand weiß, was darauf installiert ist.

Oft ist die Alternative besser: Erstellen Sie einen neuen 26.04-VPS, installieren Sie Ihre Umgebung und stellen Sie die Daten wieder her. Wechseln Sie anschließend den DNS, sobald der neue Server korrekt antwortet. Der alte Server bleibt in Betrieb, bis sich der neue bewährt hat. Ein Rollback besteht dann aus einer DNS-Änderung statt aus einer Wiederherstellung. Wenn Sie diesen Weg wählen, beginnen Sie mit den ersten zehn Minuten auf einem neuen VPS und richten Sie den neuen Server ordnungsgemäß ein.

Schritt 1: Erstellen Sie ein Backup, aus dem Sie wiederherstellen können

Verwenden Sie zwei Ebenen, weil sie auf unterschiedliche Weise ausfallen. Ein Snapshot des Providers 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 liefert einzelne Dateien und eine Kopie, die auch dann erhalten bleibt, wenn Ihr Konto gesperrt wird.

Erstellen Sie zuerst manuell Dumps 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. MyISAM-Tabellen erfordern eine angehaltene Datenbank. Das /etc-Tarball werden Sie tatsächlich benötigen, weil es alle Konfigurationsdateien enthält, zu denen das Upgrade gleich Fragen stellen wird.

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

Schritt 2: 24.04 zunächst vollständig aktualisieren

do-release-upgrade wird auf einem System mit einem fehlerhaften Paketstatus nicht ausgeführt. Ein unvollständig aktualisiertes 24.04 erschwert die Analyse 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 teilweise konfiguriert. Wenn apt-mark showhold keine Ausgabe erzeugt, ist kein Paket auf eine Version festgelegt, die das Upgrade blockieren würde. 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 absichtlich gesetzt wurde, und an dieser Stelle 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 selbst ausgeht, dass er aktiv ist.

[ -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, wird es mit einer Meldung abgebrochen, die das betroffene Dateisystem nennt.

df -h / /boot

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

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

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

do-release-upgrade deaktiviert jede apt-Quelle, die nicht zu Ubuntu gehört, weil ein für noble erstelltes Paket ein resolute-System beschädigen kann. Erkannte Quellen werden anschließend wieder aktiviert. Alle übrigen Quellen bleiben auskommentiert. Prüfen Sie, welche Quellen und Pakete vorhanden sind, 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 sowie deb822-.sources-Dateien mit den Feldern Types: und Suites:. Beide Formate werden durch das Upgrade deaktiviert. ubuntu-security-status --thirdparty listet die installierten Pakete auf, für die kein Ubuntu-Archiv ein Paket bereitstellt. Das ist die tatsächliche Anzahl der zusätzlich installierten Pakete. Jeder Eintrag in /etc/apt/preferences.d/ ist eine Paketpriorisierung. Eine für noble geschriebene Paketpriorisierung wählt auf dem neuen Release weiterhin ein altes Paket aus.

Prüfen Sie für jedes Drittanbieter-Repository, ob der Anbieter vor Beginn des Upgrades 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 dieselbe Verzeichnisstruktur 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 eine passende Version veröffentlicht. Wenn Sie den Codenamen auf einen vom Anbieter unterstützten Wert ändern, 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 ausgeführt wird, empfängt der Prozess SIGHUP und beendet sich während des Entpackens. Dadurch bleibt dpkg teilweise konfiguriert. Außerdem kann der Server anschließend über keinen funktionierenden Netzwerk-Stack mehr verfügen, über den Sie erneut eine Verbindung herstellen können. Führen Sie den Prozess stattdessen in einem Terminal-Multiplexer aus. Dadurch bleibt er auf dem Server aktiv, wenn die Clientverbindung abbricht.

sudo apt install -y tmux
tmux new -s upgrade

Innerhalb dieser Sitzung:

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. Ein ungefragtes Öffnen einer Firewall 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. Beachten Sie, dass Ihr Provider möglicherweise eine zweite Firewall in seinem Control Panel betreibt, die außerhalb des Servers liegt.

Wenn die Verbindung trotzdem abbricht, melden Sie sich erneut an und führen Sie tmux attach -t upgrade aus. Das Upgrade lief während Ihrer Abwesenheit weiter.

Schritt 5: Beantworten Sie die Abfragen zu Konfigurationsdateien bewusst

dpkg fragt nur nach Dateien, die Sie oder ein Skript geändert haben. Jede Abfrage betrifft daher eine Datei, die Sie absichtlich bearbeitet haben. Wenn Sie einfach die Eingabetaste drücken, damit die Abfrage 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 anschließend Ihre Version mit N. Die Standardauswahl ist bereits N und damit die sichere Antwort, weil Ihre Datei heute funktioniert und die bereitgestellte Datei auf diesem Rechner noch nie ausgeführt wurde.

Wenn Sie Ihre Datei behalten, erhalten Sie 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 aufgelistet wird, ist die Version des Paketbetreuers und wird 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 setzt.

Das Upgrade fragt über needrestart außerdem, welche Dienste neu gestartet werden sollen. Akzeptieren Sie die vollständige Liste. Ein Daemon, der weiterhin eine gemeinsam genutzte Bibliotheksdatei verwendet, die von der Festplatte gelöscht wurde, stürzt bei einer späteren Anfrage ab – möglicherweise zu einem Zeitpunkt, an dem Sie den Dienst nicht überwachen.

Schritt 6: Starten Sie das System neu und prüfen Sie den Rechner

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 dennoch aufgelistete Unit ist Ihre nächste Aufgabe. Das abschließende 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 liefert PostgreSQL 16 aus, Ubuntu 26.04 PostgreSQL 18. Das Upgrade installiert Version 18 neben Version 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. Version 16 behält Port 5432 mit allen Ihren Daten, während Version 18 leer auf Port 5433 läuft. Ihre Anwendung kommuniziert weiterhin mit Port 5432, und zunächst sieht alles korrekt aus. Deshalb wird das Problem oft erst Monate später entdeckt.

pg_lsclusters

Wenn zwei Cluster aufgelistet sind, wurde noch keine Migration 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 Cluster von Version 18, da pg_upgradecluster nicht in einen bereits vorhandenen Ziel-Cluster schreibt. Die Standardmethode erstellt einen Dump von Version 16 und lädt ihn in Version 18 ein. Dafür benötigen Sie freien Speicherplatz von ungefähr der Größe der Datenbank. -m upgrade verwendet stattdessen pg_upgrade und ist bei großen Datenbanken 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-Durchlauf selbst aus, da 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 erst danach den alten Cluster:

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 zum Ausfall von Servern.

Erstens startet mysqld nicht, wenn die Konfiguration eine Option enthält, die in der neuen Version entfernt wurde. default_authentication_plugin ist dabei häufig die Ursache, weil viele ältere Anleitungen empfehlen, diese Option zu setzen. Der Dienst schlägt fehl, und journalctl -u mysql -n 50 nennt die unbekannte Variable direkt. Löschen Sie diese Zeile aus der Datei unter /etc/mysql/mysql.conf.d/ und 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 MySQL 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 Passwort 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 unterstützen, können Sie das alte Plugin in 8.4 wieder aktivieren. Fügen Sie dazu mysql_native_password=ON unter [mysqld] hinzu. Verwenden Sie dies nur 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 versionsabhängige Pfade installiert, und Ihre Webserver-Konfiguration wird nicht automatisch angepasst. Ein nginx-vhost mit fastcgi_pass unix:/run/php/php8.3-fpm.sock; verweist nun auf einen Socket, den kein Prozess erstellt. Jede PHP-Anfrage liefert daher 502, und das nginx-Fehlerprotokoll 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 äußert sich das Problem 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 den Server anhand von einem LAMP-Stack auf Ubuntu 24.04 eingerichtet haben, sollten Sie beide Pfade prüfen. Die Anleitung hinterlässt einen versionsabhängigen Modulnamen und einen versionsabhängigen Socket.

Auch Ihre php.ini-Optimierung 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 als php8.3-redis installierte Erweiterung benötigt das Paket php8.5-. Wenn sie aus einem PPA stammt, hat das Upgrade diese Quelle deaktiviert, und die Erweiterung fehlt schlicht.

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

SSH: Der Fehler, der die aktuelle Sitzung beendet

Die Eingabeaufforderung sshd_config ist die Stelle, an der sich Benutzer aussperren. Die Eingabe von Y installiert die Datei des Paketbetreuers. Dadurch werden Ihre 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 Port 22 lauscht, wird die nächste Verbindung abgewiesen. Die aktuelle Sitzung ist dann die letzte, die Ihnen zur Verfügung steht.

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 folgenden Werten. Verschieben Sie Ihre Einstellungen in eine Datei, die dpkg nicht verwaltet:

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 eigene Konfiguration mehr befindet, ist diese Eingabeaufforderung unkritisch. Beide Antworten behalten Ihre Einstellungen bei, weil diese in einer anderen Datei gespeichert sind.

Ein benutzerdefinierter Port erfordert eine weitere Prüfung, weil die Einstellung möglicherweise nicht dort steht, wo Sie sie erwarten:

systemctl is-enabled ssh.socket

Wenn dort enabled ausgegeben wird, verwaltet systemd den Listening-Port. Die Zeile Port in sshd_config wird dann ignoriert. Ubuntu verwendet für sshd seit 22.10 die Socket-Aktivierung. Deshalb scheint eine Änderung in Port 2222 wirkungslos zu sein. Setzen Sie den Port stattdessen in 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 die zweite funktioniert. SSH auf einem VPS härten beschreibt die Einstellungen, die in diesem Drop-in sinnvoll sind.

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 sollten Sie den Konsolenzugriff vor einem Upgrade testen und nicht erst währenddessen.

FAQ

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

Weil /etc/update-manager/release-upgrades auf Ubuntu Server Prompt=lts enthält. Diese Einstellung bietet die nächste Long-Term-Support-Version erst an, sobald deren erste Point-Release-Version verfügbar ist. Ubuntu 26.04 LTS wurde am 23. April 2026 veröffentlicht, und 26.04.1 ist für den 27. August 2026 geplant. Bis dahin erkennt ein 24.04-Server keine neue Version. Lassen Sie die Einstellung unverändert, statt auf Prompt=normal umzuschalten. Dadurch 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 diese neuen Komponenten erst nach einem Neustart. do-release-upgrade fordert am Ende zu einem Neustart auf. Ein System, das bis „später“ weiterläuft, verwendet dann eine Mischung aus zwei Versionen. Prüfen Sie nach dem Neustart uname -r auf den neuen Kernel und systemctl --failed auf Dienste, die nicht gestartet wurden.

Sollte ich das Upgrade direkt 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 Software-Stack installieren, die Daten wiederherstellen und alles testen, während der alte Server weiterhin Netzwerkverkehr bedient. Ein Rollback besteht dann aus einer DNS-Änderung und nicht aus einer Wiederherstellung aus dem Backup. Führen Sie das Upgrade direkt durch, wenn der Server einen schwer übertragbaren Zustand enthält, der Provider pro Maschine abrechnet oder ein Snapshot und nachweislicher Konsolenzugriff vorhanden sind. Der direkte Upgrade-Pfad ist gut erprobt. Für die Dauer des Upgrades ist er jedoch unumkehrbar.

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

In einer normalen 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 erneut herstellen und mit tmux attach -t upgrade fortfahren. Das Upgrade-Programm startet zusätzlich einen Ersatz-SSH-Daemon auf Port 1022. Es öffnet die Firewall jedoch nicht für diesen Port. Erlauben Sie Port 1022 daher vorher selbst und schließen Sie ihn anschließend wieder.

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

Der Pfad zum PHP-FPM-Socket hat sich mit der Version geändert. Ubuntu 24.04 verwendet PHP 8.3, Ubuntu 26.04 dagegen PHP 8.5. Daher ist /run/php/php8.3-fpm.sock nicht mehr vorhanden, während Ihre nginx-vhost-Konfiguration 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 besteht die entsprechende Korrektur aus sudo a2dismod php8.3, gefolgt von sudo a2enmod php8.5 und einem Neustart.