Debian 13 „trixie“: Was Admins vor dem Upgrade prüfen müssen

Debian 13 „trixie“ ist seit dem 9. August 2025 stabile Produktionsbasis – aktueller Stand ist Debian 13.5 vom 16. Mai 2026. Wer jetzt von Bookworm auf Trixie upgradet, stößt auf ABI-Wechsel, neue Kernel-Defaults und veränderte Architektur-Prioritäten. Dieser Artikel beschreibt, was Admins wirklich prüfen müssen, bevor sie das Upgrade auf dem Produktivsystem anstoßen.

Was Debian 13 trixie konkret bedeutet

Debian 13 ist keine kosmetische Iteration. Der Linux-Kernel startet mit Version 6.12, der Umstieg auf 64-Bit-time_t schließt die Y2038-Lücke für langfristig laufende Systeme, und der verbesserte Schutz gegen ROP/COP/JOP-Angriffe auf amd64 und arm64 ist für Produktivserver relevant – nicht als Marketing, sondern als konkreter Hardening-Gewinn. Dazu kommt riscv64 als erstmals offiziell vollständig unterstützte Architektur, was für klassische Rechenzentren kurzfristig wenig bedeutet, aber für Edge- und Forschungsinfrastruktur interessant wird.

Debian 12 „bookworm“ ist mit dem Trixie-Release in den Oldstable-Status gewechselt. Das bedeutet: neue Upstream-Software und frische Vendor-Pakete werden zunehmend gegen Trixie getestet, nicht mehr gegen Bookworm. Wer das ignoriert, merkt es spätestens beim nächsten Monitoring-Stack-Update oder wenn ein Datenbank-Vendor seinen Bookworm-Support stufenweise einstellt.

Der Support-Zeitraum ist klar kalkulierbar: Vollsupport bis August 2028, LTS-Phase bis Juni 2030. Für produktive Server, die länger als drei Jahre stabil laufen sollen, ist Trixie also eine solide Basis – sofern das Upgrade sauber durchgeführt wird.

Vor dem Upgrade: System-Zustand ehrlich bewerten

Der einzige offiziell unterstützte Upgrade-Pfad ist Debian 12 → Debian 13. Wer noch auf Debian 11 oder älter sitzt, muss zuerst auf Bookworm upgraden, dieses System vollständig auf den neuesten Stand bringen, und erst dann den Sprung nach Trixie wagen. Ein direkter Mehrversionssprung auf einem Produktivsystem ist kein guter Plan – unabhängig davon, wie oft man es auf Testmaschinen schon gesehen hat.

Bevor irgendjemand eine Zeile in der sources.list ändert: Das Ausgangssystem muss sauber sein. Das heißt konkret – dpkg -C darf keine halb konfigurierten Pakete auswerfen, apt -f install muss sauber durchlaufen, und apt full-upgrade auf Bookworm muss ohne unerwartete Entfernungen oder Konflikte beenden. Ein System mit kaputten Paket-Abhängigkeiten vor dem Release-Wechsel ist ein System, das danach garantiert mehr Probleme hat.

Gehaltene Pakete sind eine häufig übersehene Falle. Alles, was per apt-mark hold eingefroren wurde, muss dokumentiert und bewusst entschieden werden: Wird der Hold aufgelöst, oder bleibt er – und wenn ja, warum? Gehaltene Kernpakete oder Bibliotheken können Abhängigkeitskonflikte im Upgrade produzieren, die schwer zu debuggen sind.

Architektur: i386 ist kein produktiver Server mehr

Mit Trixie ist i386 endgültig zur Co-Architektur degradiert – ausschließlich für 32-Bit-Software auf amd64-Systemen. Wer heute noch produktive Debian-Server auf i386-Basis betreibt, sollte das Trixie-Upgrade nicht als „Lift“ planen, sondern als Anlass für eine Migration auf amd64. Technisch kann man einen i386-Server upgrades – strategisch ist es eine Sackgasse ohne Zukunft.

Für armel gilt: nur noch Upgrades, keine Neuinstallationen. Wer ARM-Server betreibt, sollte auf arm64 setzen, das vollständig unterstützt wird und deutlich bessere Performance-Charakteristiken mitbringt. Die offiziellen Debian 13 Release Notes machen diese Architektur-Entscheidungen transparent – Lektüre vor dem Upgrade ist kein optionales Extra.

Paketquellen und Drittanbieter-Repos: die kritischste Vorarbeit

Drittanbieter-Repositories sind bei Debian-Upgrades der häufigste Unruheherd. Jedes Repo in /etc/apt/sources.list.d/ muss einzeln bewertet werden: Liefert es signierte Trixie-Pakete? Gibt es überhaupt einen Trixie-Branch? Wenn nein, muss das Repo vor dem Upgrade deaktiviert werden – nicht danach.

Typische Kandidaten sind Monitoring-Agents, CI-Tools, Datenbank-Vendor-Repos oder proprietary Software-Quellen. Für viele dieser Pakete gilt: entweder der Vendor hat mittlerweile Trixie-Unterstützung dokumentiert, oder man muss die Software über einen anderen Weg beziehen – Container, Flatpak für GUI-Tools, oder schlicht warten. Wer ein Repo mit bookworm-Paketen auf einem Trixie-System aktiv lässt, riskiert ABI-Konflikte und im schlimmsten Fall einen nicht bootenden Rechner.

Meine Empfehlung: Alle aktiven Repos vor dem Upgrade in einer Textdatei inventarisieren, mit Zustand (aktiv/deaktiviert) und Begründung. Das kostet zehn Minuten und spart im Incident-Fall erheblich Zeit bei der Ursachenanalyse.

APT-Simulation: kein Upgrade ohne Trockenlauf

Bevor die echten Quellen auf Trixie umgeschrieben werden, empfiehlt sich eine Simulation. Das Muster aus den offiziellen Debian-Upgrade-Dokumenten ist klar strukturiert: zuerst apt -s upgrade --without-new-pkgs für den konservativen Pfad, dann apt upgrade --without-new-pkgs, danach apt -s full-upgrade für die Simulation des vollständigen Release-Wechsels, und erst zuletzt apt full-upgrade scharf.

Wer bei der Simulation sieht, dass APT kritische Pakete entfernen will – systemd, openssh-server, zentrale Bibliotheken – sollte das Upgrade sofort abbrechen und die Ursache klären, bevor weitergemacht wird. Das ist kein Zeichen für ein kaputtes Debian, sondern dafür, dass im Ausgangssystem noch Altlasten hängen, die aufgelöst werden müssen.

Remote-Upgrades gehören zwingend in eine tmux– oder screen-Session. Ein SSH-Verbindungsabbruch während eines dpkg-Laufs kann den Paketmanager in einem inkonsistenten Zustand hinterlassen. Das ist kein seltenes Szenario – schlechte Netzwerkverbindungen oder Provider-seitige Timeouts passieren, und dann steht man mit einem halb upgegradeten System da.

Backups, Snapshots, Out-of-band-Konsole

Das klingt nach Standardratschlag. Es ist trotzdem der Punkt, an dem die meisten Probleme bei echten Major-Upgrades entstehen – nicht weil das Backup fehlt, sondern weil es nicht getestet wurde. Ein Snapshot einer VM ist wertlos, wenn der Hypervisor beim Restore einen Fehler wirft und niemand das vorher geprüft hat.

Für virtuelle Maschinen gilt: konsistenter Snapshot nach Dienststopp oder mit quiesced Filesystem, wenn der Hypervisor das unterstützt. Für Bare-Metal-Server: vollständiges Backup inklusive EFI-Partition, Bootloader und Datenverzeichnissen, mit dokumentiertem Restore-Test. Den Zeitpunkt des Snapshots festhalten – im Incident-Fall ist es wichtig zu wissen, auf welchen Stand zurückgerollt wird.

Für Remote-Server ohne Out-of-band-Konsole ist meine klare Einschätzung: Ein Major-Release-Upgrade ohne IPMI, iDRAC, iLO oder vergleichbare Konsole ist auf produktiven Systemen nicht verantwortbar. Wenn der Provider keine OOB-Konsole bietet, ist eine Neuinstallation mit Datenmigration oft der robustere Ansatz – unangenehmer in der Planung, aber sicherer in der Ausführung.

Konfigurationsdateien und Service-Kompatibilität

Debian-Upgrades fragen während des dpkg-Laufs häufig nach: alte oder neue Konfigurationsdatei übernehmen? Wer auf diese Fragen unvorbereitet trifft, entscheidet falsch oder inkonsistent. Wer vorbereitet ist, hat die relevanten Konfigurationsdateien – sshd_config, nginx.conf, postgresql.conf, Systemd-Unit-Overrides – vorher gesichert und kann gezielt vergleichen.

Debian 13 bringt neue Defaults in mehreren Bereichen: verschärfte Crypto-Einstellungen in OpenSSH, geänderte Pfade in einzelnen Paketen, veraltete Optionen, die Warnungen oder Fehler produzieren. Diese Änderungen sind in den Release Notes dokumentiert, aber die Praxis zeigt, dass sie oft erst beim ersten Reboot nach dem Upgrade auffallen – dann unter Zeitdruck.

Kritische Serverdienste wie PostgreSQL, MariaDB, Apache oder Nginx sollten vor dem Produktiv-Upgrade in einer Staging-Umgebung auf Trixie getestet werden. Das gilt besonders für Datenbankserver, bei denen ein Version-Mismatch zwischen Datendateien und Binary einen Dienst-Start verhindert. Wer PostgreSQL-Major-Versionssprünge kennt, weiß, was gemeint ist.

Systemd-Units, Kernel-Parameter und veränderte Defaults

Ein häufig unterschätzter Aspekt bei Debian-Major-Upgrades sind die geänderten Systemd-Defaults und Kernel-Parameter. Mit dem Wechsel auf Kernel 6.12 greifen neue Defaults für Cgroup-Hierarchien, Netzwerk-Stack-Tuning und I/O-Scheduling. Für die meisten Desktop- und Standard-Server-Setups ist das unproblematisch. Für Systeme mit manuell gesetzten Kernel-Parametern in /etc/sysctl.conf oder angepassten Cgroup-Einstellungen für Container-Workloads lohnt sich eine gezielte Überprüfung: Gelten die alten Werte noch, haben sie sich mit dem neuen Kernel verschoben, oder werden sie durch neue Defaults schlicht überschrieben?

Wer auf seinem Trixie-Server Cache-sensitives Scheduling unter Linux nutzt oder plant, sollte zudem prüfen, ob die eigenen Tuning-Profile mit dem neuen Scheduler-Verhalten unter Kernel 6.12 noch sinnvoll sind. Der Kernel-Scheduler hat in diesem Versionszweig einige relevante Änderungen erhalten, die bei hochlastigen Datenbank- oder Analyse-Workloads messbare Effekte haben können – in beide Richtungen.

Systemd-Unit-Overrides in /etc/systemd/system/ können nach dem Upgrade auf veraltete Optionen verweisen, die mit der neuen Systemd-Version in Trixie nicht mehr gültig sind. Der Befehl systemctl daemon-reload nach dem Upgrade zeigt Warnungen für solche Units – diese Ausgabe sollte sorgfältig gelesen und nicht als harmlos abgetan werden. Im Betrieb merkt man solche Konfigurationsprobleme oft erst, wenn ein Dienst nach einem Neustart nicht mehr automatisch startet.

Container und Virtualisierung: besondere Fallstricke

Wer Debian 13 nicht als Host-System, sondern als Basis für Container-Images oder als Hypervisor-Gast betreibt, hat zusätzliche Variablen im Spiel. Docker- und Podman-Installationen aus Drittanbieter-Repos müssen explizit auf Trixie-Kompatibilität geprüft werden – nicht jeder Container-Runtime-Vendor hat seinen Trixie-Branch gleichzeitig mit dem Debian-Release fertiggestellt. Wer Docker aus dem offiziellen Docker-Repo bezieht, sollte den Status des Trixie-Branches dort vor dem Upgrade prüfen und gegebenenfalls auf die Debian-eigene docker.io-Variante als Übergangslösung zurückgreifen.

Für LXC- und LXD-Hosts gilt: der Kernel des Hosts bestimmt die verfügbaren Kernel-Features für alle Container. Nach dem Upgrade auf Trixie mit Kernel 6.12 kann es passieren, dass Container-Konfigurationen, die auf ältere Cgroup-v1-Verhalten gesetzt haben, angepasst werden müssen. Das betrifft besonders ältere LXC-Konfigurationen, die explizit lxc.cgroup.pattern oder ähnliche Parameter setzen.

Wer virtuelle Maschinen unter KVM/QEMU betreibt, profitiert unter Trixie von aktualisierten QEMU- und libvirt-Versionen, die bessere Virtio-Treiber und verbesserte VFIO-Unterstützung mitbringen. Der Upgrade-Pfad ist hier in der Regel unproblematisch, solange die VM-Konfigurationsdateien nicht manuell auf veraltete Gerätetypen gesetzt sind. Ein schneller Blick auf virsh dumpxml vor dem Upgrade lohnt sich, um Überraschungen beim ersten VM-Start nach dem Host-Upgrade zu vermeiden.

Nach dem Reboot: was wirklich geprüft werden muss

Der erste Reboot nach dem Upgrade ist der Moment, an dem sich zeigt, ob die Vorbereitung gereicht hat. Checkliste für die ersten Minuten: uname -a zeigt den erwarteten Trixie-Kernel (6.12.x), journalctl -b enthält keine kritischen Fehler, alle relevanten Systemd-Units sind im Zustand active (running), und ein Blick auf /etc/apt/sources.list sowie die Dateien in sources.list.d/ bestätigt, dass überall trixie steht – nicht mehr bookworm.

Obsolete Pakete und alte Kernel-Images erst nach erfolgreichem Smoke-Test entfernen. Wer direkt nach dem Reboot aufräumt und dabei den Backup-Kernel löscht, hat im nächsten Problemfall keine Rückfalloption mehr. Das gilt genauso für verwaiste Pakete, die mit apt autoremove entfernt werden könnten – erst prüfen, dann entfernen.

Debian 13.5 ist der aktuelle Stand, der Sicherheitsfixes und kritische Bugfixes aus mehreren Point-Releases bündelt. Wer eine frische Trixie-Basis aufbaut, sollte direkt auf 13.5 zielen, nicht auf 13.0. Für bestehende Installationen sorgt apt update && apt full-upgrade nach dem Release-Wechsel automatisch dafür, dass der aktuelle Point-Release eingespielt wird – vorausgesetzt, die Paketquellen sind korrekt konfiguriert.

Was bleibt

Debian 13 trixie ist als Linux-Server-Basis technisch gut aufgestellt: Kernel 6.12, Y2038-Fix, verbessertes Hardening, klarer Support-Zeitraum bis 2030. Die eigentliche Arbeit liegt nicht im Upgrade selbst, sondern in der Vorbereitung – sauberes Ausgangssystem, geprüfte Paketquellen, getestetes Backup, dokumentierter Rollback-Plan. Wer diese Hausaufgaben macht, riskiert wenig. Wer sie überspringt, hat nach dem Upgrade entweder Glück gehabt oder ein Problem.

Die offizielle Debian-Releases-Übersicht hält alle relevanten Versionsinformationen aktuell bereit. Die Release Notes sind kein optionales Dokument für Enthusiasten – sie beschreiben bekannte Probleme, empfohlene Vorgehensweisen und Änderungen, die auf keinem anderen Weg vollständig dokumentiert sind. Wann haben Sie zuletzt ein Major-Debian-Upgrade ohne Release Notes durchgeführt – und wie oft hat das wirklich ohne Nacharbeiten funktioniert?