Upgrade Ubuntu 25.10 -> 26.04 LTS | Bug "Distribution data outdated"

Ein do-release-upgrade von Ubuntu 25.10 auf 26.04 LTS bricht ab, weil das System die Ziel-Distribution als ungültig einstuft. Die Fehlermeldung „Distribution data outdated“ tritt auf, obwohl das System über die regulären Paketquellen vollständig aktualisiert wurde. Die technische Ursache liegt in der Validierungslogik des Canonical-Upgrade-Tools. Das Python-Skript gleicht den Ziel-Codenamen mit einer lokalen Datenbank ab, die durch das Paket distro-info-data bereitgestellt wird.

Da die in den Repositories von Ubuntu 25.10 (Questing Quokka) vorliegende Version 0.66 den Codenamen für 26.04 (Resolute Raccoon) noch nicht enthält, verweigert das Tool strikt die Ausführung. Das System schützt sich hierbei vor einem vermeintlich undefinierten Systemzustand. Um den Upgrade-Pfad freizuschalten, muss die Datenbank durch eine manuelle Installation der Version 0.69 direkt manipuliert werden.

Voraussetzungen für einen konsistenten Upgrade-Pfad

Bevor du tiefgreifende Änderungen an der Release-Struktur vornimmst, muss der aktuelle Paketbaum absolut konsistent sein. Inkonsistenzen im Paketmanager (dpkg) oder fehlerhaft aufgelöste Abhängigkeiten führen während des OS-Upgrades zwangsläufig zu Abbrüchen, die das System im schlimmsten Fall in einem unbootbaren Zustand zurücklassen.

Du synchronisierst zunächst die lokalen Paketlisten mit den Repositories und zwingst das System zu einem vollständigen Upgrade. Der Parameter full-upgrade ist hier essenziell, da er im Gegensatz zu einem einfachen upgrade die Berechtigung hat, Paketkonflikte durch die Deinstallation veralteter oder blockierender Pakete hart aufzulösen. Ein anschließendes autoremove bereinigt verwaiste Bibliotheken, wodurch die spätere Upgrade-Routine nicht durch Altlasten im Abhängigkeitsbaum gestört wird. Ein Reboot stellt sicher, dass keine alten Kernel-Module mehr im Arbeitsspeicher gehalten werden.

Hinweis

Prüfe die Ausgabe auf Pakete, die entfernt werden sollen. Tauchen dort selbst kompilierte Pakete oder PPA-Abhängigkeiten auf, musst du diese manuell sichern oder pinnen, bevor du fortsetzt.

sudo apt update 
apt full-upgrade --dry-run
sudo apt full-upgrade -y
sudo apt autoremove -y
sudo reboot

Nach dem Neustart verifizierst du die Fehlerursache durch eine direkte Abfrage der lokal bekannten Release-Zyklen. Die Binärdatei distro-info liest die besagte CSV-Datenbank aus. Fehlt der Eintrag resolute in der Ausgabe, ist das System logisch blind für das neue Release und der Bug ist bestätigt.

distro-info --supported

Schritt 1: Metadaten-Datenbank manuell injizierend

Da die korrigierte Version 0.69 des Pakets distro-info-data zwar auf den Master-Servern von Canonical liegt, aber nicht in den regulären Update-Kanal von Ubuntu 25.10 gepusht wurde, umgehst du den APT-Paketmanager. Du lädst das Debian-Paket direkt aus dem zentralen Pool herunter. Da es sich um ein Architektur-unabhängiges Paket handelt (_all.deb), welches lediglich CSV-Dateien und keine kompilierten Binärdateien enthält, ist dieser manuelle Eingriff sicher.

Du beziehst das Paket via wget und nutzt das Low-Level-Werkzeug dpkg, um die lokale Paketdatenbank zu überschreiben.

wget https://archive.ubuntu.com/ubuntu/pool/main/d/distro-info-data/distro-info-data_0.69_all.deb
sudo dpkg -i distro-info-data_0.69_all.deb

Hinweis

Prüfe den Hashwert mit "sha256sum distro-info-data_0.69_all.deb" | Den erwarteten Hashwert findest du in den Paket-Metadaten unter https://archive.ubuntu.com/ubuntu/dists/plucky/main/binary-all/Packages.gz. Stimmt der Hash nicht überein, brich ab und lade das Paket erneut herunter.

Um zu validieren, dass die Metadaten nun korrekt im Dateisystem liegen, wiederholst du die Abfrage der unterstützten Distributionen.

distro-info --supported

Schritt 2: Ausführungssperre für /tmp aufheben

Das Werkzeug do-release-upgrade lädt ein komprimiertes Tar-Archiv mit den spezifischen Python-Routinen für das Ziel-Release herunter, entpackt diese standardmäßig in das Verzeichnis /tmp und führt sie von dort aus. In gehärteten Server-Umgebungen (beispielsweise nach CIS-Benchmarks) wird die Partition /tmp zwingend mit dem Flag noexec gemountet. Dies verhindert, dass Malware dort abgelegte Skripte ausführen kann.

Dieses Sicherheitsfeature blockiert jedoch die Ausführung der Canonical-Skripte, was das Upgrade stumm fehlschlagen lässt. Um dies zu umgehen, remountest du das Verzeichnis temporär im laufenden Betrieb und erteilst Ausführungsrechte. Dieser Eingriff geschieht ausschließlich im RAM und überlebt keinen Neustart, sodass die Basissicherheit nach dem Upgrade automatisch wiederhergestellt wird.

sudo mount -o remount,exec /tmp

Schritt 3: Isolationsmechanismen von APT deaktivieren

Während des Herunterladens der Paketlisten für das neue Release nutzt APT aus Sicherheitsgründen Drop-Privileges. Es wechselt vom Benutzer root zum unprivilegierten Benutzer _apt. Wenn Dateisystem-Berechtigungen (etwa durch eine restriktive UMASK) oder GPG-Schlüssel-Konfigurationen den Zugriff für den _apt-Benutzer auf bestimmte Sandbox-Verzeichnisse blockieren, wirft der Prozess Warnungen oder bricht ab.

Um einen reibungslosen Ablauf des OS-Upgrades zu garantieren, hebst du diese Sandbox-Isolierung für den anstehenden Prozess gezielt auf. Du zwingst APT dazu, alle Dateioperationen als root auszuführen. Nach dem Upgrade entfernst du diese Datei wieder, um die Sicherheitsarchitektur zu reparieren.

Sicherheitshinweis

Dieser Schritt deaktiviert einen aktiven Schutzmechanismus. Führe ihn nur aus, wenn do-release-upgrade explizit mit einem _apt-Berechtigungsfehler abbricht. Prüfe vorher /var/log/apt/term.log auf den konkreten Fehler. Ist kein solcher Fehler vorhanden, überspringe diesen Schritt vollständig.

echo 'APT::Sandbox::User "root";' | sudo tee /etc/apt/apt.conf.d/10sandbox

Schritt 4: Das OS-Upgrade initiieren

Nun startest du den eigentlichen Upgrade-Prozess. Das Tool analysiert die neue Metadaten-Basis, identifiziert Ubuntu 26.04 LTS als valides Ziel, entpackt die Upgrade-Bibliotheken in das nun ausführbare /tmp-Verzeichnis und beginnt mit der Migration der Paketquellen (/etc/apt/sources.list.d/ubuntu.sources).

sudo do-release-upgrade

Führst du das Upgrade über eine SSH-Verbindung durch, erkennt do-release-upgrade dies und öffnet intern automatisch eine screen-Sitzung auf einem separaten Port (meist TCP 1022). Wenn ein Netzwerk-Timeout die SSH-Sitzung killt, läuft der Compile- und Installationsprozess im Hintergrund sicher weiter. Um dich nach einem Abbruch wieder mit der laufenden Migration zu verbinden, listest du die aktiven Sitzungen und hängst dich wieder ein.

sudo screen -list
sudo screen -r

Nach dem Upgrade: Kernel-Module und Container

Nach dem Abschluss aller Skripte erzwingt das Tool einen Reboot, um den Kernel von 26.04 zu laden. Du verifizierst den Status der neuen Distribution über den LSB-Release-Befehl.

lsb_release -a

Auf Systemen, die auf proprietäre Kernel-Module angewiesen sind (wie NVIDIA-Grafiktreiber oder spezielle Netzwerkkarten), greift das Dynamic Kernel Module Support (DKMS) Framework. DKMS überwacht Kernel-Upgrades und rekompiliert die proprietären Treiber automatisch gegen die neuen Linux-Header. Schlägt dies aufgrund von Timeouts oder fehlenden Build-Abhängigkeiten während des Upgrades fehl, lädt das System den Open-Source-Treiber (z. B. Nouveau), was Rechen- und CUDA-Workloads zerstört. Du triggerst den Rebuild der Module daher zur Sicherheit manuell an.

sudo dkms autoinstall

Bei der Ausführung von Docker-Containern werden Iptables- oder NFTables-Regeln tief in die Netzwerk-Stack-Architektur des Hosts geschrieben. Da das Upgrade auf 26.04 die Firewall-Bibliotheken austauscht, verlieren aktive Docker-Netzwerke häufig ihr Routing. Du überprüfst laufende Container und zwingst den Daemon zu einem Neustart, damit die NAT-Regeln für das Bridge-Netzwerk sauber neu injiziert werden.

docker ps
sudo systemctl restart docker

Vergiss nicht, die APT-Sandbox-Datei zu löschen, um den unprivilegierten Download-Modus für zukünftige Paket-Aktualisierungen wieder zu aktivieren.

sudo rm /etc/apt/apt.conf.d/10sandbox

Fazit

Das Scheitern des do-release-upgrade von 25.10 auf 26.04 LTS ist ein Paradebeispiel für inkonsistentes Release-Management seitens Canonical. Die Tatsache, dass das wichtigste Tool zur Systemmigration aufgrund einer statischen, nicht per regulärem APT-Kanal aktualisierten CSV-Datei fehlschlägt, ist auf Enterprise-Ebene kritisch. Es zwingt Administratoren dazu, den Standard-Paketmanager zu umgehen und .deb-Archive direkt über wget und dpkg in das Dateisystem zu injizieren – eine Praxis, die in automatisierten Infrastrukturen (Infrastructure-as-Code via Ansible oder Puppet) zu massiven Ausfällen führt, wenn sie nicht rechtzeitig in die Playbooks gepatcht wird.

Die Fehlerbehebung demonstriert gleichzeitig, wie wichtig das Verständnis der zugrunde liegenden Unix-Architektur ist. Die Modifikation der /tmp-Mount-Flags (noexec zu exec) zeigt deutlich auf, dass tief in das Betriebssystem eingreifende Skripte oftmals auf Berechtigungen angewiesen sind, die in gehärteten Systemen aus guten Gründen deaktiviert wurden. Die temporäre Deaktivierung der APT-Sandbox (_apt zu root) unterstreicht dieses Problem: Sicherheitsmechanismen, die vor kompromittierten Repository-Servern schützen sollen, werden hier zu Hindernissen im operativen Ablauf.

Ein reines Wissen um den Befehl do-release-upgrade reicht nicht aus. Als Administrator musst du die Mechaniken von Mount-Namespaces, Privilege-Drops und Kernel-Modul-Kompilierung (DKMS) beherrschen, um ein System nach einem Major-Upgrade wieder in einen produktionsreifen, sicheren Zustand zu überführen. Das händische Entfernen der APT-Sandbox-Overrides nach dem Upgrade ist dabei eine obligatorische Pflicht, um das System nicht dauerhaft einer erhöhten Angriffsfläche auszusetzen.