#Linux & Open Source · 3 Min. Lesezeit · Tim Rinkel

PODMAN-HAMMER! Version 6 schmeisst JETZT slirp4netns, cgroups v1 und BoltDB RAUS — DEIN Container-Stack braucht ein UPGRADE

PODMAN-HAMMER! Version 6 schmeisst JETZT slirp4netns, cgroups v1 und BoltDB RAUS — DEIN Container-Stack braucht ein UPGRADE

TL;DR:

  • Podman 6.0 ist offiziell raus — Release-Woche 25.–29. Mai 2026.
  • Entfernt: slirp4netns, cgroups v1, BoltDB-Backend.
  • Pflicht: Netavark, Pasta, cgroups v2, SQLite.
  • Netavark droppt iptables zugunsten von nftables — alte Firewall-Regeln werden hinfällig.
  • Config-File-Handling wurde refactored — vor allem für Remote-Clients.

Container-Welt aufgepasst, Tim — was sich seit Monaten angekündigt hat, ist jetzt offiziell. Podman 6.0 ist raus, und die Macher haben den Frühjahrsputz mit der Brechstange erledigt. Wer noch auf Altlasten läuft, wird beim Update nicht sanft hingeführt — er bleibt einfach stehen.

Drei Tote im Release

Mit Podman 6 fallen drei Komponenten endgültig raus:

  • slirp4netns — der Userspace-Network-Stack für rootless Containers. Ersatz: Pasta, performanter und mit besserer IPv6-Unterstützung.
  • cgroups v1 — die Kontrollgruppen-API aus den 2010ern. Ersatz: cgroups v2, seit Kernel 5.0 verfügbar.
  • BoltDB — das alte Storage-Backend für Container-Metadaten. Ersatz: SQLite, seit Podman 4.4 Default.

Wer auf einem alten CentOS 7 oder Ubuntu 18.04 fährt: Du wirst Podman 6 schlicht nicht installieren können. Migration auf cgroups v2 ist Pflicht.

Netavark schmeißt iptables raus

Das Container-Networking macht den nächsten Sprung: Netavark droppt iptables-Support und setzt voll auf nftables. Wer noch handgeschriebene iptables-Regeln für Container-Traffic hat, muss VOR dem Update migrieren. nft-Pendants gibt es in der Podman-Doku.

Bonus: Netavark behält jetzt die Reihenfolge der Container-Netzwerke bei. Schluss mit dem Zufallsprinzip bei Multi-Network-Containern.

Config-File-Handling refactored

Der zweite große Brocken ist das Config-File-Handling für Remote-Clients. Wer Podman Desktop oder Remote-CLI nutzt, sollte vor dem Upgrade die containers.conf sichern. Die neue Logik liest aus mehreren Pfaden mit klarer Präzedenz — alte Override-Mechanismen fallen weg.

Was du vor dem Upgrade machst

  1. cgroups v2 prüfen: stat -fc %T /sys/fs/cgroup/ muss cgroup2fs zeigen.
  2. Netzwerk-Backend: podman info | grep -i network — falls cni, vorher auf Netavark migrieren.
  3. Storage-Backend: podman system info --format '{{.Store.GraphDriverName}}' — und checken, dass SQLite läuft.
  4. Test-Container auf einer Staging-VM starten, alle eigenen Healthchecks durchlaufen.
  5. Erst dann: Update auf 6.0 in Prod.

Für Selfhoster und Homelab

Wer Podman in Quadlets oder Systemd-Units packt, bekommt durch Podman 6 keinen Bruch in der Unit-File-Syntax. Systemd-Quadlets bleiben rückwärtskompatibel. Das Risiko liegt im Netzwerk- und cgroup-Layer.

FAQ

Funktionieren meine alten Docker-Compose-Files noch?

Ja. Podman 6 unterstützt weiterhin podman compose und Docker-Compose-Syntax.

Was, wenn ich noch CentOS 7 oder RHEL 7 nutze?

Podman 6 wird dort nicht installiert. Migrationspfad: Wechsel auf RHEL 9 / Rocky 9 / Alma 9.

Bricht das Update meine Container-Volumes?

Nein. Volumes bleiben intakt, das Storage-Format hat sich nicht geändert.

Brauche ich Podman Desktop neu installieren?

Ja. Podman Desktop bekommt parallel zum 6.0-Release ein Major-Update, das die neue Config-Logik nutzt.

Funktioniert rootless noch genauso?

Ja, sogar besser. Pasta ist schneller als slirp4netns, vor allem bei IPv6 und hoher Connection-Last.

[bookmark-affiliate slug=“proton-mail“]

Quellen

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert