Rootless containers that were created with slirp4netns do not start after an upgrade to Fedora 45. Neither do Quadlet units that name slirp4netns, new containers for any user whose containers.conf still sets it as the default, or rootful containers on a host that pinned netavark to iptables. Fedora 45 ships Podman 6, which removes slirp4netns, the iptables firewall driver, BoltDB and cgroups v1. Apart from a BoltDB deprecation warning, none of it warns you before the upgrade. The containers simply refuse to start the first time you need them.
This guide gives you the exact error for each case, a preflight script that finds every affected container and file before you upgrade, and the fix for each one. We ran it twice on the same Fedora 44 host with Podman 5.8.7 and SELinux enforcing, both times upgrading to Fedora 45 and Podman 6.1.1. The first upgrade went straight through with no preparation. The second came after the prep steps below, restored from the same snapshot. The host had a normal rootless user, root, and two test accounts whose container stores were created by Podman 4 and still sat on BoltDB, one for the automatic migration and one for the manual command.
What changes for Podman on a Fedora 44 to 45 upgrade
The upgrade replaces the whole container stack at once. On the test host, podman went from 5.8.7 to 6.1.1, netavark from 1.17.2 to 2.1.0 (with aardvark-dns 2.1.0 alongside it), and containers-common from 0.67.2 to 0.69.0. The slirp4netns package is still in the Fedora 45 repos and was upgraded along with everything else, but nothing requires it anymore and Podman no longer calls it. This is what each removed piece did on the two releases:
| Setting in use before the upgrade | Fedora 44, Podman 5.8.7 | Fedora 45, Podman 6.1.1 |
|---|---|---|
Existing container created with --network slirp4netns | Starts | Refuses to start until podman system migrate |
Quadlet with Network=slirp4netns | Starts | Fails on every start, hits the systemd start limit |
default_rootless_network_cmd="slirp4netns" in containers.conf | New containers use slirp4netns | Every podman run for that user fails |
firewall_driver="iptables" for netavark | Works | Every rootful container on a bridge network fails |
| Container store still on BoltDB | Warning on every command, migrates on the first run after a reboot | Migrated to SQLite on the first command after the upgrade reboot |
| Containers on two different bridge networks | Can reach each other | Blocked by default (isolate=strict) |
| cgroups v1 | Not tested (both hosts ran cgroups v2, the Fedora default since Fedora 31) | Support removed |
For the full upstream list, including CNI, Intel Mac and Windows 10 removals that do not apply to a Fedora host, read Podman 6.0 breaking changes and how to upgrade. The Fedora side is tracked on the Podman 6 change page and is one item in the Fedora 45 release changes.
The errors you see after the upgrade
This is the host that went through the upgrade with no preparation, on its first boot into Fedora 45. Each error names a different problem, so match the text before you apply a fix:
Error: “slirp4netns support has been removed, run `podman system migrate` to update this container to use pasta”
The container was created on Podman 5 with slirp4netns, either explicitly or because slirp4netns was that user’s default at the time. The network mode is stored in the container’s config, so Podman 6 will not start it. podman system migrate rewrites the stored mode to pasta (Step 5). Containers created with pasta, the Podman 5 default, start normally: web-pasta on the same host came up with no changes.
Error: “slirp4netns support has been removed, use –network=pasta instead”
This is the same removal, but raised while a new container is being created. On an upgraded host it almost always comes from a Quadlet file with Network=slirp4netns, because Quadlet regenerates the podman run command on every start. podman system migrate cannot fix a Quadlet, since the next start passes --network slirp4netns again. On the test host the unit failed five times in two seconds and systemd gave up:
× whoami.service - whoami test service
Loaded: loaded (/home/mercy/.config/containers/systemd/whoami.container; generated)
Active: failed (Result: start-limit-hit) since Wed 2026-09-30 17:24:43 UTC; 40s ago
Process: 1007 ExecStart=/usr/bin/podman run --name whoami --replace --rm --cgroups=split --network slirp4netns --sdnotify=conmon -d --publish 8082:80 docker.io/traefik/whoami:latest (code=exited, status=125)The fix is to edit the Network= line (Step 3).
Error: invalid default_rootless_network_cmd option “slirp4netns”
A containers.conf file still sets slirp4netns as the rootless default, and Podman 6 rejects it for every new container that user runs, even a plain podman run with no network flags. podman info still reports slirp4netns as the rootless network command, which can mislead you. Look in ~/.config/containers/containers.conf, ~/.config/containers/containers.conf.d/ and /etc/containers/containers.conf.d/ (Step 3).
Error: “netavark: Must provide a valid firewall backend, got iptables”
Some hosts pinned netavark to iptables with firewall_driver="iptables", often to share the host with Docker. Netavark 2 has no iptables driver, so every rootful container on a bridge network fails, and so does every podman run that attaches to one. The run that failed with exit code 126 still left a container in Created state, which you have to remove by hand (Step 4).
No error: containers on different networks stop talking
This one fails silently. Netavark 2 isolates bridge networks from each other by default. On Fedora 44 a container on one rootful network reached nginx on another. After the upgrade, the same request timed out. Existing networks get the new default too, because their options are empty and the default applies at runtime. If a reverse proxy on one network forwards to apps on another, it breaks here (Step 7).
Step 1: Audit every Podman user before you upgrade
Podman state is per user, and root is a separate user, so one check as yourself misses the rest. The script below prints the database backend, network backend and rootless default, then lists every container still on slirp4netns and every config or Quadlet line that Podman 6 rejects. Save it as podman6-preflight.sh:
#!/usr/bin/env bash
# Run once as root (sudo) and once as every user that runs rootless Podman.
export SUPPRESS_BOLTDB_WARNING=1
echo "== $(id -un) =="
echo "cgroups: $(stat -fc %T /sys/fs/cgroup)"
podman info --format 'database: {{.Host.DatabaseBackend}}
network: {{.Host.NetworkBackend}}
rootless net cmd: {{.Host.RootlessNetworkCmd}}'
echo "-- containers on slirp4netns:"
podman ps -aq | xargs -r podman inspect --format '{{.Name}} {{.HostConfig.NetworkMode}}' | grep slirp4netns
echo "-- config and Quadlet files that need editing:"
grep -rnsE 'slirp4netns|firewall_driver *= *"iptables"|network_backend *= *"cni"|database_backend *= *"boltdb"' \
/etc/containers ~/.config/containers /usr/share/containers/systemd 2>/dev/null | grep -v ':[0-9]*: *#'Make it executable and run it for yourself, for root, and for each service account that runs containers. Lingering (loginctl enable-linger) on each account gives sudo -iu a working user runtime directory:
chmod +x podman6-preflight.sh
./podman6-preflight.sh
sudo ./podman6-preflight.sh
sudo cp podman6-preflight.sh ~boltuser/ && sudo chown boltuser ~boltuser/podman6-preflight.sh
sudo -iu boltuser ./podman6-preflight.shOn the test host the rootless user had four slirp4netns containers (one of them the Quadlet), a Quadlet file and a containers.conf default to fix. Root inherited the system-wide iptables drop-in:
The cgroups line should read cgroup2fs. Current systemd no longer boots cgroups v1 at all, so on a Fedora 44 host this is a sanity check, and any other value points at something unusual, such as running the script inside a container. The script exits 1 when the last check finds nothing, which is the result you want. On Podman 5.8, if it is the first Podman command since boot for that user, it also triggers the BoltDB migration described next.
Step 2: Move BoltDB container state to SQLite
BoltDB was the default before Podman 4.8, and Podman 5 refuses to create a new BoltDB database, so a store still on BoltDB almost always dates from Fedora 39 or earlier and was carried forward by upgrades. Check for the old file for each user and for root:
ls ~/.local/share/containers/storage/libpod/
sudo ls /var/lib/containers/storage/libpod/A bolt_state.db file means that store has not been migrated yet. Podman 5.8 also prints a warning on every command while it is in use:
time="2026-09-30T17:28:21Z" level=warning msg="The deprecated BoltDB database driver is in use. This driver will be removed in the upcoming Podman 6.0 release in mid 2026. It is advised that you migrate to SQLite to avoid issues when this occurs by rebooting and running podman again or using the `podman system migrate --migrate-db` command. IMPORTANT, only use that command when you can ensure they will be no parallel podman processes running, if you are unsure do the reboot. Set SUPPRESS_BOLTDB_WARNING environment variable to remove this message."Podman 5.8 migrates the store by itself on the first Podman command after a reboot. On the test host, that first command was the preflight script. The alternative is to run the migration yourself as the affected user, with no other Podman commands running for that user:
podman system migrate --migrate-dbIf the preflight flagged a database_backend="boltdb" line, delete it first, then migrate. Podman 6 refuses to start at all while that line is set, so neither the automatic migration nor --migrate-db can run. We set it for a test account on Fedora 45 to confirm:
Error: the BoltDB database backend was removed in Podman 6.0 - please comment out the `database_backend` line in containers.conf and migrate to SQLite by rebooting the system or using the `podman system migrate --migrate-db` commandThe migration copies the containers and volumes into SQLite and renames the old file instead of deleting it. The output after the same deprecation warning:
$ podman system migrate --migrate-db
Old database has been renamed to /home/bolt2/.local/share/containers/storage/libpod/bolt_state.db-old and will no longer be used
$ podman info --format {{.Host.DatabaseBackend}}
sqlite
$ podman ps -a --format 'table {{.Names}} {{.Status}}'
NAMES STATUS
legacy-app Created
$ podman volume ls -q
olddata2The Fedora change page warns that unmigrated state becomes “unusable” on Podman 6. That did not happen on Podman 6.1.1. On the host upgraded without preparation, the BoltDB user’s first podman ps after the upgrade reboot migrated the store, printed the same rename message, and kept the container and its volume. The container still needed Step 5 because it used slirp4netns. After that it served the file Podman 4 had written into its volume. That depends on the reboot. According to the Podman 6 source (we did not test this case), it only migrates during its first run after boot, and otherwise stops with an error that tells you to reboot or run podman system migrate --migrate-db. A dnf system-upgrade always reboots, so an upgraded host gets the automatic path. Migrate on Fedora 44 anyway: you choose when it happens, and you can check the result while the old release is still installed. Keep bolt_state.db-old until every container for that user has started on Fedora 45.
Step 3: Remove slirp4netns from containers.conf and Quadlet files
Both edits work on Podman 5.8, so make them before the upgrade. Delete the rootless default and Podman falls back to pasta:
sed -i '/^default_rootless_network_cmd=/d' ~/.config/containers/containers.conf
podman info --format '{{.Host.RootlessNetworkCmd}}'Run the same edit on whichever file and line the preflight reported, since the setting can also live in a drop-in directory. The second command should print pasta. Setting the line to default_rootless_network_cmd="pasta" works too, and that is how the host that was not prepared recovered on Fedora 45. Next, switch each Quadlet to pasta. The test unit only had a plain Network=slirp4netns line:
sed -i 's/^Network=slirp4netns/Network=pasta/' ~/.config/containers/systemd/whoami.container
systemctl --user daemon-reload
systemctl --user restart whoami.service
systemctl --user is-active whoami.serviceA Network= line with options, such as slirp4netns:allow_host_loopback=true, needs the pasta equivalent from Step 6, not a plain rename. If you only find the Quadlet after the upgrade, the unit is already in start-limit-hit. Edit the file, then run systemctl --user daemon-reload and systemctl --user reset-failed whoami.service before the start command. reset-failed clears the start-limit-hit state; without it, a start inside the rate-limit window is refused. To see the exact command a Quadlet generates without starting it, use the generator’s dry run:
/usr/libexec/podman/quadlet -user -dryrun | grep ExecStart=For rootful units in /etc/containers/systemd, drop the -user flag (we only ran the rootless form). Quadlet itself does not reject Network=slirp4netns, so the dry run output looks normal. The failure only shows up when Podman runs that command. If Quadlet is new to you, run Podman containers as systemd services with Quadlet covers the file format.
Step 4: Switch netavark back to nftables
Fedora has defaulted netavark to nftables since Fedora 41, so the iptables setting is always a local override. Find it and remove it:
grep -rn firewall_driver /etc/containers/ ~/.config/containers/ 2>/dev/null
sudo rm /etc/containers/containers.conf.d/50-iptables.confThe file name is the one from the test host, so use the path grep gives you. If the line sits in a file with other settings, delete only that line. On the upgraded host, clean up the half-created containers from failed runs, then start the rest:
sudo podman ps -a --filter status=created
sudo podman rm -f rootweb2
sudo podman start rootweb
sudo nft list tablesWith the override gone, netavark programs its rules into its own nftables table:
table inet netavarkIf you pinned iptables so that Docker and Podman could share a host, test that combination after the change. We did not run Docker on this host.
Step 5: Upgrade, then run podman system migrate for each user
Run the release upgrade as usual. The Fedora 44 to 45 upgrade guide covers the GUI and CLI paths and rollback. On the prepared host, the Quadlet was active on first boot, a plain podman run worked, and the rootful container served requests again, about half a minute after the start (the first curl right after it returned nothing). What remained was the containers created with slirp4netns, because we left them for Podman 6 to convert. Podman 6 converts them with one command, run as each affected user:
podman system migrateDo not run this while you are serving traffic. It stops every running container that belongs to the user first, and prints each ID as stopped. A Quadlet container with Restart=always came back on its own. A container started by hand stayed stopped until we ran podman start on it. The command then rewrites every slirp4netns container to pasta and drops any slirp4netns options, with a warning for each container that had them:
Confirm the new mode and start the containers again:
podman inspect web-slirp web-default --format '{{.Name}} {{.HostConfig.NetworkMode}}'
podman start web-slirp web-defaultBoth report pasta, and the published ports answered with HTTP 200 on the test host. Port mappings survive the migration unchanged.
Step 6: Replace the slirp4netns options that migrate drops
The warning in the screenshot is the one to act on. The most common option is allow_host_loopback=true, which let a container reach services bound to the host’s 127.0.0.1 through 10.0.2.2. After the migration that address times out. Podman’s name for the host, host.containers.internal, does not help for loopback-only services either:
$ podman run --rm --network pasta docker.io/library/alpine wget -q -T 3 -O - http://host.containers.internal:9999
wget: can't connect to remote host (169.254.1.2): Connection refusedPasta’s --map-host-loopback option maps an address inside the container to the host’s loopback. Map the old slirp4netns address, and application configs that point at 10.0.2.2 keep working. The network mode of an existing container cannot be changed, so recreate it. --replace deletes the old container, so carry over its original -p, -v and -e options, and anything written to its writable layer instead of a volume is lost:
podman run -d --replace --name web-loop --network pasta:--map-host-loopback,10.0.2.2 docker.io/library/alpine sleep infinity
podman exec web-loop wget -q -T 3 -O - http://10.0.2.2:9999The same value works in a Quadlet file as Network=pasta:--map-host-loopback,10.0.2.2, which we tested on Fedora 45. The podman run form also worked on Podman 5.8, so you can recreate these containers before the upgrade. Mapping the host loopback exposes every service bound to 127.0.0.1 on the host to that container, just as allow_host_loopback did. Give it only to the containers that need it. For other dropped options, map each one to its pasta equivalent in the pasta section of man podman-run.
Step 7: Reconnect containers that talk across networks
Treat network isolation as the new baseline. It closes a path that most setups never meant to leave open. When two containers genuinely need to talk, attach one of them to the other’s network instead of weakening isolation for both networks. This was tested on rootful bridge networks:
sudo podman network connect appnet proxy
sudo podman exec proxy wget -q -T 3 -O /dev/null http://rootweb && echo reachable || echo blockedBefore the connect, proxy on frontnet timed out against rootweb on appnet. Afterwards it reached it by name, because both now share appnet and its DNS. If you really need the old flat behaviour, create the networks with --opt isolate=false. The man page describes that value as the way “to restore the pre-Podman 6 / Netavark 2 behavior”. Both sides need it. A container on an isolate=false network still could not reach one on a default network. Two isolate=false networks could reach each other. podman network update only changes DNS servers, so you cannot add the option to an existing network. You have to recreate the network.
Podman 6 error lookup for Fedora 45 hosts
Every failure from the test upgrade, with where it comes from and the step that fixes it:
| What you see | Cause | Fix |
|---|---|---|
slirp4netns support has been removed, run `podman system migrate` | Existing container created with slirp4netns | podman system migrate as that user (Step 5) |
slirp4netns support has been removed, use --network=pasta instead | Quadlet Network=slirp4netns or a new --network slirp4netns | Edit the Network= line, daemon-reload, reset-failed (Step 3) |
Result: start-limit-hit on a Quadlet unit | The error above, repeated five times | Same as above, then systemctl --user reset-failed |
invalid default_rootless_network_cmd option "slirp4netns" | containers.conf default | Delete the line or set it to pasta (Step 3) |
netavark: Must provide a valid firewall backend, got iptables | firewall_driver="iptables" override | Remove the override, delete Created leftovers (Step 4) |
The deprecated BoltDB database driver is in use (Fedora 44) | Store created before Podman 4.8 | Reboot, or podman system migrate --migrate-db (Step 2) |
dropping slirp4netns options [...] | Migrate removed slirp4netns-only options | Recreate with the pasta equivalent (Step 6) |
Container reaches 10.0.2.2 no more | Dropped allow_host_loopback=true | --network pasta:--map-host-loopback,10.0.2.2 (Step 6) |
| Timeouts between containers on different networks | Netavark 2 default isolate=strict | podman network connect, or recreate with isolate=false (Step 7) |
If a Fedora 45 host shows none of these, run the preflight script there as each user anyway. A clean result means nothing on that host still depends on the removed pieces. For a fresh Fedora 45 setup rather than an upgrade, start from installing Podman on Fedora, where pasta, SQLite and nftables are already the defaults.
