Ubuntu LTS vs normal: Welche Version gehört 2026 auf deinen Server?

Ubuntu LTS vs normal ist keine Geschmacksfrage, sondern eine Rechnung mit zwei Variablen: Wie lange bekommst du Sicherheitsupdates, und wie oft musst du dafür das gesamte System austauschen? Die übliche Antwort lautet „LTS ist stabiler, normal ist aktueller”. Wir haben das 2026 nachgemessen — an den Paketarchiven von Canonical, an laufenden Containern und an den Signaturen der Sicherheits-Repositories. Ein Teil der üblichen Antwort stimmt. Der wichtigere Teil ist falsch.

Der Befund, der uns am meisten überrascht hat: Ein Ubuntu-Zwischenrelease, das seit acht Monaten tot ist, meldet bei apt update und apt upgrade keinerlei Fehler. Es lädt Paketlisten, meldet Aktualisierungen, installiert sie und beendet sich mit Exit-Code 0. Nichts an diesem Ablauf verrät, dass die Sicherheitsquelle dahinter seit 243 Tagen nicht mehr angefasst wurde.

Ubuntu LTS vs normal: die kurze Antwort

Falls du keine 24 Minuten hast:

• Server, egal welcher Art: LTS. Ohne Ausnahme, und die Begründung unten ist härter als die übliche.
• Entwickler-Desktop mit Bedarf an frischen Toolchains: Interim ist vertretbar, wenn du die Upgrade-Disziplin wirklich durchhältst.
• Alles, was du nicht alle sechs Monate anfassen willst: LTS.
• „Ich nehme das Zwischenrelease wegen des neueren Kernels”: Dieses Argument ist ab Seite 2 dieses Artikels tot. Der LTS-Kernel ist heute neuer.

Was „LTS” und „normal” bei Ubuntu technisch bedeuten

Ubuntu veröffentlicht seit 2004 im Halbjahrestakt: April und Oktober, daher die Versionsnummern JJ.MM. Jedes zweite Jahr im April erscheint ein LTS-Release (Long Term Support). Alle anderen sind Interim-Releases — im Deutschen meist „Zwischenrelease” oder schlicht „normale Version”.

Die Versionsnummer allein verrät die Kategorie: Gerade Jahreszahl plus .04 bedeutet LTS (24.04, 26.04), alles andere ist ein Interim (25.04, 25.10). Der Zusatz LTS steht zusätzlich im Namen.

Wir haben die tatsächlichen Support-Zeiträume aus dem Release-Kalender ausgelesen und ausgerechnet, statt die Marketingzahlen zu übernehmen:

Methodik: Release- und EOL-Daten aus dem maschinenlesbaren Ubuntu-Release-Kalender (endoflife.date-API, gegengeprüft gegen changelogs.ubuntu.com/meta-release), abgerufen am 20.09.2026. Berechnet wurde die Differenz in Tagen zwischen releaseDate und eol.

Die Spannweite bei den Interim-Releases hat einen historischen Grund, den fast keine Übersicht erwähnt: Bis einschließlich 12.10 bekamen Zwischenreleases 18 Monate Support. Erst ab 13.04 wurde auf neun Monate verkürzt. Wer eine ältere Anleitung liest, liest also möglicherweise eine Regel, die seit 2013 nicht mehr gilt. In der modernen Ära (ab 13.04, 21 Releases) liegt der Median bei exakt 9,0 Monaten.

Bei den LTS-Releases fällt ein Ausreißer auf: 10.04 bekam nur 3,03 Jahre. Damals galt die Fünf-Jahres-Zusage nur für die Server-Variante, die Desktop-Variante hatte drei Jahre. Seit 12.04 sind es einheitlich fünf.

Der Fund, der alles andere überlagert: Ubuntu stirbt lautlos

Das ist der Teil, für den wir den Artikel geschrieben haben. Wir haben drei Container gestartet — ein totes Interim, ein gerade erst totes Interim und ein lebendes LTS — und jeweils exakt die Befehle abgesetzt, die ein Admin absetzt.

Ubuntu 25.04, seit dem 17.01.2026 ohne Support, gemessen am 20.09.2026:

$ apt-get update
Get:1 http://security.ubuntu.com/ubuntu plucky-security InRelease [126 kB]
Get:2 http://archive.ubuntu.com/ubuntu plucky InRelease [265 kB]
...
Fetched 25.2 MB in 1s (21.3 MB/s)
Reading package lists...
EXITCODE=0

Kein Fehler. Keine Warnung. Kein Hinweis. Wir haben die gesamte Ausgabe anschließend nach den Wörtern expire, no longer, end of life, EOL, unsupported und warning durchsucht — kein einziger Treffer. Derselbe Test auf 25.10 und auf 24.04 LTS: ebenfalls keine Warnung, aber dort ist das Schweigen ja korrekt.

Schlimmer: Das tote System meldet sogar aufrüstbare Pakete und installiert sie brav.

Methodik: docker run --rm ubuntu:plucky|questing|noble, jeweils apt-get update gefolgt von apt-get -s upgrade und apt list --upgradable, gemessen am 20.09.2026 gegen die offiziellen Spiegel archive.ubuntu.com und security.ubuntu.com.

Das ist die gefährlichste Bauart eines Fehlers: Die Anzeige unterscheidet nicht zwischen „es gibt nichts Neues” und „hier schaut niemand mehr nach”. Beide Zustände sehen für den Admin identisch aus — ein grünes apt upgrade, das keine Pakete anbietet.

Der Beweis, dass dahinter wirklich nichts mehr passiert

„Keine Warnung” allein wäre nur eine Beobachtung über die Ausgabe. Entscheidend ist, ob die Quelle dahinter noch gepflegt wird. Jede InRelease-Datei trägt einen Zeitstempel ihrer letzten Signatur. Den haben wir bei allen relevanten Releases abgefragt:

Methodik: curl http://security.ubuntu.com/ubuntu/dists/<suite>-security/InRelease, ausgewertet wurde das Date-Feld der Signatur. Abgerufen 20.09.2026, 07:00 UTC.

Die drei unterstützten LTS-Releases wurden am selben Morgen neu signiert, innerhalb von drei Minuten. Die beiden Interim-Releases seit Monaten nicht. Das ist der Unterschied zwischen einem Repository, in das ein Sicherheitsteam schreibt, und einem eingefrorenen Verzeichnis.

Bemerkenswert und für die Praxis wichtig: Keine der InRelease-Dateien enthält ein Valid-Until-Feld. Wir haben alle fünf geprüft — null Treffer. Dieses Feld ist der Mechanismus, mit dem apt selbstständig anschlagen würde („Release file has expired”). Ohne ihn ist apt strukturell blind für das Alter seiner eigenen Quelle. Genau deshalb bleibt die Ausgabe grün.

Wie viel Sicherheitspflege hier konkret fehlt

Die Zahl der Pakete, für die es überhaupt ein Sicherheitsupdate gibt, macht den Abstand greifbar:

Methodik: Packages.xz aus <suite>-security/main/binary-amd64 heruntergeladen, entpackt und die Package-Einträge gezählt. Stand 20.09.2026.

Diese Zahlen sind kein direkter Qualitätsvergleich — ein älteres Release sammelt naturgemäß mehr Sicherheitsupdates an, weil es länger existiert. 24.04 LTS liegt nicht deshalb vorn, weil es besser gepflegt wird als 26.04 LTS, sondern weil es zweieinhalb Jahre mehr Historie hat. Die aussagekräftige Ablesung ist eine andere: Bei den beiden EOL-Releases hört die Kurve einfach auf. Ihre Zahl wächst nie wieder, egal welche Lücke morgen bekannt wird.

Wie konkret das wird, zeigt ein Blick auf einzelne Pakete im Sicherheits-Repository:

Methodik: Versionsfelder aus denselben -security-Indizes, Stand 20.09.2026.

Die interessante Stelle ist die letzte Ziffer. Bei 24.04 LTS steht openssh-server bei Revision 19 — neunzehn Sicherheitsüberarbeitungen derselben Upstream-Version. Bei 25.04 steht dieselbe Sorte Paket bei Revision 1 und wird dort für immer bleiben. Die Upstream-Version auf dem toten Interim ist neuer (9.9 gegen 9.6) — und trotzdem schlechter gepflegt. Das ist die Falle in Kurzform: „neuer” und „sicherer” sind bei Distributionen zwei verschiedene Größen.

Der Kernel: das beliebteste Argument fürs Zwischenrelease, und warum es nicht trägt

Das häufigste Argument für ein Interim-Release lautet: neuerer Kernel, besserer Hardware-Support. Beim Blick in die Erstveröffentlichung stimmt das auch:

Nur misst diese Tabelle den Zustand am Erscheinungstag — und niemand betreibt einen Server am Erscheinungstag. Die relevante Frage ist, was heute auf den Systemen installierbar ist. Dafür muss man in -updates schauen, nicht in die Erstveröffentlichung:

Methodik: Packages.xz aus <suite>-updates/main/binary-amd64 heruntergeladen und die Versionen von linux-generic sowie linux-generic-hwe-<version> ausgelesen. Stand 20.09.2026.

Das dreht das Argument komplett um. Ubuntu 24.04 LTS bekommt über den HWE-Stack (Hardware Enablement) den Kernel 7.0.0 — neuer als der Kernel 6.17, auf dem das jüngere Zwischenrelease 25.10 für immer festsitzt. Ein Kommando genügt:

sudo apt install linux-generic-hwe-24.04

Der Mechanismus dahinter: Canonical portiert die Kernel der jeweils neuesten Releases zurück in die aktuelle LTS. Die Version trägt das Suffix ~24.04.1, hier also 7.0.0-31.31~24.04.1 — derselbe Kernel-Zweig wie in 26.04 LTS, verpackt für die ältere LTS.

Damit lautet der ehrliche Satz: Ein Interim-Release verschafft dir einen neueren Kernel für einige Monate. Eine LTS mit HWE-Stack verschafft ihn dir dauerhaft — ohne dass du alle sechs Monate das gesamte System austauschst.

Wie viel frischer sind Interim-Releases wirklich?

Beim Rest der Software stimmt das Frische-Argument — zumindest am Stichtag. Wir haben die Paketindizes aller vier relevanten Releases heruntergeladen und verglichen:

Methodik: Packages.xz aus <suite>/main bzw. universe für amd64 heruntergeladen, entpackt und die Version-Felder der Erstveröffentlichung ausgelesen. Stand 20.09.2026.

Hier ist der Abstand real und teils erheblich — Node.js 18 gegen 22 sind zwei volle LTS-Generationen. Aber: Die rechte Spalte ist ebenfalls eine LTS. Die aktuelle LTS 26.04 liegt bei jedem einzelnen Paket vorn oder gleichauf mit dem jüngsten Interim. Das Frische-Argument gilt also nicht „LTS gegen Interim”, sondern nur „alte LTS gegen neues Interim” — und dieser Zustand hält maximal zwei Jahre, bis die nächste LTS erscheint.

Auch die Katalogbreite gibt wenig her:

Die aktuelle LTS hat den größten Katalog der vier. „Mehr Software im Zwischenrelease” ist als pauschale Aussage nicht haltbar.

Der Kalender, den niemand einplant: die Lücke zwischen zwei Interim-Releases

Das ist ein Fund, den wir nicht gesucht haben. Wer auf der Interim-Schiene bleiben will, braucht ein durchgehend unterstütztes Release. Wir haben deshalb für jedes moderne Zwischenrelease berechnet, ob sein Nachfolger erscheint, bevor es selbst stirbt.

Das Ergebnis: In 6 von 19 Fällen klafft eine Lücke. Beispiele:

Methodik: Differenz zwischen dem eol-Datum eines Interim-Releases im Oktober und dem releaseDate des nächsten Oktober-Releases. Der Wert für 26.10 beruht auf dem üblichen Oktober-Termin und ist als einziger eine Erwartung, keine Messung.

Das Muster ist systematisch: Jedes Oktober-Interim stirbt im Juli, sein Nachfolger kommt aber erst im Oktober. Wer strikt auf Zwischenreleases setzt, hat also alle zwei Jahre rund drei Monate ohne unterstütztes Ziel — er muss zwischendurch auf ein April-Release ausweichen oder diese Zeit ungeschützt überbrücken.

Und heute, am 20.09.2026, ist genau so ein Fenster offen. Die Messung:

• Unterstützte Interim-Releases: keine. Null.
• Unterstützte LTS-Releases: 22.04, 24.04, 26.04.

Wer heute ein Ubuntu-System neu aufsetzt, hat bei der Interim-Schiene schlicht keine unterstützte Option. Die einzige Wahl ist eine LTS — oder ein Release, das ab dem ersten Tag ohne Sicherheitsupdates läuft.

Die Upgrade-Rechnung: 0 gegen 10

Der Preis der Interim-Schiene ist nicht die Aktualität, sondern die Frequenz. Wir haben das Lebensfenster einer einzigen LTS als Maßstab genommen — Ubuntu 24.04, unterstützt vom 25.04.2024 bis zum 31.05.2029, also 1.862 Tage:

Ein do-release-upgrade ist kein apt upgrade. Es tauscht die Paketquellen, migriert Konfigurationsdateien, fragt bei jeder geänderten Datei nach, deaktiviert Drittanbieter-Repositories und will am Ende einen Neustart. Auf einem Server mit eigener nginx-Konfiguration, PHP-Pools und Datenbank ist das jedes Mal ein geplantes Wartungsfenster.

Zehnmal statt keinmal. Das ist der eigentliche Preis, und er fällt nicht dem auf, der die Entscheidung trifft, sondern dem, der zwei Jahre später den Server betreut.

do-release-upgrade: drei Schalter, die kaum jemand kennt

Beim Testen des Upgrade-Pfads sind wir auf ein Verhalten gestoßen, das in der Praxis regelmäßig für Verwirrung sorgt. Die Datei /etc/update-manager/release-upgrades enthält einen Schalter Prompt, der bestimmt, welche Ziele überhaupt angeboten werden.

Gemessen auf einem Ubuntu 24.04 LTS am 20.09.2026, während 26.04.1 LTS längst verfügbar ist:

# Prompt=lts (Standardwert auf LTS-Systemen)
$ do-release-upgrade -c
Checking for a new Ubuntu release
There is no development version of an LTS available.

# Prompt=normal
$ do-release-upgrade -c
Checking for a new Ubuntu release
New release '26.04.1 LTS' available.

# Prompt=never
$ do-release-upgrade -c
In /etc/update-manager/release-upgrades Prompt
is set to never so upgrading is not possible.

Der erste Fall ist der tückische. Mit dem Standardwert Prompt=lts meldet ein 24.04-System, es gebe nichts — obwohl eine neuere LTS bereitsteht. Die Meldung spricht von einer „development version” und klingt dadurch wie eine Entwarnung, nicht wie eine Einschränkung. Wer das liest, hält sein System für aktuell.

Der Hintergrund ist eine bewusste Entscheidung von Canonical: Das Upgrade auf eine neue LTS wird erst mit dem ersten Point-Release (.1) breit angeboten, damit die frühen Fehler bereits behoben sind. Trotzdem bleibt die Ausgabe irreführend — sie sagt nicht „noch nicht freigegeben”, sondern „nicht vorhanden”.

Auf dem toten 25.04-System hingegen funktioniert die Erkennung einwandfrei:

$ do-release-upgrade -c
Your Ubuntu release is not supported anymore.
For upgrade information, please visit:
http://www.ubuntu.com/releaseendoflife

New release '26.04.1 LTS' available.

Das ist bemerkenswert: do-release-upgrade weiß, dass das System tot ist. apt weiß es nicht. Dieselbe Information, dieselbe Maschine, zwei Werkzeuge — nur eines sagt es. Und ausgerechnet das, das man täglich benutzt, schweigt.

Daraus folgt eine konkrete Betriebsempfehlung: Verlass dich nicht auf apt, um EOL zu erkennen. Ein wöchentlicher Cronjob mit do-release-upgrade -c liefert die Information, die apt update verschweigt.

Die Support-Zusage hat ein Kleingedrucktes

Bei den Zeiträumen gibt es eine Einschränkung, die in Vergleichstabellen fast immer fehlt — wir haben sie bereits in unserem Debian-vs-Ubuntu-Vergleich an den Archiven belegt: Die kostenlose Fünf-Jahres-Zusage einer Ubuntu LTS gilt für die Pakete in main. Nicht für universe.

Das ist keine Randnotiz. In main liegen bei 26.04 LTS 6.487 Pakete, in universe 66.741. Werkzeuge wie certbot, fail2ban, viele Sprachlaufzeiten und ein großer Teil dessen, was einen typischen Webserver ausmacht, liegen in universe. Für diese Pakete gilt die Fünf-Jahres-Zusage nur mit Ubuntu Pro — kostenlos für bis zu fünf Maschinen, danach kostenpflichtig.

Für die Frage „LTS vs normal” ändert das die Richtung allerdings nicht, sondern verstärkt sie: Auf einem Interim-Release gilt für beide Bereiche gar nichts, sobald die neun Monate um sind.

Wann ein Interim-Release trotzdem die richtige Wahl ist

Dieser Artikel liest sich bis hier wie eine Abrechnung. Deshalb ehrlich die Gegenseite — es gibt Fälle, in denen ein Zwischenrelease vernünftig ist:

1. Entwickler-Desktop mit Bedarf an frischen Toolchains. Wenn du gegen PHP 8.5 oder Python 3.14 entwickeln musst und kein Docker einsetzen willst, spart das Zwischenrelease echte Zeit. Der Preis — alle sechs Monate ein Upgrade — trifft auf einem Arbeitsgerät weniger hart als auf einem Server.

2. Sehr neue Hardware auf dem Desktop. Der HWE-Stack der LTS holt viel auf, aber ein brandneues Notebook profitiert manchmal von einem Interim. Das ist ein Desktop-Argument, kein Server-Argument.

3. Als Vorschau auf die nächste LTS. Wer 26.04 LTS produktiv fährt, kann sinnvollerweise ein 26.10 auf einer Testmaschine betreiben, um zu sehen, was kommt.

Was in keinem dieser Fälle gilt: ein Server, der Dienste ins Internet stellt. Wir betreiben mehrere VPS mit Caddy, Node-Diensten, MariaDB, PostgreSQL, Redis und Shopware. Auf keinem davon läuft ein Zwischenrelease — aus dem einfachen Grund, dass drei Monate Sicherheitslücke schlimmer sind als eine zwei Jahre alte nginx-Version. Wie wir solche Systeme aufsetzen, steht in unserem Leitfaden zum Linux-Server einrichten; wer noch bei der Distributionswahl steht, findet die Übersicht unter Linux-Server-Distributionen.

Wer die frischen Versionen wirklich braucht, löst das ohnehin nicht über die Distributionswahl, sondern über die Quelle: Container-Images, Hersteller-Repositories oder Sprachversionsverwalter. Eine LTS als Unterbau plus Docker Compose für die Anwendungen gibt dir beides — stabilen Unterbau und aktuelle Laufzeiten. Für Desktop-Systeme lohnt zusätzlich der Blick auf Ubuntu vs. Mint und, falls du am Anfang stehst, auf welches Linux für Anfänger geeignet ist.

Praxis: Welche Version läuft bei mir, und wie lange noch?

Drei Befehle, die auf jedem Ubuntu-System funktionieren.

Welches Release läuft hier?

lsb_release -a

Steht in Description das Wort LTS, bist du auf der langen Schiene.

Bis wann bekomme ich Updates?

ubuntu-security-status

Das Werkzeug gehört zum Basissystem und zeigt, wie viele installierte Pakete aus main stammen, wie viele aus universe und was davon unter welche Zusage fällt. Es ist die ehrlichste Auskunft, die das System über sich selbst gibt.

Steht ein Release-Upgrade an?

do-release-upgrade -c

Und wie oben gezeigt: Wenn hier „no development version of an LTS available” erscheint, obwohl du auf einer LTS sitzt, prüf den Prompt-Wert in /etc/update-manager/release-upgrades, bevor du das für eine Entwarnung hältst.

Minimaler EOL-Wächter

Weil apt schweigt, hier ein Skript, das die Lücke schließt. Es liest das Signaturdatum des eigenen Sicherheits-Repositories und schlägt an, wenn es zu alt ist:

#!/bin/bash
# Warnt, wenn das eigene Security-Repo seit über 30 Tagen nicht signiert wurde.
SUITE=$(lsb_release -cs)
DATE=$(curl -fsS --max-time 30 \
  "http://security.ubuntu.com/ubuntu/dists/${SUITE}-security/InRelease" \
  | grep -m1 '^Date:' | cut -d' ' -f2-)

if [ -z "$DATE" ]; then
  echo "WARNUNG: Signaturdatum nicht lesbar - Repo entfernt oder offline?"
  exit 1
fi

AGE=$(( ( $(date +%s) - $(date -d "$DATE" +%s) ) / 86400 ))
echo "Letzte Signatur: $DATE (${AGE} Tage alt)"
[ "$AGE" -gt 30 ] && { echo "ALARM: ${SUITE} wird nicht mehr gepflegt."; exit 1; }
exit 0

Wichtig ist der mittlere Block: Wenn das Datum nicht gelesen werden kann, meldet das Skript einen Fehler, statt stillschweigend „alles in Ordnung” anzunehmen. Ein Prüfer, der bei fehlender Information Entwarnung gibt, ist gefährlicher als gar kein Prüfer — genau dieser Fehler steckt ja im Verhalten von apt.

Der Wechsel von Interim auf LTS

Wenn du feststellst, dass du auf einem toten Zwischenrelease sitzt: Der Weg führt über die Zwischenstationen, nicht direkt.

1. Sichern. Vollständiges Backup, bei einem VPS ein Snapshot. Ein Release-Upgrade ist nicht rückgängig zu machen.
2. Aktuellen Stand herstellen. sudo apt update && sudo apt full-upgrade
3. Drittanbieter-Repositories deaktivieren. Sie sind die häufigste Ursache für abgebrochene Upgrades.
4. Prompt prüfen. In /etc/update-manager/release-upgrades auf normal setzen, wenn das nächste Ziel eine LTS ist, die noch nicht breit ausgerollt wird.
5. Upgraden. sudo do-release-upgrade — bei mehreren Sprüngen (z. B. 25.04 → 25.10 → 26.04) jeden Schritt einzeln, mit Neustart dazwischen.
6. Prüfen statt annehmen. Nach dem Neustart lsb_release -a, dann jeden Dienst einzeln testen. Eine Erfolgsmeldung des Upgraders ist keine Aussage darüber, ob deine Anwendung noch läuft.

Bei mehr als zwei Sprüngen ist eine Neuinstallation oft der schnellere und sauberere Weg. Die Konfiguration liegt ohnehin in Dateien, die Daten im Backup — und ein frisch aufgesetztes System schleppt keine Reste aus vier Upgrade-Generationen mit.

Häufige Fragen

Was ist der Unterschied zwischen Ubuntu LTS und einer normalen Version?

Eine LTS erscheint alle zwei Jahre im April und bekommt fünf Jahre kostenlose Sicherheitsupdates für die Pakete in main, mit Ubuntu Pro zehn. Eine normale Version — auch Interim- oder Zwischenrelease genannt — erscheint alle sechs Monate und wird nur neun Monate gepflegt. Unsere Auswertung aller 44 Releases seit 2004 ergibt einen Median von 5,04 Jahren für LTS gegen 9,2 Monate für Interim-Releases.

Warnt Ubuntu mich, wenn meine Version keine Updates mehr bekommt?

Bei apt nicht. Wir haben ein Ubuntu 25.04 getestet, das seit acht Monaten ohne Support ist: apt update und apt upgrade liefen fehlerfrei durch, meldeten sogar neun aufrüstbare Pakete und gaben keine einzige Warnung aus. Der Grund ist, dass die InRelease-Dateien kein Valid-Until-Feld enthalten — wir haben alle fünf geprüft, null Treffer. Nur do-release-upgrade -c erkennt den Zustand und meldet „Your Ubuntu release is not supported anymore”.

Hat ein Interim-Release einen neueren Kernel als eine LTS?

Nur am Erscheinungstag. Über den HWE-Stack bekommt Ubuntu 24.04 LTS heute Kernel 7.0.0 — neuer als der Kernel 6.17, auf dem das jüngere Zwischenrelease 25.10 endgültig festsitzt. Ein sudo apt install linux-generic-hwe-24.04 genügt. Das verbreitetste Argument für Zwischenreleases trägt damit in der Praxis nicht.

Wie lange wird Ubuntu 24.04 LTS unterstützt?

Bis zum 31.05.2029 kostenlos, mit Ubuntu Pro bis zum 25.04.2034. Die kostenlose Zusage gilt allerdings für die Pakete in main — bei 26.04 LTS sind das 6.487 von 75.328 Paketen. Werkzeuge aus universe wie certbot oder fail2ban fallen nur mit Ubuntu Pro darunter, das für bis zu fünf Maschinen kostenlos ist.

Kann ich direkt von einem Interim-Release auf eine LTS upgraden?

Nur wenn das Interim unmittelbar vor der LTS liegt, etwa 25.10 auf 26.04. Von 25.04 aus führt der Weg über 25.10. Jeder Sprung einzeln, mit Neustart dazwischen und einem Backup davor. Bei mehr als zwei Sprüngen ist eine Neuinstallation meist schneller und hinterlässt ein saubereres System.

Warum meldet mein 24.04-System, es gebe kein Upgrade auf 26.04 LTS?

Weil der Standardwert Prompt=lts in /etc/update-manager/release-upgrades greift. Wir haben das am 20.09.2026 gemessen: Mit Prompt=lts antwortet das System „There is no development version of an LTS available”, mit Prompt=normal auf derselben Maschine „New release ‘26.04.1 LTS’ available”. Canonical gibt LTS-Upgrades bewusst verzögert frei; die Formulierung klingt aber nach Entwarnung statt nach Einschränkung.

Gibt es Zeiträume ohne unterstütztes Interim-Release?

Ja, und zwar regelmäßig. In 6 von 19 Fällen seit 2013 starb ein Zwischenrelease, bevor sein Nachfolger erschien — die Lücken lagen zwischen 77 und 108 Tagen. Betroffen sind systematisch die Oktober-Releases, die im Juli sterben. Am 20.09.2026 ist genau so ein Fenster offen: Es gibt derzeit kein unterstütztes Interim-Release, aber drei unterstützte LTS-Versionen (22.04, 24.04, 26.04).

Bekomme ich auf einem Interim-Release überhaupt noch Sicherheitsupdates nach EOL?

Nein. Die Repositories bleiben erreichbar, aber niemand schreibt mehr hinein. Das Sicherheits-Repository von 25.04 wurde zuletzt am 19.01.2026 signiert — 243 Tage vor unserer Messung. Die drei unterstützten LTS-Releases wurden am Messtag innerhalb von drei Minuten alle neu signiert. Pakete, die du nach EOL installierst, sind exakt die vom Todestag.

Ist eine normale Version aktueller als die aktuelle LTS?

Nein. Wir haben die Paketstände verglichen: Ubuntu 26.04 LTS liegt bei nginx, Apache, PHP, Node.js, Docker, Python, PostgreSQL, MariaDB, Redis, systemd und Git durchgehend vorn oder gleichauf mit dem jüngsten Interim 25.10. Und mit 75.328 Paketen hat es auch den größten Katalog der vier untersuchten Releases. Frischer ist ein Interim nur gegenüber einer alten LTS — ein Zustand, der höchstens zwei Jahre anhält.

Welche Ubuntu-Version sollte ich für einen Webserver nehmen?

Die aktuelle LTS. Der Grund ist nicht Stabilität im Sinne von „läuft nicht ab”, sondern die Wartungsrechnung: Im Lebensfenster einer LTS von 1.862 Tagen brauchst du null Release-Upgrades, auf der Interim-Schiene zehn. Dazu kommt das Sicherheitsargument — und über den HWE-Stack bekommst du den neueren Kernel ohnehin.

Fazit: Die Frage ist falsch gestellt

„Ubuntu LTS vs normal” klingt nach einem Abwägen zwischen Stabilität und Aktualität. Nach dieser Messreihe ist das nicht der Kern. Die aktuelle LTS ist bei jedem geprüften Paket so aktuell wie das jüngste Zwischenrelease, hat den größeren Katalog und über den HWE-Stack sogar den neueren Kernel. Der Vorteil des Interim-Releases schrumpft damit auf ein schmales Zeitfenster gegen eine alternde LTS.

Dem gegenüber steht ein realer Preis: zehn Release-Upgrades statt keinem, regelmäßig wiederkehrende Monate ohne unterstütztes Ziel — und ein System, das seinen eigenen Tod nicht meldet.

Der letzte Punkt wiegt am schwersten. Ein Server, der beim Update einen Fehler wirft, wird repariert. Ein Server, der grün meldet, während niemand mehr hinter seinen Paketen steht, läuft weiter, bis jemand von außen darauf aufmerksam macht. Zwischen „es gibt nichts Neues” und „hier schaut keiner mehr hin” unterscheidet apt nicht — und diese Unterscheidung ist genau die, auf die es ankommt.

Für Server: LTS. Für Desktops mit gutem Grund: Interim, wenn die Upgrade-Disziplin wirklich steht. Und in beiden Fällen: einen Wächter bauen, der das Alter der eigenen Sicherheitsquelle prüft — denn das System selbst tut es nicht.