SSD Nodes Learn Hosting plans →
Anleitungen Matt ConnorVon Matt Connor · Aktualisiert 2026-08-25

Ubuntu LTS oder Interim-Release für Server?

Ubuntu Interim-Releases bieten 9 Monate Support und erfordern dann ein Upgrade. LTS-Versionen erhalten 5 Jahre Sicherheitsupdates. Das kostet Sie im Serverbetrieb.

Ubuntu LTS vs. Interim-Releases: die kurze Antwort

Die Entscheidung zwischen einem Ubuntu LTS und einem Interim-Release auf einem Server hängt von einer Zahl ab: Wie lange erhält dieses Release Sicherheitsupdates? Ein LTS erhält fünf Jahre lang standardmäßige Sicherheitswartung. Ein Interim-Release erhält neun Monate lang Updates. Danach werden die Updates eingestellt, und Sie müssen ein Upgrade durchführen oder das System neu aufbauen. Verwenden Sie ein LTS für alles, wovon andere Personen abhängig sind. Verwenden Sie ein Interim-Release nur dort, wo Sie das System neu aufbauen können, ohne jemanden fragen zu müssen.

LTS steht für Long Term Support. Canonical veröffentlicht alle zwei Jahre im April eines geraden Jahres ein LTS und dazwischen alle sechs Monate ein Interim-Release. 26.04 LTS wurde am 23. April 2026 veröffentlicht. Die standardmäßige Sicherheitswartung läuft bis 2031. 26.10 soll am 15. Oktober 2026 veröffentlicht werden. Es ist ein Interim-Release, daher endet der Support im Juli 2027.

Wie lange jede Ubuntu-Version unterstützt wird

ChartSupport length and release upgrades needed over five years
The data behind this chart
[
  {
    "label": "LTS, standard support",
    "support_months": 60,
    "upgrades_over_5_years": 1
  },
  {
    "label": "LTS with Ubuntu Pro",
    "support_months": 120,
    "upgrades_over_5_years": 0
  },
  {
    "label": "Interim release",
    "support_months": 9,
    "upgrades_over_5_years": 10
  }
]

Das sind die von Canonical veröffentlichten Richtwerte mit Stand August 2026, keine Messwerte von einem Testsystem. Eine LTS-Version erhält 60 Monate reguläre Sicherheitswartung. Das entspricht 1 geplanten Release-Upgrades in fünf Jahren. Eine Zwischenversion wird 9 Monate unterstützt. Wer in diesen fünf Jahren bei Zwischenversionen bleibt, muss 10 Release-Upgrades durchführen, weil keine Version übersprungen werden kann und fünf Jahre zehn Versionen umfassen.

Ein Ubuntu-Pro-Abonnement erhöht den Wert für LTS-Versionen auf 120 Monate beziehungsweise zehn Jahre. Außerdem wird die Abdeckung von der main-Komponente auf das gesamte Archiv erweitert. Mit Stand August 2026 ist Pro für die private Nutzung auf bis zu fünf Rechnern kostenlos. Das deckt die meisten kleinen VPS-Flotten ab. Für eine Zwischenversion gibt es keine entsprechende Option. Die Unterstützung beträgt vollständig neun Monate. Kein Abonnement verlängert diesen Zeitraum.

Was neun Monate auf einem echten Server kosten

Nehmen wir 26.10 als Beispiel. Diese Version wird am 15. Oktober 2026 veröffentlicht. Ihre Sicherheitswartung endet im Juli 2027. Das entspricht demselben Muster von neun Monaten, das bei 25.10 im Juli 2026 endete. Im Kalender sieht das nach einem Wartungsfenster alle drei Quartale aus. Diese Betrachtung ist falsch, und zwar in kostspieliger Hinsicht.

Die Fristenkette am konkreten Beispiel

Installieren Sie 26.10 im Oktober 2026 und warten Sie bis zum letztmöglichen sicheren Zeitpunkt. Sie aktualisieren im Juni 2027 auf 27.04, kurz bevor 26.10 ausläuft. 27.04 wurde jedoch im April 2027 veröffentlicht, und die eigenen neun Monate dieser Version enden im Januar 2028. Ihre zweite Frist kommt sieben Monate nach der ersten, nicht nach neun.

Aktualisieren Sie im Dezember 2027 erneut auf 27.10. Diese Version wurde im Oktober 2027 veröffentlicht und endet im Juli 2028. Ab diesem Punkt ist das Muster festgelegt. Sie liegen immer eine Version hinter der aktuellen Version. Deshalb fällt etwa alle sechs Monate eine Frist an. Neun Monate sind die Supportdauer einer einzelnen Version. Dieser Zeitraum entspricht nicht dem Abstand zwischen Ihren Wartungsfenstern.

Ein Versionsupgrade ersetzt das Betriebssystem direkt auf dem vorhandenen System. do-release-upgrade schreibt die apt-Quellen neu, deaktiviert Drittanbieter-Repositorys, ändert die Version fast jedes installierten Pakets, fragt nach Konfigurationsdateien, die Sie bearbeitet haben, und führt am Ende einen Reboot durch. Deshalb ist es ein geplantes Wartungsfenster und kein Hintergrundprozess.

Wenn Sie das Upgrade über ssh ausführen, schützt Sie das Werkzeug vor einem Abbruch Ihrer eigenen Verbindung. Es startet eine eigene screen-Sitzung und öffnet einen zweiten sshd. Zuvor weist es 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.

Lassen Sie dies zu. Wenn Ihre Firewall oder die separate Netzwerk-Firewall Ihres Providers Port 1022 blockiert, steht dieser Fallback nicht zur Verfügung. Ein anschließender Verbindungsabbruch hinterlässt dann einen teilweise aktualisierten Paketsatz. Wenn Sie selbst innerhalb von tmux oder screen arbeiten, erhalten Sie auf jedem System denselben Schutz.

Die Abfragen zu Konfigurationsdateien verwandeln ein Upgrade von fünfzehn Minuten in eine Stunde:

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 ?

Wenn Sie Ihre Datei beibehalten, entgehen Ihnen alle Änderungen an den neuen Standardeinstellungen. Wenn Sie die Datei des Paketbetreuers übernehmen, ist Ihre Härtung so lange verloren, bis Sie sie erneut eintragen. Ohne Kenntnis der Änderungen in dieser Version ist keine der beiden Antworten sicher. Deshalb gehört das Lesen der Release Notes zum Wartungsfenster und ist keine optionale Vorbereitung.

Rechnen Sie das anschließend auf mehrere Systeme hoch. Ein VPS im Interim-Track erfordert in fünf Jahren zehn Upgrade-Fenster. Bei fünf VPS-Systemen sind es fünfzig, sofern nicht jedes System wegwerfbar ist und aus einem Image neu erstellt wird. Fünf Systeme im LTS-Track erfordern im selben Zeitraum fünf Upgrades, und Sie wählen den Monat für jedes einzelne Upgrade selbst.

Warum Sie keine Ubuntu-Version überspringen können

Die Upgrade-Pfade sind festgelegt. Ein Interim-Release wird auf das nächste Release aktualisiert, unabhängig davon, welches das ist. Ein LTS wird direkt auf das nächste LTS aktualisiert oder auf das nächste Interim-Release, wenn Sie dies anfordern. Kein Upgrade überspringt zwei Versionen. Um von 26.10 auf 28.04 LTS zu gelangen, müssen Sie 27.04 und 27.10 durchlaufen oder den Rechner neu installieren.

Der Mechanismus ist wichtig, weil er zeigt, dass diese Regel nicht umgangen werden kann. do-release-upgrade ruft eine Meta-Release-Datei von changelogs.ubuntu.com ab und lädt anschließend ein Upgrade-Tool herunter, das für genau einen Übergang erstellt wurde. Canonical erstellt und testet jeweils nur einen Übergang. Für ein Upgrade, das ein Release überspringt, gibt es daher weder ein Tool noch Tests. Der Upgrader verweigert das Upgrade nicht aus Vorsicht. Es gibt schlicht kein passendes Upgrade-Angebot.

Welche Version Ihnen angeboten wird, ergibt sich aus einer Konfigurationszeile:

grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c

Prompt=lts bietet nur das nächste LTS an. Prompt=normal bietet das nächste Release an, unabhängig davon, ob es ein LTS ist. Prompt=never bietet nichts an. Damit verhindern Sie, dass ein hilfsbereiter Kollege ein nicht geplantes Upgrade startet. Bei einem Release, das kein LTS ist, verhält sich lts genau wie normal, weil auf 26.10 unter beiden Einstellungen 27.04 folgt. Die Prüfung gibt Checking for a new Ubuntu release aus und anschließend entweder eine Zeile mit New release ... available. oder No new release found.

Eine weitere Regel für die Planung führt häufig zu Missverständnissen. Ein Upgrade von einem LTS auf das nächste LTS wird nicht am Tag der Veröffentlichung des neuen LTS angeboten. Es wird mit dem ersten Point-Release freigeschaltet. Für 26.04.1 ist der 27. August 2026 geplant. Ein Point-Release ist keine neue Ubuntu-Version, sondern dasselbe Release mit vier Monaten kumulierter Fehlerkorrekturen, die in neue Installationsmedien integriert wurden. Die Wartezeit stellt sicher, dass der Upgrade-Pfad vor dem Angebot vier Monate lang getestet werden konnte. Ein 24.04-System mit Prompt=lts, das im Sommer 2026 mit No new release found. antwortete, war nicht defekt. Es folgte der vorgesehenen Richtlinie. Sobald der Pfad freigeschaltet ist, ist das Upgrade von 24.04 auf 26.04 LTS der Durchlauf, den Sie planen und testen sollten.

Wann die Wahl einer Zwischenversion sinnvoll ist

In vier Fällen ist sie tatsächlich die bessere Wahl:

  • Sie benötigen auf diesem Rechner sofort eine Kernel- oder Userspace-Version, die das LTS-Archiv nicht enthält.
  • Der Rechner ist ein Build-Host, ein CI-Runner oder ein Testsystem, das Sie aus einem Image neu erstellen. Ein Upgrade bedeutet dann eine neue Instanz statt eines Wartungsfensters.
  • Eine Hardware- oder Hypervisor-Funktion wurde erst nach dem Einfrieren der LTS-Version eingeführt, und es gibt keinen Backport.
  • Sie prüfen, was die nächste LTS-Version enthalten wird. 28.04 wird aus 26.10, 27.04 und 27.10 zusammengestellt. Eine inkompatible Änderung auf einem unkritischen VPS zu finden, ist weniger problematisch, als sie auf dem wichtigen Rechner zu entdecken.

Die meisten Anwender, die zu einer Zwischenversion greifen, benötigen ein neueres Paket und keine neuere Distribution. Dafür gibt es zwei kostengünstigere Lösungen. Der Hardware-Enablement-Stack bringt Kernel aus späteren Versionen in eine LTS-Version. Unter 24.04 ist das sudo apt install linux-generic-hwe-24.04. Bei jedem Point Release wird er aktualisiert, beginnend mit dem zweiten. Für eine einzelne Anwendung aktualisieren Sie stattdessen ein Element über ein Container-Image oder das Repository des Anbieters, nicht das gesamte Betriebssystem.

Wenn eine Zwischenversion die falsche Wahl ist

  • Alles mit zahlenden Benutzern oder einer Rufbereitschaft. Sie akzeptieren zweimal pro Jahr ein verpflichtendes Upgrade und erhalten dafür Paketversionen, die Sie möglicherweise nie verwenden.
  • Jeder Server, auf dem unattended-upgrades Ihre Sicherheitsupdates übernimmt. Diese Automatisierung ist nur so zuverlässig wie die Security-Pocket, aus der sie die Pakete abruft.
  • Eine Serverflotte, die Sie manuell aktualisieren, weil sich der tatsächliche Aufwand aus einem Wartungsfenster multipliziert mit der Anzahl der Server ergibt.
  • Alles, was Sie installieren und anschließend ein Jahr lang nicht prüfen. Eine vergessene Zwischenversion bedeutet neun Monate später einen ungepatchten, aus dem Internet erreichbaren Server.

Dieser letzte Fehler bleibt unbemerkt. Genau das macht ihn gefährlich. Wenn eine Version ihr End of Life erreicht, werden ihre Pakete nach old-releases.ubuntu.com verschoben. Dadurch schlägt sudo apt update mit 404-Fehlern gegen archive.ubuntu.com fehl. Die auf dem Datenträger gespeicherten Paketlisten veralten. unattended-upgrades läuft weiterhin nach seinem Zeitplan und schreibt weiterhin Zeilen wie diese in /var/log/unattended-upgrades/unattended-upgrades.log:

No packages found that can be upgraded unattended and no pending auto-removals

Diese Zeile sieht auf einem vollständig gepatchten Server genauso aus wie auf einem Server, dessen Version vor vier Monaten das End of Life erreicht hat. Wenn niemand die apt-Fehler liest oder das End-of-Life-Datum nachverfolgt, gibt es auf dem System keinen Hinweis darauf, welcher der beiden Fälle vorliegt.

Die Art von Änderung, die zuerst in den Interim-Track gelangt

Im März 2026 schlug ein Canonical-Entwickler im Ubuntu Discourse vor, den signierten GRUB-Bootloader, der in 26.10 für Secure Boot ausgeliefert wird, zu reduzieren. Der Vorschlag entfernt die Dateisystemtreiber für btrfs, hfsplus, xfs und zfs, die JPEG- und PNG-Bildparser, Apple-Partitionstabellen, /boot auf LVM, Software-RAID außer RAID 1 sowie ein LUKS-verschlüsseltes /boot. Als Grund wird genannt, dass Parser innerhalb eines Bootloaders wiederkehrend Sicherheitsfehler verursachen und dass die Speicher- und Verschlüsselungslogik in die initramfs gehört, also in das kleine anfängliche RAM-Dateisystem, das der Kernel vor dem eigentlichen root-Dateisystem einhängt. Im August 2026 handelt es sich dabei um einen diskutierten Vorschlag, nicht um eine ausgelieferte Änderung.

Für die meisten VPS-Instanzen würde sich dadurch nichts ändern, weil sie ohne Secure Boot von einem einfachen ext4-/boot auf einer GPT-Partitionstabelle booten. Prüfen Sie Ihre Konfiguration, statt dies anzunehmen. Wenn Ihr root-Dateisystem ZFS ist oder /boot auf btrfs oder innerhalb von LUKS liegt, ist dies genau die Art von Änderung, die Sie zuerst im Interim-Track erreicht. Der eigene Rat des Threads an betroffene Benutzer lautet, bei einer LTS-Version zu bleiben. Dieser Rat fasst das gesamte Argument in einem Satz zusammen. In Interim-Versionen werden Änderungen erprobt. In einer LTS-Version kommen sie an, nachdem zwei Jahre mit Interim-Versionen gezeigt haben, was sie beschädigen.

Dasselbe Muster zeigt sich bei jeder Interim-Version in kleinerem Umfang. Die Standardversionen der Datenbank, der Sprachlaufzeit und der init-Konfiguration werden aktualisiert, sodass zuvor funktionierende Konfigurationsdateien nicht mehr funktionieren können. Die Standardwerte weiterzuentwickeln, ist der Zweck einer Interim-Version. Daher gehört es zum Preis, dem Sie zugestimmt haben, vor jedem dieser zehn Upgrades die Release Notes zu lesen.

Auswahl des Tracks beim Erstellen des Servers

Wählen Sie den Track bereits bei der Installation aus. Eine spätere Änderung erfordert eine Neuinstallation oder eine Kette von Upgrades. Auf einem neuen Server zeigen Ihnen vier Befehle, wo Sie stehen:

lsb_release -a
grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c
pro security-status

lsb_release -a sollte den Release angeben, den Sie installieren wollten. Bei einem LTS endet die Beschreibung mit LTS. Die Zeile Prompt sollte dem ausgewählten Track entsprechen und nicht dem Track, mit dem das Image des Providers zufällig ausgeliefert wurde. do-release-upgrade -c sollte bei einem aktuellen LTS mit No new release found. antworten. Wenn stattdessen ein Interim-Release angeboten wird, ist Prompt auf normal gesetzt. Dann sollte jemand prüfen, ob dies beabsichtigt war. pro security-status zeigt, wie viele installierte Pakete von welchem Update-Stream abgedeckt werden, und weist ausdrücklich darauf hin, wenn der Server nicht mit einem Abonnement verknüpft ist.

Notieren Sie anschließend das End-of-Life-Datum an einer Stelle, an der Sie es wieder sehen, zusammen mit den übrigen Build-Notizen für diesen Server. Das gehört zu den anderen Arbeiten in den ersten zehn Minuten auf einem neuen VPS, denn ein Supportdatum, das nur im Gedächtnis einer Person existiert, läuft unbemerkt ab. Wenn Sie den halbjährlichen Wechsel vollständig vermeiden möchten, lohnt sich das FreeBSD-Releasemodell im Vergleich zu Linux vor der Entscheidung, eine gesamte Serverflotte auf eines der beiden Modelle festzulegen, mindestens eine Stunde Lektüre.

FAQ

Sollte ich eine Ubuntu-Interim-Version auf einem Produktionsserver einsetzen?

In fast allen Fällen: nein. Eine Interim-Version erhält neun Monate nach ihrem Release keine Security-Updates mehr. Der Produktionseinsatz auf diesem Release-Zweig bedeutet daher dauerhaft ein verpflichtendes Upgrade-Fenster etwa zweimal pro Jahr. Eine sinnvolle Ausnahme sind Systeme, die ohnehin aus einem Image neu erstellt werden, etwa CI-Runner und Build-Hosts. Dort ist ein Upgrade eine neue Instanz und kein Wartungsfenster. Wenn echte Benutzer auf den Server angewiesen sind, installieren Sie die LTS-Version und nutzen Sie die eingesparten Wartungsfenster für andere Aufgaben.

Wie lange wird eine Ubuntu-Interim-Version unterstützt?

Neun Monate. 26.10 wird am 15. Oktober 2026 veröffentlicht. Die Security Maintenance endet im Juli 2027, entsprechend dem Ende von 25.10 im Juli 2026. Das gilt für jede Interim-Version: Sie wird im April oder Oktober veröffentlicht und endet neun Monate später. Eine LTS-Version erhält fünf Jahre Standard-Security-Maintenance. Mit Ubuntu Pro verlängert sich dieser Zeitraum auf zehn Jahre. Seit August 2026 ist Ubuntu Pro für die private Nutzung auf bis zu fünf Systemen kostenlos.

Kann ich Ubuntu-Releases beim Upgrade überspringen?

Nein. do-release-upgrade führt jeweils nur einen Schritt aus: Eine Interim-Version wird auf das nächste Release aktualisiert. Eine LTS-Version kann direkt auf die nächste LTS-Version aktualisiert werden. Für den Wechsel von 26.10 auf 28.04 LTS müssen Sie das Upgrade zuerst auf 27.04 und anschließend auf 27.10 durchführen oder das System neu installieren. Canonical erstellt und testet jeweils nur einen Übergang. Das Upgrade-Programm lädt ein Werkzeug für genau diesen Wechsel herunter. Für einen Sprung über zwei Releases gibt es kein entsprechendes Werkzeug. Deshalb wird er nie angeboten.

Was passiert, wenn meine Ubuntu-Version das Ende ihrer Lebensdauer erreicht?

Die Pakete werden nach old-releases.ubuntu.com verschoben. Daher schlägt sudo apt update bei Anfragen an archive.ubuntu.com mit 404-Fehlern fehl. Für diese Version werden dann überhaupt keine neuen Security-Updates mehr veröffentlicht. Das System weist nicht darauf hin. Der Server läuft weiter und verarbeitet weiterhin Netzwerkverkehr, während jede neu veröffentlichte Schwachstelle darin offen bleibt. Die Wiederherstellung besteht aus einem Release-Upgrade unter Zeitdruck oder einer Neuinstallation. Prüfen Sie daher das Datum und warten Sie nicht auf Symptome.

Ist der LTS-Kernel zu alt für neue Hardware?

Normalerweise nicht, weil eine LTS-Version ihren ursprünglichen Kernel nicht fünf Jahre lang unverändert verwendet. Der Hardware Enablement Stack, HWE, bringt Kernel aus späteren Releases über Point-Releases in die LTS-Version. Eine Serverinstallation kann ihn mit einem Paket wie linux-generic-hwe-24.04 aktivieren. Prüfen Sie mit uname -r, welcher Kernel ausgeführt wird, bevor Sie ihn als Ursache annehmen. Wenn die fehlende Funktion eine Userspace-Version und kein Kernel-Feature betrifft, ist ein Container oder ein Hersteller-Repository eine wesentlich kleinere Änderung, als das gesamte System auf den Interim-Zweig umzustellen.