Ubuntu 24.04 → 26.04 auf Servern

Am Donnerstag, dem 27. August 2026 veröffentlicht Canonical Ubuntu 26.04.1, und damit öffnet sich der LTS-zu-LTS-Upgrade-Pfad von 24.04 für alle.^[schedule] Jede Anleitung, die Sie in dieser Woche finden werden, führt durch do-release-upgrade und hört dort auf. Dieser Befehl ist nicht der schwierige Teil. Der schwierige Teil ist, dass Ubuntu zwischen Noble Numbat und Resolute Raccoon sechs Bestandteile des Basissystems ersetzt hat, auf denen Server-Automatisierung stillschweigend aufbaut, zwei Bedingungen hinzugefügt hat, unter denen der Upgrader die Arbeit von vornherein verweigert, und zwei bekannte Server-Regressionen ausgeliefert hat, die dokumentiert sind und trotzdem fast nie erwähnt werden.

Das ist die Checkliste, die ich auf echten Maschinen verwende. Sie ist für Menschen geschrieben, die Ubuntu als Server betreiben: kein Desktop, kein GNOME, kein Snap Store. Alle Fakten stammen aus Canonicals eigenen Release Notes und von den Upstream-Projekten; wo die offiziellen Notizen keine Versionsnummer nennen – OpenSSL ist der interessante Fall –, habe ich keine erfunden. Alle Befehle sind lesend, sofern der Kommentar nichts anderes sagt.

Warum der 27. August das entscheidende Datum ist

Ubuntu bietet Ihnen das nächste LTS nicht am Tag seiner Veröffentlichung an. Es wartet auf dessen erstes Point Release, das etwa vier Monate später erscheint und die schlimmsten frühen Regressionen aufnimmt. Für 26.04 ist das 26.04.1 am 27. August 2026. Bis dahin meldet ein 24.04-Server mit der üblichen Richtlinie Prompt=lts vollkommen korrekt, dass es nichts zu aktualisieren gibt – das ist kein Fehler und nichts, was man umgehen sollte.^{[schedule][upgradedoc]}

# Ubuntu does NOT offer one LTS to the next until the first point release.
# For 26.04 that is 26.04.1, scheduled for Thursday 27 August 2026. Before that
# date `do-release-upgrade` on a 24.04 box correctly answers "No new release".

lsb_release -a
# Description:  Ubuntu 24.04.4 LTS
# Codename:     noble

# The policy that decides what you are offered. On servers it should be `lts`.
grep -v '^#' /etc/update-manager/release-upgrades
# [DEFAULT]
# Prompt=lts

# Prompt=lts     -> next LTS, but only after ITS point release. Correct for servers.
# Prompt=normal  -> every 6-month interim release. Wrong for almost all servers.
# Prompt=never   -> never offered. Use this to pin a fleet during a change freeze.

sudo do-release-upgrade -c          # -c = check only, changes nothing
# Checking for a new Ubuntu release
# No new release found.

# You CAN force it before 27 August with `-d`, which targets the development
# upgrade path. Do not do this on a production server: -d is how you end up
# being the person who finds the release-upgrader bug, and the point release
# exists precisely to absorb the first four months of regressions.

Genau deshalb ist der Kalender auch weniger dringend, als er sich anfühlt. Ubuntu 24.04 LTS erhält reguläre Sicherheitspflege bis April 2029. Am 27. August werden Sie nicht über eine Klippe geschoben, es wird Ihnen eine Tür geöffnet. Die einzige echte Frist ist die, die Sie sich selbst setzen, und die vernünftige liegt vor dem nächsten Release – nicht in der Woche, in der Ihre Revision oder Ihr Auditor nach dem Patch-Stand fragt.^{[releasecycle]}

Wenn Sie länger brauchen: Ubuntu Pro verlängert 24.04 per Expanded Security Maintenance bis April 2034. Für eine bewusst eingefrorene Flotte ist das eine legitime Strategie – eine Appliance, eine abgeschottete Umgebung, etwas, das ohnehin abgebaut wird. Für eine Flotte, gegen die Sie noch entwickeln, ist es eine schlechte, denn Ihre Toolchain zieht weiter und Sie backporten am Ende alles selbst.^[pro]

Die Bestandsaufnahme vorab – und warum sie nur liest

Alles Folgende läuft auf der 24.04-Maschine, bevor Sie irgendetwas anfassen. Es schreibt nichts. Der Zweck ist nicht ein hübscher Bericht, sondern eine Ausgabe, die Sie nach dem Upgrade gegen denselben Skriptlauf diffen können – damit aus „es ist wieder hochgekommen“ eine Aussage wird, die man tatsächlich überprüfen kann.

#!/usr/bin/env bash
# noble-preflight.sh - read-only. Run it BEFORE the upgrade, save the output,
# and diff it against the same script run afterwards. Nothing here changes state.
set -uo pipefail
echo "=== identity ==="
lsb_release -ds; uname -r; systemctl --version | head -1

echo "=== 1. third-party repositories (the usual cause of a stuck upgrade) ==="
# do-release-upgrade disables these and does NOT re-enable them for you.
grep -rhs --include='*.list'    -E '^deb ' /etc/apt/sources.list /etc/apt/sources.list.d/
grep -rhs --include='*.sources' -E '^URIs' /etc/apt/sources.list.d/

echo "=== 2. packages not from the Ubuntu archive ==="
# Do NOT filter on the suite name: Docker's repo suite is literally `noble` and
# PGDG's is `noble-pgdg`, so grepping the codename hides exactly the two vendors
# you care about. Ask apt-cache policy where each package actually came from -
# in ONE invocation, because per-package calls reload the cache each time and
# turn this section into several minutes on a normal server.
#
# Set MIRROR to your own archive host if you run a local mirror, otherwise
# every package on the box gets reported as third-party and the output is noise.
# [.] rather than \. - awk processes escapes in a -v assignment and would warn.
MIRROR='archive[.]ubuntu[.]com|security[.]ubuntu[.]com|ports[.]ubuntu[.]com|archive[.]canonical[.]com'

apt-cache policy $(dpkg-query -f '${binary:Package} ' -W) 2>/dev/null | awk -v m="$MIRROR" '
  /^[a-zA-Z0-9]/ { pkg = $0; sub(/:$/, "", pkg) }
  /\*\*\*/     { getline; if ($2 !~ m && $2 != "/var/lib/dpkg/status")
                     printf "%-40s %s\n", pkg, $2 }'

echo "=== 3. held and manually installed packages ==="
apt-mark showhold
apt-mark showmanual | wc -l

echo "=== 4. locally modified config files you will be asked about ==="
# Every one of these produces a "keep or replace?" prompt mid-upgrade. Decide
# NOW, in writing, not at 02:00 with the package manager waiting on you.
debsums -ec 2>/dev/null || echo "install debsums to get this list"

echo "=== 5. services that must come back up ==="
systemctl list-unit-files --state=enabled --type=service --no-pager --no-legend | awk '{print $1}'

echo "=== 6. disk headroom - /boot is the one that bites ==="
df -h / /boot /var 2>/dev/null

echo "=== 7. cgroup hierarchy - a HARD upgrade blocker (see the cgroup section) ==="
stat -fc %T /sys/fs/cgroup/
# The parameter is a systemd boolean: 0/false/no/off all mean v1. Do not match
# only [01] or you will report "fine" on a host that is explicitly forced to v1.
grep -o 'systemd.unified_cgroup_hierarchy=[^ ]*' /proc/cmdline || echo "cmdline: default (v2)"

echo "=== 8. CPU capability for the AMD64v3 cloud images ==="
for f in avx avx2 bmi1 bmi2 f16c fma abm movbe osxsave; do
  grep -qw "$f" /proc/cpuinfo || echo "  MISSING: $f"
done

echo "=== 9. anything still using System V init scripts ==="
ls -1 /etc/init.d/ | grep -v README

Vier dieser Abschnitte verdienen ihren Platz, weil sie aus einem 40-Minuten-Upgrade eine schlechte Nacht machen:

• Fremd-Repositories. do-release-upgrade deaktiviert vor dem Start jedes Repository, das nicht von Ubuntu stammt, und aktiviert es hinterher nicht wieder. Das ist korrektes Verhalten, und es bedeutet: Alles, was Sie aus einem Hersteller-Repository installiert haben – Docker, PostgreSQLs PGDG, Node, ein APM-Agent –, erhält ab dem Moment des Abschlusses keine Updates mehr, still und leise, bis Sie es von Hand auf die Suite resolute umbiegen.
• Lokal geänderte Config-Dateien. Jede einzelne erzeugt mitten in der Transaktion eine interaktive Rückfrage nach behalten oder ersetzen. Entscheiden Sie das vorher und schriftlich. Die Standardantwort behält Ihre Fassung – die sichere Wahl bei Anwendungskonfiguration und die falsche bei allem Sicherheitsrelevanten, das zwei Jahre Upstream-Härtung hinter sich hat.
• Freier Plattenplatz. / braucht mehrere Gigabyte; ein separates, kleines /boot ist der Klassiker unter den Fehlschlägen, weil dracut und mehrere Kernel es füllen und das Upgrade auf halber Strecke mit einem halb konfigurierten System abbricht.
• Die cgroup-Hierarchie und die CPU-Flags. Beides wird unten ausführlich behandelt. Beides sollten Sie jetzt herausfinden und nicht später an der seriellen Konsole.

Was sich zwischen den beiden Releases tatsächlich bewegt hat

Zuerst die großen Zahlen, denn sie setzen die Erwartung für alles Weitere. Zwei Jahre Ubuntu-Entwicklung sind ein weiter Sprung – das hier ist kein Service Pack.^[ltssummary]

Eine dieser Zeilen ist im Stillen die interessanteste. Der Sprung von OpenSSH 9.6 auf 10.2 bedeutet, dass die hybride post-quantensichere Schlüsselvereinbarung mlkem768x25519-sha256 verfügbar ist und standardmäßig bevorzugt wird – garantiert ist sie damit nicht, denn eine Gegenstelle mit 9.6 handelt weiterhin einen klassischen Austausch aus – und dass die DSA-Unterstützung vollständig entfällt. OpenSSL in 26.04 bekommt ML-KEM, ML-DSA und SLH-DSA, die NIST-Standards. Wer das Post-Quanten-Thema bisher aufgeschoben hat: Dieses Upgrade bringt einen guten Teil dieser Migration mit, ob eingeplant oder nicht.^{[openssh][openssl35][fips203]}

Sechs Voreinstellungen, die unter Ihnen ausgetauscht wurden

Das ist der Abschnitt, der in jeder anderen Anleitung fehlt, und der Grund, warum es diesen Artikel gibt. Ubuntu hat nicht nur Versionen hochgezogen, sondern die Implementierung hinter sechs Dingen ausgetauscht, die Sie täglich tippen oder voraussetzen. Die meisten sind Verbesserungen. Nur eine einzige bringt das Upgrade zum Stillstand. Der Rest wird schlicht um drei Uhr nachts jemanden in Ihrem Team verwirren, wenn es niemand aufgeschrieben hat.^[ltssummary]

sudo ist jetzt sudo-rs

Die überraschendste Zeile in den 26.04-Release-Notes: sudo-rs ist jetzt der voreingestellte sudo-Provider, und das ursprüngliche sudo von Todd C. Miller wurde in das Paket sudo.ws umbenannt. sudo-rs ist eine speichersichere Neuimplementierung, die die sudoers-Teilmenge abdeckt, die praktisch alle tatsächlich verwenden. Sein dokumentiertes Verhalten bei etwas, das es nicht unterstützt, ist der Abbruch mit einer klaren Fehlermeldung – nicht das stille Ignorieren. Das ist die richtige Richtung, und genau deshalb sollten Sie vorher prüfen statt hinterher: Eine nicht unterstützte Direktive legt sudo lahm, und zwar auf einer Maschine, auf der sudo der Weg ist, Dinge zu reparieren. Eine kurze, abschließend aufgezählte Menge wird stattdessen akzeptiert und ignoriert – env_reset, visiblepw, verifypw, mail_badpass, always_set_home, log_denied und eine Handvoll weiterer –, und keine davon lockert Zugriffsrechte.^[sudors]

# 26.04 makes sudo-rs the default sudo provider. The original sudo by
# Todd C. Miller is still packaged, renamed to `sudo.ws`.

sudo --version
update-alternatives --display sudo    # which implementation is actually selected

# sudo-rs implements the sudoers subset that essentially everyone uses:
# user/group specs, host specs, NOPASSWD, Cmnd_Alias, %group, includedir.
# Its documented behaviour on something it does NOT support is to fail closed
# with a clear error, not to ignore it. That is the safe direction - but it
# means an unsupported directive stops sudo from working rather than quietly
# degrading it, so you want to find those directives before the upgrade, not
# from a locked-out root account afterwards. A short enumerated set is accepted
# and ignored instead (env_reset, visiblepw, verifypw, mail_badpass,
# always_set_home, log_denied among them); none of those loosen access.

# Resource limits and umask move to PAM; sendmail integration is simply gone.
grep -rEn 'Defaults.*(umask|rlimit|mailto|mailerpath|env_keep|logfile|SELinux|role|type)' \
     /etc/sudoers /etc/sudoers.d/ 2>/dev/null

# Whatever you change, validate with the checker that matches your provider.
# visudo uses it automatically; run it by hand after any scripted edit.
sudo visudo -c

# --- If you find something sudo-rs will not honour ---
# Both implementations coexist; the provider is chosen through alternatives,
# so installing the package is only half the job:
sudo apt install sudo.ws
sudo update-alternatives --config sudo
# Treat this as a migration window rather than a destination: fix the sudoers
# file so you do not depend on the fallback staying available.

# --- One removal has no fallback ---
# The `sudo-ldap` package is gone. If your sudoers rules live in LDAP you must
# move that authorisation to PAM before upgrading, not after:
dpkg -l sudo-ldap 2>/dev/null | grep '^ii' && echo "ACTION REQUIRED: sudo-ldap is removed in 26.04"

Zwei praktische Hinweise. Erstens existieren beide Implementierungen nebeneinander, und der Provider wird über update-alternatives ausgewählt – die Installation von sudo.ws ist also erst die halbe Rückkehr. Zweitens gibt es eine Entfernung ganz ohne Rückfallpfad: Das Paket sudo-ldap ist weg. Wenn Ihre sudo-Autorisierungsregeln im LDAP liegen, muss das vor dem Upgrade auf PAM-basierte LDAP-Authentifizierung umgestellt werden – sonst landen Sie auf einem System, auf dem die Regeln schlicht fehlen, und je nachdem, wie Ihre Eskalationspfade verdrahtet sind, möglicherweise auf einem, das Sie ohne Konsolenzugang nicht mehr reparieren können.

ls, sort und date sind jetzt Rust

Zweite Überraschung: Die Kernwerkzeuge stammen jetzt aus der Rust-Implementierung rust-coreutils. Die GNU-Binärdateien sind weiterhin installiert, mit dem Präfix gnu – gnuls, gnudate, gnusort. Bemerkenswert: cp, mv und rm sind innerhalb des Rust-Pakets weiterhin GNU, wegen ungelöster Fehler zurückgehalten. Das ist die richtige Entscheidung – und es bedeutet, dass ausgerechnet die Werkzeuge mit dem größten Zerstörungspotenzial unverändert geblieben sind. Eines sollten Sie wissen, bevor Sie sich eine Meinung bilden: Die 26.04-Release-Notes legen zwanzig bekannte CVEs gegen rust-coreutils offen. Offengelegt ist erheblich besser als verschwiegen, und nichts davon ist ein Grund zur Panik – aber es bedeutet, dass die Kernwerkzeuge auf Ihren Patch-Radar gehören und nicht in die gedankliche Schublade der Dinge, die sich nie bewegen.^[uutils]

# Core utilities now come from rust-coreutils (the uutils project). The GNU
# binaries are still installed, prefixed with `gnu`: gnuls, gnudate, gnusort...

ls --version | head -1        # uutils
gnuls --version | head -1     # GNU

# Worth knowing before you decide: the 26.04 release notes ship a list of
# twenty known CVEs against rust-coreutils (CVE-2026-35341 through -35377).
# That is disclosed, not hidden, and none of it is a reason to panic - but it
# is a reason to keep this package on your patching radar rather than assuming
# core utilities are the boring part of the system.

# cp, mv and rm are STILL the GNU implementations inside rust-coreutils, held
# back over unresolved bugs. So the utilities most likely to destroy data are
# the ones that did not change - which is the right call, and worth knowing
# before you go hunting for a regression in the wrong place.

# Where this actually bites: scripts that parse output, or lean on a GNU-only
# flag. Behaviour is close, not identical, and error text differs.
# Test the parsers, not the interactive use:
sort --help | grep -c . ; date --help | grep -c .

# --- Reverting, if a script you cannot change depends on GNU behaviour ---
sudo apt install coreutils-from-gnu --allow-remove-essential
# ...and back again:
sudo apt install coreutils-from-uutils --allow-remove-essential
# `--allow-remove-essential` is required because coreutils is Essential:yes.
# Read that flag as the warning it is: run it from a console you can recover,
# not over the SSH session you are about to need.

chrony ersetzt systemd-timesyncd – nur nicht auf Ihrer Maschine

Drittens, und das ist der Punkt, den ich am häufigsten übersehen sehe: chrony ist jetzt der voreingestellte Zeitdienst anstelle von systemd-timesyncd – aber nur bei Neuinstallationen. Ihr aktualisierter Server behält timesyncd, funktioniert weiter und weicht ab sofort still von der Dokumentation, von den Härtungsvorgaben (BSI IT-Grundschutz, CIS Benchmarks) und von jedem Runbook ab, das gegen 26.04 geschrieben wurde. Canonical dokumentiert die manuelle Migration; ausgeführt wird sie von niemandem.^[chrony]

# Chrony replaces systemd-timesyncd as the default time daemon - but ONLY for
# fresh installs. An upgraded 24.04 server keeps timesyncd and will not tell
# you it is now off the default path. This is the change most likely to be
# missed, because nothing breaks: you just quietly stop matching the docs.

timedatectl show --property=NTP --property=NTPSynchronized
systemctl is-active systemd-timesyncd chrony 2>/dev/null

# --- The migration Canonical documents for upgraded systems ---
sudo apt-mark auto systemd-timesyncd     # demote it to an automatic dependency
sudo apt install chrony                  # installing chrony displaces timesyncd

# Verify you have exactly one time daemon running, not zero and not two:
systemctl is-active chrony
chronyc tracking
chronyc sources -v

# --- The trap, if you had ever edited chrony.conf ---
# Ubuntu's NTS-authenticated pool now lives in a separate drop-in file. If your
# old chrony.conf still lists servers, you will poll the same pool twice.
grep -E '^(server|pool)' /etc/chrony/chrony.conf
cat /etc/chrony/sources.d/ubuntu-ntp-pools.sources
# Keep the drop-in, comment out the duplicates in chrony.conf, then:
sudo systemctl restart chrony && chronyc sources -v

Die Migration hat am anderen Ende eine Falle. Ubuntus NTS-authentifizierter Pool liegt jetzt in /etc/chrony/sources.d/ubuntu-ntp-pools.sources. Wenn Sie jemals chrony.conf bearbeitet und dort pool- oder server-Zeilen stehen gelassen haben, fragen Sie dieselben Server doppelt ab – nicht tödlich, aber genau die Art von Detail, die ein halbes Jahr später eine verwirrende chronyc-Ausgabe erzeugt, wenn jemand einer Uhrabweichung nachgeht.

dracut ersetzt initramfs-tools

Viertens: dracut ist jetzt die voreingestellte Initramfs-Infrastruktur und löst initramfs-tools ab. Die Release Notes sind an dieser Stelle vorsichtig, und wir sollten es auch sein – initramfs-tools bleibt unterstützt, und Sie können zwischen den beiden Implementierungen wechseln. Womit ein aktualisierter Host am Ende tatsächlich läuft, sollten Sie nicht aus einem Blogartikel ableiten, auch nicht aus diesem. Prüfen Sie es und handeln Sie nach dem Befund:^{[dracut][dracutconf]}

• Fragen Sie die Maschine, statt zu schließen. dpkg -l dracut initramfs-tools sagt Ihnen, was installiert ist, und dracut --version, ob es benutzbar ist. Beachten Sie dabei: lsinitrd kennt keine Option --version, der naheliegende Einzeiler zur dracut-Erkennung liefert also die falsche Antwort – nehmen Sie stattdessen dracut --version.
• Die Konfiguration liegt woanders. Wenn Sie tatsächlich wechseln, ist /etc/initramfs-tools/ nicht mehr der Ort: dracut liest /etc/dracut.conf.d/, und jeder eigene Hook, jede Modulliste und jeder erzwungene Treiber muss dafür neu geschrieben werden. Diese Neufassung ist die eigentliche Arbeit, und sie wird Ihnen nicht abgenommen.
• Das Image inspizieren, nicht neu erzeugen. Lassen Sie sich den Inhalt auflisten und bestätigen Sie, dass Ihre Storage- und Netzwerktreiber enthalten sind – NVMe, virtio, megaraid, mpt3sas, was auch immer Ihre Hardware oder Ihr Hypervisor braucht. Das Initramfs unmittelbar nach einem Release-Upgrade neu zu bauen, auf einem Host, den Sie noch nicht zweimal neu gestartet haben, ist das Riskanteste, was Sie auf dieser Seite tun könnten.

cgroup v1 ist weg, und blockiert das Upgrade

systemd 259 in 26.04 hat überhaupt kein cgroup v1 mehr. Upstream wurden die Legacy- und Hybrid-Hierarchien in systemd 258 entfernt; beim Booten wird nur noch cgroup v2 eingehängt. Canonical hat daraus eine harte Sperre gemacht statt einer Überraschung – im Wortlaut: „Ubuntu-Installationen, die cgroup v1 verwenden, werden nicht auf Ubuntu 26.04 LTS aktualisieren dürfen.“ Der Fehlerfall ist hier also ein verweigertes Upgrade und kein unbrauchbarer Host. Das ist der gute Ausgang, und es lohnt sich, an dieser Stelle präzise zu sein, denn viele Darstellungen dieser Änderung legen etwas anderes nahe.^{[systemd258][cgroupv2]}

# systemd 259 in 26.04 has NO cgroup v1. The legacy and hybrid hierarchies
# were removed upstream in systemd 258; only cgroup v2 is mounted at boot.
#
# Canonical turned that into a hard gate rather than a surprise: "Ubuntu
# installations running cgroup v1 will not be allowed to upgrade to Ubuntu
# 26.04 LTS." So the failure mode is a REFUSED upgrade, not a bricked host -
# which is the good outcome, and the reason to check now is that you would
# otherwise discover it inside your maintenance window.

stat -fc %T /sys/fs/cgroup/
# cgroup2fs   -> v2, the upgrade will proceed
# tmpfs       -> v1 or hybrid, the upgrader will refuse. Fix it first.

# The parameter is a systemd boolean: 0, false, no and off all select v1.
grep -o 'systemd.unified_cgroup_hierarchy=[^ ]*' /proc/cmdline
grep -o 'systemd.legacy_systemd_cgroup_controller=[^ ]*' /proc/cmdline

# --- Fix it on 24.04, reboot, and confirm the workload still works ---
sudoedit /etc/default/grub
#   remove systemd.unified_cgroup_hierarchy=0 from GRUB_CMDLINE_LINUX*
sudo update-grub && sudo reboot
# after the reboot:
stat -fc %T /sys/fs/cgroup/     # must print cgroup2fs

# Two related consequences that are easy to miss, both from the release notes:
#   - a 26.04 CONTAINER will not run on a host still booted with cgroup v1
#   - a 26.04 HOST will not run containers that require v1 (e.g. images based
#     on Ubuntu older than 18.04). Check your base images, not just your hosts.

# --- The other systemd deadline, and it is closer than you think ---
# 26.04 is the LAST release that runs System V init scripts. systemd 260 has
# already dropped the support upstream, so the release that loses it is 26.10
# - October 2026, not some comfortable date in 2028.
ls -1 /etc/init.d/ | grep -v README
systemctl list-units --type=service --no-pager | grep -i 'LSB:'

Das Muster, nach dem Sie suchen, ist ein Kernel-Parameter, meist systemd.unified_cgroup_hierarchy=0, vor Jahren gesetzt, um ein altes Docker, einen alten Kubernetes-Node oder einen JVM-Monitoring-Agenten zufriedenzustellen – und nie wieder entfernt, weil niemand je daran erinnert wurde. Ihn jetzt zu finden statt in der Nacht des Upgrades hat einen schlichten Grund: Eine Verweigerung mitten im Wartungsfenster kostet Sie das Wartungsfenster trotzdem. Zwei Folgewirkungen übersieht man leicht: Ein 26.04-Container läuft nicht auf einem Host, der noch mit cgroup v1 gebootet ist, und ein 26.04-Host führt keine Container aus, die v1 verlangen – etwa alles, was auf Ubuntu älter als 18.04 basiert. Prüfen Sie also Ihre Basis-Images, nicht nur Ihre Hosts. Davon getrennt: 26.04 ist das letzte Release, das System-V-Init-Skripte ausführt, und diese Frist liegt näher, als sie aussieht – systemd 260 hat die Unterstützung upstream bereits entfernt, das Release, das sie verliert, ist also 26.10 im Oktober 2026 und kein bequemes Datum in 2028.^{[since2510][mobycgroup][systemd260]}

APT 3 und der Wegfall von apt-key

APT geht von 2.7 auf 3.1, und die Änderung, die Automatisierung bricht, ist der Wegfall von apt-key. Es ist seit Jahren abgekündigt, und es gibt keinen Ersatzaufruf: Die Signaturprüfung läuft nun direkt über gpgv, und jedes Repository muss seinen eigenen Schlüssel benennen. Jedes Provisionierungsskript, das noch apt-key add aufruft, scheitert unter 26.04 – und weil dieser Aufruf meist früh im Bootstrap steht, scheitert es, bevor irgendetwas Nützliches passiert ist.^{[aptsecure][aptsources]}

# APT 3 in 26.04 removes `apt-key` entirely. Verification goes straight to
# gpgv, and every repository must name its key explicitly.

apt --version                       # apt 3.1.x
command -v apt-key || echo "apt-key: gone, as expected"

# Find repositories that still rely on the deleted trusted keyring. These are
# what break: not the tool, the repositories that assumed it.
ls -l /etc/apt/trusted.gpg /etc/apt/trusted.gpg.d/ 2>/dev/null

# --- The replacement: one key per repository, referenced by path ---
# Create the directory explicitly. It exists on a normal install and does NOT
# on a minimal container image, which is exactly where bootstrap scripts run.
sudo install -m 0755 -d /etc/apt/keyrings
# Dearmor the key into its own file (note .gpg for binary, .asc for armoured):
curl -fsSL https://example.com/repo.asc \
  | sudo gpg --dearmor -o /etc/apt/keyrings/example.gpg
sudo chmod 0644 /etc/apt/keyrings/example.gpg

# Then point the repository at it. Modern deb822 format, /etc/apt/sources.list.d/example.sources:
#   Types: deb
#   URIs: https://example.com/apt
#   Suites: resolute
#   Components: main
#   Signed-By: /etc/apt/keyrings/example.gpg
#
# Or the one-line form, if you still use it:
#   deb [signed-by=/etc/apt/keyrings/example.gpg] https://example.com/apt resolute main

sudo apt update                     # any repo you missed fails loudly here

# --- Worth knowing about, not worth planning around ---
# APT 3 adds transaction history. It replays package operations; it does not
# restore data, and it cannot undo a release upgrade.
apt history-list
sudo apt history-undo <ID>

APT 3 bringt außerdem einen neuen Abhängigkeitslöser, der automatisch einspringt, wenn der klassische keine Lösung findet, sowie eine Transaktionshistorie mit apt history-undo und apt history-rollback. Lesen Sie zu dieser Historie das Kleingedruckte, bevor Sie sich darauf verlassen: Sie spielt Paketoperationen zurück. Sie stellt keine Daten wieder her, sie weiß nichts von Ihrer Datenbank, und ein Release-Upgrade kann sie nicht rückgängig machen.

Python 3.12 → 3.14 überquert die toten Batterien

Ubuntu 24.04 liefert Python 3.12 aus, 26.04 liefert 3.14. Dieses Upgrade überquert damit 3.13, das Release, das neunzehn Module der Standardbibliothek gelöscht hat – nach PEP 594. Es gibt keine Deprecation-Warnung mehr, die Sie abfangen könnten, denn die Warnphase waren 3.11 und 3.12. Was Sie stattdessen bekommen, ist ein ImportError zur Laufzeit, in genau dem Cronjob, Hook oder Request-Handler, der diesen Import zuerst erreicht.^{[py313][pep594]}

# 24.04 shipped Python 3.12. 26.04 ships 3.14 as the system interpreter - so
# this upgrade crosses 3.13, the release that deleted nineteen standard-library
# modules under PEP 594. Nothing warns you: the import simply fails at runtime,
# in whichever cron job or handler happens to reach that line first.

python3 --version                   # Python 3.14.x

# Scan everything you own for the removed modules, before the upgrade. Note
# the module name is matched anywhere on an import line, not just directly
# after the keyword - otherwise `import os, cgi` slips straight through.
grep -rInE '^[[:space:]]*(import|from)[[:space:]].*\b(aifc|audioop|cgi|cgitb|chunk|crypt|imghdr|mailcap|msilib|nis|nntplib|ossaudiodev|pipes|sndhdr|spwd|sunau|telnetlib|uu|xdrlib)\b' \
  --include='*.py' /opt /srv /usr/local/lib /home 2>/dev/null

# The three that actually turn up on servers, and what to do about each:
#   cgi / cgitb -> old WSGI shims and form parsing. Move to the framework's
#                  parser, or `pip install standard-cgi` as a stopgap.
#   crypt       -> /etc/shadow hashing in provisioning scripts.
#                  Replace with `passlib` or a libxcrypt binding.
#   telnetlib   -> network-device automation. Replace with `netmiko`/`pexpect`,
#                  or better, stop using telnet.
# Pure-Python removals are republished on PyPI under `standard-*` names, which
# buys you a release cycle. It does not fix the code.

# Do not forget the interpreter under your virtualenvs: a venv created against
# 3.12 keeps pointing at a binary the upgrade removes. -xdev keeps this out of
# /proc, /sys and network mounts; -print0 survives paths with spaces.
find / -xdev -name pyvenv.cfg -print0 2>/dev/null \
  | xargs -0 -r grep -H 'version'   # rebuild every one of these afterwards

Drei der neunzehn tauchen auf Servern mit echter Regelmäßigkeit auf: cgi und cgitb in alten WSGI-Shims und Formular-Parsern, crypt in Provisionierungsskripten, die Hashes nach /etc/shadow schreiben, und telnetlib in der Automatisierung von Netzwerkgeräten. Die reinen Python-Module wurden auf PyPI unter Namen mit dem Präfix standard- neu veröffentlicht, was Ihnen einen Release-Zyklus verschafft, um den Code ordentlich zu reparieren. Und vergessen Sie die Virtualenvs nicht: Eine gegen das 3.12-Binary erstellte Umgebung zeigt weiterhin auf einen Interpreter, den das Upgrade entfernt.^[py314]

Ihre Cloud-Instanz wird womöglich nicht mehr unterstützt

Die Ubuntu-26.04-Cloud-Images für AMD64 werden für die Mikroarchitektur-Ebene x86-64-v3 gebaut. Lesen Sie dieses Wort genau, denn viele Darstellungen tun es nicht: Bewegt haben sich die vorgebauten Images, nicht das Archiv. x86-64-v3 ist die v2-Grundlinie plus AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT, MOVBE und OSXSAVE – eine CPU ohne diese Befehle kann sie schlicht nicht ausführen, es gibt also keinen Kernel-Parameter, der das abfedern könnte.^{[ltssummary][x86levels]}

# Ubuntu 26.04 cloud IMAGES for AMD64 are built for the x86-64-v3
# microarchitecture level. Read that word carefully: it is the prebuilt images
# that moved, not the archive. The archive stays baseline x86-64, so an
# in-place upgrade still pulls baseline packages. What you lose on an old
# instance family is SUPPORT and a launchable image - not, by itself, the boot.
# That is a smaller problem than "it will not come back", and still one you
# want to solve before you build anything else on top of it.

# x86-64-v3 is the v2 baseline plus AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT,
# MOVBE and OSXSAVE. AVX2 is a decent proxy; the loop is the real check.
# Note `abm`: Linux exposes LZCNT under that capflag, and there is no `lzcnt`
# string in /proc/cpuinfo - grep for the obvious name and every host on earth
# reports a missing feature it actually has.
for f in avx avx2 bmi1 bmi2 f16c fma abm movbe osxsave; do
  grep -qw "$f" /proc/cpuinfo && echo "  $f yes" || echo "  $f MISSING"
done

# --- AWS: previous-generation families are out ---
# M1 M2 M3 M4 / C1 C3 C4 / R3 R4 / I2 / G3 / P2 P3 P3dn are no longer supported
# from 26.04. Note the [a-z]* before the dot: without it you miss p3dn and g3s,
# which are precisely two of the families you are hunting for.
aws ec2 describe-instances \
  --query 'Reservations[].Instances[].{Id:InstanceId,Type:InstanceType}' \
  --output text | grep -E '^\S+[[:space:]]+(m[1-4]|c[134]|r[34]|i2|g3|p[23])[a-z]*\.'
# The fix is a migration, not a config change: resize onto a current family
# (m6i/m7i, c6i/c7i, r6i/r7i) FIRST, then upgrade the OS.

# --- Google Cloud: N1 on Sandy Bridge or Ivy Bridge is out ---
gcloud compute instances list --format='table(name,zone,machineType,cpuPlatform)'

# --- Bare metal / on-prem: opt in only after you have checked every host ---
# The archive itself stays baseline x86-64; the v3 build is opt-in:
echo 'APT::Architecture-Variants "amd64v3";' | sudo tee /etc/apt/apt.conf.d/99enable-amd64v3
sudo apt update && sudo apt upgrade

Praktisch bedeutet das weniger als die Panikversion, und es ist trotzdem einen Handgriff wert. Die AWS-Instanzfamilien der Vorgängergeneration werden ab 26.04 nicht mehr unterstützt, und für sie wird kein 26.04-Image gebaut. Ein do-release-upgrade an Ort und Stelle zieht die Basis-amd64-Pakete aus dem Archiv, es ist also ein Support-Problem und nicht automatisch ein Boot-Problem – aber eine nicht unterstützte Kombination unter Produktionslast zu betreiben, auf Hardware, gegen die niemand testet, ist keine Position, die man bewusst wählt. Wenn bei Ihnen eine M3 etwas Wichtiges trägt – und erstaunlich viele Leute haben so etwas, weil es seit einem Jahrzehnt einfach läuft –, ziehen Sie zuerst auf eine aktuelle Familie um und aktualisieren Sie danach. Auf Bare Metal zwingt Sie überhaupt nichts: Das Archiv bleibt Basis-x86-64, und der v3-Build ist strikt optional.^[awsprev]

Dienst für Dienst: die mit echten Migrationen

Versionssprünge verlaufen meist ereignislos. Das hier sind die Fälle, in denen die Maintainer etwas geändert haben, das Ihr Handeln erfordert – grob danach sortiert, wie übel es ausgeht, wenn Sie nichts tun:

RabbitMQ verdient die erste Zeile aus eigener Kraft: Wegen der Feature Flags ist es über diesen Sprung hinweg nicht direkt aktualisierbar, und Canonical dokumentiert manuelle Schritte dafür. Dovecot 2.4 hat das Konfigurationsformat komplett neu geschrieben – planen Sie das als eigenes Änderungsvorhaben, nicht als Nebenwirkung des Betriebssystem-Upgrades. HAProxy geht von der 2.x-Reihe auf 3.2, das das Schlüsselwort enabled für dynamische Server ablehnt, nicht standardkonforme URIs strenger parst und tune.ssl.ocsp-update in tune.ocsp-update umbenennt.^{[rabbitmq][dovecot24][haproxy32]}

Der Rest ist gewöhnlich, aber nicht automatisch. PostgreSQL 18 braucht pg_upgrade von 16 aus; MySQL 8.0 auf 8.4 LTS entfernt lange abgekündigte Optionen und die 32-Bit-Server-Unterstützung. SSSD läuft jetzt als unprivilegierter Benutzer sssd statt als root, prüfen Sie also, ob es seine Secrets und Keytabs noch lesen kann. Postfix läuft standardmäßig nicht mehr im chroot. Und wenn Sie einen Samba-Domänencontroller im Active Directory betreiben, ohne dass das Paket samba-ad-dc explizit installiert ist, installieren Sie es vor dem Upgrade – sonst überlebt die Domänencontroller-Funktionalität den Wechsel nicht, und die Komponenten, die Sie zur Reparatur bräuchten, sind genau die, die nicht installiert wurden.^{[postgres18][mysql84][sssd]}

Die zwei bekannten Probleme, die Server wirklich treffen

Canonical veröffentlicht neben den Release Notes eine Liste bekannter Probleme, und zwei Einträge darin sind konkreter als fast alles andere, was über 26.04 geschrieben wurde. Keiner der beiden blockiert das Upgrade. Beide verändern still, wie sich Ihr Server danach verhält – auf eine Weise, die Sie etwas anderem zuschreiben werden, wenn Sie nicht wissen, wonach Sie schauen müssen. Der erste ist apache2: Seine systemd-Unit setzt zur Härtung nun MemoryDenyWriteExecute=yes, was Speicher verbietet, der gleichzeitig beschreibbar und ausführbar ist – also genau das, was ein JIT-Compiler braucht. Unter libapache2-mod-php bricht damit der JIT von PHP, mit Allocation of JIT memory failed in Ihren Logs und einem Leistungseinbruch, den niemand mit einem Betriebssystem-Upgrade in Verbindung bringt.^{[since2510][apachebug]}

# Both of these are in Canonical's own known-issues list for 26.04, and both
# are more concrete than most of what gets written about this release. Neither
# stops the upgrade; both change how your server behaves afterwards.

# --- 1. apache2 + mod-php: the PHP JIT stops working ---
# The apache2 systemd unit now sets MemoryDenyWriteExecute=yes as hardening.
# That forbids memory that is writable and executable at once, which is exactly
# what a JIT needs. Symptom:
#   Warning: preg_match(): Allocation of JIT memory failed, PCRE JIT will be disabled.
dpkg -l 'libapache2-mod-php*' 2>/dev/null | grep '^ii'

# Recommended fix: move to php-fpm, which is not affected. Note the a2dismod -
# without it apache2 keeps loading mod_php and the JIT stays broken, which is
# the most common way this "fix" gets applied and then reported as not working.
sudo apt install php-fpm
sudo a2dismod php8.5 && sudo a2dismod mpm_prefork
sudo a2enmod mpm_event proxy_fcgi setenvif && sudo a2enconf php8.5-fpm
sudo systemctl restart apache2 php8.5-fpm

# If you must stay on mod-php, override the hardening deliberately - and
# understand that you are turning off a mitigation, not fixing a bug:
sudo systemctl edit apache2
#   [Service]
#   MemoryDenyWriteExecute=no
sudo systemctl restart apache2

# --- 2. PostgreSQL on the 7.0 kernel: throughput and latency regression ---
# A Linux 7.0 change can cost PostgreSQL significant throughput and latency.
# Systems using huge pages are NOT affected, so this is a configuration
# question rather than a wait-for-a-patch question.
sudo -u postgres psql -tAc 'SHOW huge_pages;'      # want: on

# huge_pages=try (the default) silently falls back to normal pages, which is
# how you end up affected without any error telling you so.
#
# Size the pool FIRST. PostgreSQL will compute the number for you - no
# arithmetic, no guessing at shared_buffers overhead:
sudo -u postgres postgres -D /var/lib/postgresql/18/main \
     -C shared_memory_size_in_huge_pages
# 3170
grep -E 'Hugepagesize|HugePages_Total' /proc/meminfo
sudo sysctl -w vm.nr_hugepages=3170                # use YOUR number, then
                                                   # persist it in /etc/sysctl.d/
# ...and only now turn it on:
sudo -u postgres psql -c "ALTER SYSTEM SET huge_pages = 'on';"
sudo systemctl restart postgresql
# huge_pages=on means PostgreSQL REFUSES TO START if the pages are not
# available. That is the point - it fails loudly instead of quietly slowly -
# but it means you size the pool before you flip the setting, not after.

Der zweite ist PostgreSQL, und darauf würde ich wetten, dass er falsch diagnostiziert wird. Eine Änderung in Linux 7.0 kann einen erheblichen Einbruch bei Durchsatz und Latenz verursachen – Systeme, die Huge Pages verwenden, sind davon jedoch nicht betroffen, womit das eher eine Konfigurationsfrage ist als eine Frage des Wartens auf einen Patch. Der Haken: PostgreSQLs Voreinstellung huge_pages=try fällt still auf normale Speicherseiten zurück, ein betroffener Server meldet also überhaupt nichts – keine Fehlermeldung, keine Warnung, nur schlechtere Zahlen als in der Woche zuvor. Setzen Sie huge_pages=on bewusst, und dimensionieren Sie den Huge-Page-Pool vorher, denn on bedeutet, dass PostgreSQL den Start verweigert, wenn die Seiten nicht da sind. Das ist der richtige Tausch – lieber laut scheitern als leise langsam werden –, aber es ist keine Einstellung, die man am Ende eines langen Wartungsfensters umlegt.^{[pghugepages][pgkernel][systemdexec]}

Das Upgrade durchführen

Nichts davon ist raffiniert. Der Wert liegt vollständig in der Reihenfolge – und darin, Schritt null nicht zu überspringen.^[upgradedoc]

# Nothing below is clever. The value is entirely in the order and in refusing
# to skip step 0.

# --- 0. A rollback you have actually tested ---
# Snapshot the VM, or take a filesystem-level backup you have restored from at
# least once. `do-release-upgrade` has no undo, and neither does apt history.
# If you cannot roll back, you are not upgrading, you are gambling.

# --- 1. Land on a fully patched 24.04 first ---
sudo apt update && sudo apt full-upgrade
sudo apt --purge autoremove
sudo reboot                        # boot the newest 24.04 kernel BEFORE upgrading
uname -r

# --- 2. Survive a dropped connection ---
# The upgrade takes 20-60 minutes and will kill your shell if the link drops
# mid-transaction. do-release-upgrade opens a standby sshd on 1022 by itself;
# run it inside tmux or screen anyway.
sudo apt install tmux
tmux new -s upgrade
# detach with Ctrl-b d, reattach after a disconnect with: tmux attach -t upgrade

# --- 3. Run it ---
sudo do-release-upgrade
# Answer the config-file prompts from the list you produced in the pre-flight.
# Default is "keep your currently-installed version" (N). For sshd_config and
# anything security-relevant, take the maintainer's version and re-apply your
# changes as a drop-in afterwards - your 2019 hardening file is not better
# than the 2026 defaults.

# --- 4. Reboot and verify, in this order ---
sudo reboot
lsb_release -ds                    # Ubuntu 26.04.1 LTS
uname -r                           # 7.x
systemctl --failed                 # must be empty
journalctl -p err -b --no-pager | head -50
ss -tlnp                           # every listener you expect, and nothing new

# --- 5. Clean up what the upgrade left behind ---
sudo apt --purge autoremove        # read the list before confirming
ls /etc/apt/sources.list.d/        # re-enable third-party repos, resolute suites
dpkg -l | grep '^rc' | wc -l       # removed-but-not-purged leftovers

Eine Ermessensentscheidung gehört ausgesprochen, weil die Standardantwort nicht immer die richtige ist. Wenn das Upgrade nach einer geänderten Config-Datei fragt, ist das Behalten Ihrer Fassung die sichere Wahl bei Anwendungskonfiguration und meist die falsche bei allem Sicherheitsrelevanten: Ihre sshd_config-Härtung von 2019 ist nicht besser als die Voreinstellungen von 2026. Nehmen Sie diesen Rat allerdings mit dem naheliegenden Vorbehalt. Wer die Fassung des Maintainers für sshd_config übernimmt, verwirft damit auch einen eigenen Port, ein AllowUsers, ein PermitRootLogin oder einen Match-Block aus dieser Datei – und sshd startet neu, bevor Sie das wieder eingespielt haben, über genau die Verbindung, durch die Sie gerade aktualisieren. Lassen Sie die Reserve-Sitzung auf Port 1022 offen, bringen Sie Ihre echten lokalen Änderungen als Drop-in unter sshd_config.d/ wieder ein, wo das nächste Upgrade sie in Ruhe lässt, und schließen Sie erst dann die erste Shell.

Hinterher richtig verifizieren

„Es hat gebootet“ ist keine Verifikation. Dies ist das Gegenstück zum Vorab-Skript – und, um genau zu sein, wie man beide benutzt: Sie geben bewusst unterschiedliche Abschnitte aus, diffen Sie sie also nicht pauschal gegeneinander. Direkt vergleichbar sind die Liste der aktivierten Dienste und ss -tlnp: dieselben Units aktiviert, dieselben Ports auf Empfang. Wenn ein Dienst vorher aktiviert war und es jetzt nicht mehr ist, erfahren Sie es hier – und nicht, wenn am Montag jemand ein Ticket aufmacht.

#!/usr/bin/env bash
# noble-postflight.sh - the counterpart to the pre-flight script. The two print
# DIFFERENT sections on purpose, so do not diff them against each other
# wholesale. The blocks that are directly comparable are the enabled-services
# list and `ss -tlnp`: same units enabled, same ports listening.
# "It booted" is not a verification; "the same 41 services are enabled and
# listening on the same ports" is.
set -uo pipefail

echo "=== the defaults that changed under you ==="
sudo --version | head -1                    # sudo-rs, unless you reverted
update-alternatives --display sudo | head -2
ls --version | head -1                      # uutils, unless you reverted
systemctl is-active chrony systemd-timesyncd 2>/dev/null   # exactly one active
stat -fc %T /sys/fs/cgroup/                 # cgroup2fs

echo "=== which initramfs generator is this host ACTUALLY using? ==="
# Both are supported in 26.04 and either can be in place after an upgrade, so
# do not assume - ask. (lsinitrd has no --version; dracut does.)
dpkg -l dracut initramfs-tools 2>/dev/null | grep '^ii' || true
command -v dracut >/dev/null && dracut --version

echo "=== crypto, which moved a long way in two years ==="
ssh -V                                      # OpenSSH 10.2p1 in 26.04, from 9.6p1
ssh -Q kex | grep -c mlkem                  # post-quantum key agreement offered
# OpenSSL spells these with hyphens - ML-KEM-768, not mlkem - so grep for both
# or you will "prove" that a correctly configured box has no PQ support.
openssl list -kem-algorithms | grep -ciE 'ml-?kem'

echo "=== DSA host keys are gone; make sure nothing still expects one ==="
ls /etc/ssh/ssh_host_*_key 2>/dev/null
sudo sshd -t && echo "sshd config: valid"

echo "=== services ==="
systemctl --failed --no-pager
systemctl list-unit-files --state=enabled --type=service --no-pager --no-legend | awk '{print $1}'
ss -tlnp

echo "=== rebuild every virtualenv that pointed at python3.12 ==="
find / -xdev -name pyvenv.cfg 2>/dev/null

echo "=== the two server known-issues from the release notes ==="
# 1. apache2 now sets MemoryDenyWriteExecute=yes, which breaks the PHP JIT
#    under libapache2-mod-php. php-fpm is unaffected and is the recommendation.
dpkg -l libapache2-mod-php\* 2>/dev/null | grep -q '^ii' && \
  echo "mod-php present -> move to php-fpm, or: systemctl edit apache2 (MemoryDenyWriteExecute=no)"
# 2. A Linux 7.0 change can cost PostgreSQL significant throughput and latency.
#    Systems using huge pages are not affected.
command -v psql >/dev/null && sudo -u postgres psql -tAc 'show huge_pages'
#    Anything other than `on` here is worth fixing before you call this done.

echo "=== boot integrity: inspect, do not regenerate ==="
# READ ONLY on purpose. Regenerating the initramfs immediately after a release
# upgrade is the riskiest thing you could do on this page; look first.
# /boot/initrd.img-* is mode 0600 root:root, hence the sudo on both branches.
if command -v lsinitrd >/dev/null; then
  sudo lsinitrd | grep -E 'nvme|virtio|megaraid|mpt3sas' | head
elif command -v lsinitramfs >/dev/null; then
  sudo lsinitramfs /boot/initrd.img-"$(uname -r)" | grep -E 'nvme|virtio|megaraid|mpt3sas' | head
else
  echo "neither lsinitrd nor lsinitramfs present - install the tool matching your generator"
fi

Zwei Dinge, die das Skript nicht für Sie prüfen kann. Erstens Ihre netplan-Konfiguration: 26.04 liefert Netplan 1.2 aus, samt eines eigenen systemd-networkd-wait-online, das auf eine routingfähige Schnittstelle wartet – ein Host mit einer spät hochkommenden NIC bootet also möglicherweise anders als bisher. Zweitens jedes Fremd-Repository aus der Vorab-Liste: auf die Suite resolute umbiegen, mit einem Signed-By-Schlüssel versehen und bestätigen, dass apt update sauber durchläuft. Eine Umgebung, die still keine Sicherheitsupdates des Herstellers mehr bekommt, ist die leiseste Art, wie dieses Upgrade schiefgehen kann.^[netplan]

Also: jetzt, im November oder 2027?

Mein ehrlicher Rat, nachdem ich das auf sorgfältigen wie auf sorglosen Flotten gemacht habe:

1. Aktualisieren Sie nicht am 27. August. Das Point Release existiert, um Regressionen aufzufangen, aber die, die es nicht erwischt, treten in den folgenden zwei Wochen zutage – gefunden von Leuten mit mehr Risikoappetit, als eine Produktionsumgebung haben sollte.
2. Aktualisieren Sie Anfang September einen unkritischen Server. Etwas Echtes genug, um interessant zu sein – ein Build-Agent, ein internes Werkzeug –, aber nichts, wofür man Sie nachts anruft. Lassen Sie das Vorab- und das Nachher-Skript laufen und heben Sie den Diff auf. Dieser Diff ist Ihr Migrationsdokument für alles Weitere.
3. Räumen Sie zuerst die beiden Upgrade-Sperren aus dem Weg, überall. Ein Host, der noch mit cgroup v1 gebootet ist, und alles, was auf IBM Z z14 oder älter läuft, wird vom Upgrader abgewiesen – finden Sie diese Fälle also, bevor Sie Arbeit darum herum planen. Nehmen Sie die AMD64v3-Instanzfamilien in denselben Durchgang: Die sind nicht gesperrt, aber eine nicht unterstützte Kombination zu betreiben ist eine Entscheidung, und sie sollte eine bewusste sein. Alle drei lassen sich heute unter 24.04 prüfen, unabhängig von jeder Upgrade-Entscheidung.
4. Und dann bündeln Sie den Rest über Oktober und November. Bis dahin haben die Fremd-Repositories, von denen Sie abhängen, ihre resolute-Suiten, und damit fällt der größte Teil der verbleibenden Reibung weg.

Und lesen Sie die Seite mit den bekannten Problemen, nicht nur die Zusammenfassung. Sie wird nach dem Release fortgeschrieben, und genau das ist die Eigenschaft, die man von ihr will: Die Zusammenfassung sagt Ihnen, was beabsichtigt war, die Liste der bekannten Probleme sagt Ihnen, was tatsächlich passiert ist.^[since2510]

Wenn Sie ohnehin an Init und Zeitsteuerung arbeiten, behandelt systemd-Timer gegen Cron die Migration, die dieses Release überfällig macht. Die SSH- und TLS-Seite des Upgrades ist das Thema von Post-Quanten-SSH und -TLS, wo es um die Prüfung der Verbindungen statt der Pakete geht. Und wenn Sie dieser Artikel vor allem darin bestärkt hat, künftig weniger bewegliche Teile aktualisieren zu wollen, dann ist das genau die These von langweilige Cloud-Architekturen.

Häufige Fragen

Kann ich schon vor dem 27. August 2026 von Ubuntu 24.04 auf 26.04 aktualisieren?

Technisch ja, mit do-release-upgrade -d, das auf den Entwicklungs-Upgrade-Pfad zielt. Auf einem Produktivserver sollten Sie das nicht tun. Das Point Release existiert genau dafür, vier Monate an Regressionen nach dem Release aufzufangen, und ein erzwungenes frühes Upgrade macht Sie zu der Person, die die Fehler des Release-Upgraders findet. Auf einem Notebook, das Sie in einer Stunde zurückspielen können, ist das vertretbar; auf einem Server mit echtem Verkehr nicht.

Muss ich überhaupt aktualisieren? Wie lange wird 24.04 unterstützt?

Ubuntu 24.04 LTS erhält reguläre Sicherheitspflege bis April 2029, und Ubuntu Pro verlängert das per ESM bis April 2034. Im August 2026 besteht keine Eile. Der Grund zu aktualisieren ist, dass Ihre eigene Toolchain weiterzieht – neueres Python, neueres PostgreSQL, neuere Sprachlaufzeiten – und Stillstand irgendwann bedeutet, dass Sie alles selbst backporten. Einfrieren ist eine legitime Wahl für eine Appliance oder eine Umgebung, die abgebaut wird, und eine schlechte für eine Plattform, auf der Sie weiterbauen.

Welche einzelne Änderung kostet mich am ehesten ein Wartungsfenster?

Ein übrig gebliebener Kernel-Parameter systemd.unified_cgroup_hierarchy=0. systemd 259 hat überhaupt kein cgroup v1 mehr, und Canonical hat daraus eine harte Sperre gemacht: Ein Host, der noch mit cgroup v1 gebootet ist, darf nicht aktualisieren. Sie bekommen keine kaputte Maschine – Sie bekommen eine Verweigerung, und zwar genau an der Stelle, an der Sie eine Stunde Ausfallzeit eingeplant hatten. Auf Platz zwei folgt die PostgreSQL-Regression auf dem Linux-7.0-Kernel, denn anders als die erste erzeugt sie gar keinen Fehler, sondern nur schlechtere Zahlen. Beides ist unter 24.04 in weniger als einer Minute prüfbar, heute, bevor Sie sich auf einen Termin festlegen.

Ist sudo-rs im Produktivbetrieb sicher einsetzbar?

Ja, für die sudoers-Konfiguration, die die überwältigende Mehrheit der Systeme tatsächlich hat: Benutzer- und Gruppenangaben, Host-Angaben, NOPASSWD, Kommando-Aliase, includedir. Sorgfalt braucht es an den Rändern. sudo-rs implementiert nicht die volle Bandbreite der Defaults-Einträge; Ressourcenlimits und umask wandern zu PAM, die sendmail-Integration entfällt. Trifft es auf eine nicht unterstützte Direktive, bricht es dokumentiert mit einer klaren Fehlermeldung ab, statt sie zu ignorieren – die sichere Richtung, die aber bedeutet, dass eine ungeprüfte Direktive sudo auf einer Maschine lahmlegen kann, auf der sudo der Weg ist, Dinge zu reparieren. Eine kurze, abschließend aufgezählte Menge wird stattdessen akzeptiert und ignoriert, und keine davon lockert Zugriffsrechte. Prüfen Sie die Datei vor dem Upgrade. Wenn Sie doch zurückwechseln müssen: Beide Implementierungen existieren nebeneinander – sudo.ws installieren und mit update-alternatives --config sudo auswählen; die Installation des Pakets allein wechselt den Provider nicht.

Laufen meine Docker-Container nach dem Upgrade weiter?

In nahezu allen Fällen ja, denn Ubuntu 24.04 nutzt bereits standardmäßig cgroup v2, und modernes Docker unterstützt v2 seit Jahren. Die Ausnahme ist ein Host, auf dem jemand früher systemd.unified_cgroup_hierarchy=0 auf der Kernel-Kommandozeile gesetzt hat, um ein älteres Docker oder einen älteren Kubernetes-Node zufriedenzustellen – einem solchen Host wird das Upgrade rundheraus verweigert. Prüfen Sie stat -fc %T /sys/fs/cgroup/: Die Ausgabe muss cgroup2fs lauten. Zwei verwandte Grenzen übersieht man leichter. Ein 26.04-Container läuft nicht auf einem Host, der noch mit cgroup v1 gebootet ist, und ein 26.04-Host führt keine Container aus, die v1 verlangen – etwa Images auf Basis von Ubuntu älter als 18.04. Prüfen Sie also Ihre Basis-Images ebenso wie Ihre Hosts.

Warum funktioniert mein Python-Skript nach dem Upgrade nicht mehr?

Sehr wahrscheinlich wegen eines ImportError auf ein Modul, das in Python 3.13 entfernt wurde. Ubuntu 24.04 lieferte Python 3.12 aus, 26.04 liefert 3.14, dieses Upgrade überquert also das Release, das nach PEP 594 neunzehn Module der Standardbibliothek gelöscht hat. Die drei, die auf Servern am häufigsten auftauchen, sind cgi, crypt und telnetlib. Die reinen Python-Module wurden als Übergangslösung auf PyPI unter Namen mit dem Präfix standard- neu veröffentlicht. Unabhängig davon muss jede Virtualenv, die gegen das 3.12-Binary erstellt wurde, neu gebaut werden, weil der Interpreter, auf den sie zeigt, nicht mehr existiert.

Muss ich von systemd-timesyncd auf chrony migrieren?

Nicht zwingend – timesyncd funktioniert weiter, und ein aktualisierter Server behält es. Aber chrony ist die Voreinstellung bei frischen 26.04-Installationen: Tun Sie nichts, driften Ihre aktualisierten und Ihre neu gebauten Hosts auseinander, und jedes Runbook und jede Härtungsvorgabe, die gegen 26.04 geschrieben wurde – etwa aus dem BSI IT-Grundschutz-Kompendium –, passt nicht mehr. Canonical dokumentiert die Migration als apt-mark auto systemd-timesyncd gefolgt von apt install chrony. Wenn Sie migrieren, prüfen Sie, ob in chrony.conf noch Server stehen, die das Drop-in /etc/chrony/sources.d/ubuntu-ntp-pools.sources bereits abdeckt.

Kann ich zurückrollen, wenn das Upgrade schiefgeht?

Mit Ubuntu-Bordmitteln nicht. do-release-upgrade kennt kein Rückgängig, und das neue apt history-undo spielt Paketoperationen zurück, statt ein System wiederherzustellen – es weiß nichts von Ihren Daten und kann ein Release-Upgrade nicht umkehren. Ihr Rollback ist ein VM-Snapshot oder ein Backup auf Dateisystemebene, aus dem Sie mindestens einmal tatsächlich zurückgespielt haben. Wenn Sie das nicht haben, aktualisieren Sie nicht, sondern spielen – mit gutem Erwartungswert und unbegrenztem Verlustrisiko.

Auch die darunterliegende Container-Laufzeit hat sich bewegt: was beim Wechsel auf Docker Engine 29 kaputtgeht behandelt die API-Untergrenze, den Image-Store und das Limit für Dateideskriptoren, das sich ohne Fehlermeldung geändert hat.

Quellen

Jede Aussage oben lässt sich auf eine dieser Quellen zurückführen. Für alles Ubuntu-Spezifische sind Canonicals Release Notes und der Release-Zeitplan maßgeblich, für alles Übrige die Dokumentation der Upstream-Projekte. Wo die offiziellen Notizen keine Version nennen, beschreibt dieser Artikel die Fähigkeit, statt eine Nummer zu raten.

1. Canonical — Ubuntu 26.04 LTS (Resolute Raccoon) release notes; released 23 April 2026, supported until April 2031
2. Canonical — Ubuntu 26.04 LTS summary for LTS users: the authoritative list of changes since 24.04, and the source for every default swap described here
3. Canonical — Ubuntu 26.04 LTS changes since 25.10, including the known-issues list and the cgroup v1 removal detail
4. Canonical — Resolute Raccoon release schedule; the 26.04.1 point release is listed for Thursday 27 August 2026
5. Ubuntu Server documentation — How to upgrade your release (do-release-upgrade, the -d flag, and the LTS-to-LTS point release rule)
6. Canonical — Ubuntu 24.04 LTS (Noble Numbat) release notes, the baseline this article upgrades from
7. Canonical — Ubuntu release cycle: LTS cadence, five years of standard support, ESM through Ubuntu Pro
8. Canonical — Ubuntu Pro documentation (ESM, Livepatch, and the ten-year maintenance window on 24.04)
9. Trifecta Tech Foundation — sudo-rs, the memory-safe sudo and su implementation that is now Ubuntu's default sudo provider
10. uutils/coreutils — the Rust reimplementation of the GNU core utilities shipped as rust-coreutils
11. systemd v258 release notes — removal of cgroup v1 (legacy and hybrid hierarchies) and the raised kernel baseline
12. systemd NEWS — the upstream changelog covering v256 through v259, including the System V compatibility deprecation
13. Linux kernel documentation — Control Group v2, the only hierarchy systemd still mounts
14. moby/moby #51111 — Docker's cgroup v1 deprecation discussion and support timeline
15. apt-secure(8) — repository signing after the removal of apt-key, and the Signed-By mechanism that replaces it
16. sources.list(5) — the deb822 .sources format and the Signed-By field
17. dracut(8) — the initramfs infrastructure that replaces initramfs-tools as Ubuntu's default
18. dracut.conf(5) — configuration in /etc/dracut.conf.d/, including hostonly and the drivers to force-include
19. chrony.conf(5) — the configuration file, source directories and NTS options for Ubuntu's new default time daemon
20. What's New In Python 3.13 — the release that removed the nineteen PEP 594 'dead battery' standard-library modules
21. PEP 594 — Removing dead batteries from the standard library; the full list of removed modules and their replacements
22. What's New In Python 3.14 — the interpreter Ubuntu 26.04 ships as the system Python
23. OpenSSL 3.5 series release notes — ML-KEM, ML-DSA and SLH-DSA support and the default hybrid TLS groups
24. OpenSSH release notes index — covers the 9.6 to 10.2 range that this upgrade crosses, including DSA removal
25. NIST FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM), the algorithm behind the new OpenSSL and OpenSSH defaults
26. AWS — previous generation EC2 instances; the families that lose Ubuntu support because of the AMD64v3 cloud image baseline
27. x86-64 microarchitecture levels — what x86-64-v3 requires (AVX2, BMI1/2, FMA, MOVBE)
28. RabbitMQ — upgrade documentation and feature flags, the reason RabbitMQ is not directly upgradable across this release
29. Dovecot — upgrading from 2.3 to 2.4, the release that rewrote the configuration format (26.04 ships 2.4.2)
30. HAProxy 3.2 configuration manual — the breaking changes since the 2.x series shipped in 24.04
31. PostgreSQL 18 release notes — the major version 26.04 ships, requiring pg_upgrade from 16
32. MySQL 8.4 LTS release notes — the series replacing 8.0, including removed deprecated options
33. Netplan 1.2 documentation — the series shipped in Ubuntu 26.04
34. SSSD 2.10 release notes — the change that makes the daemon run as the unprivileged sssd user rather than root
35. systemd v260 release notes — System V service script support already dropped upstream, which is why 26.10 is the release that loses it
36. PostgreSQL documentation — the huge_pages configuration parameter, the documented mitigation for the Linux 7.0 regression
37. PostgreSQL documentation — configuring Linux huge pages for the server
38. LP #2144455 — apache2's MemoryDenyWriteExecute hardening breaking the PHP JIT under libapache2-mod-php
39. systemd.exec(5) — MemoryDenyWriteExecute=, the hardening directive apache2 now sets by default