Description of problem: In F39, my containers worked fine. After upgrading to F40: $ podman start blockerbugsdb Error: unable to start container "7f58781009b1a5216fb3003d4d119e7acc1c6f5e3e0faeb2e7d2707ac989e758": could not find slirp4netns, the network namespace can't be configured: exec: "slirp4netns": executable file not found in $PATH This is resolved by installing slirp4netns-1.2.2-2.fc40.x86_64. There seems to be a missing dependency in the podman package. Version-Release number of selected component (if applicable): podman-5.0.1-1.fc40.x86_64 How reproducible: always (in my case) Steps to Reproduce: 1. just try to start a container (possibly already existing after an upgrade from F39, not sure if it's needed or not)
This doesn't affect my Toolbx containers, they can be started just fine (even through "podman start"). So there's some difference between toolbx containers and my blockerbugsdb container (containing a postgres instance) which makes it affected by this issue.
How did you upgrade? Is this a dnf based or rpm-ostree based fedora install? Podman 5.0 changed the default to rootless networking tool to pasta (package passt) so slirp4netns is no longer installed by default as it is not strictly needed. New containers will use pasta by default. However existing containers will continue to use slirp4netns so it is still needed for upgrades. Toolbx works because it uses --network host.
This was a `dnf system-upgrade` of Fedora 39 Workstation (to 40). Looking at the log, slirp4netns was present on F39 and got up upgraded, and *would have worked* in F40. But after the system-upgrade, I ran `dnf autoremove`, which removed slirp4netns as no longer needed. Which is correct, in a sense (for new containers, it's not). So, hm, I guess this is WONTFIX? The unfortunate thing is that people who have existing containers and run "dnf autoremove" after the upgrade will hit this issue. But I don't see a way how to avoid it.
I am not sure how dnf autoremove works but we still have slirp4netns as a "Suggests" in the spec. If autoremove doesn't take that into account that yes this is likely a wontfix.
"Hints are by default ignored by dnf" https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/#_hints If you want the weak dependency to have any effect through dnf, you need to use Recommends instead of Suggests. I haven't tested it (I'd have to rebuild the packages), but I assume that would have prevented "dnf autoremove" from removing slirp4netns.
Well we do not want to install slirp4netns on new systems as it is not needed unless a user explicitly configures that so it making Recommends would defeat that purpose IMO but I am NOT a packager.
I see. In that case, unless there's some nice packaging trick available, I think those are basically two conflicting goals - not have it installed by default, but don't remove it by dnf autoremove after upgrade.
(In reply to Kamil Páral from comment #1) > This doesn't affect my Toolbx containers, they can be started just fine > (even through "podman start"). So there's some difference between toolbx > containers and my blockerbugsdb container (containing a postgres instance) > which makes it affected by this issue. Toolbx containers don't use a network namespace. They are created with: podman create --network host ...
(In reply to Kamil Páral from comment #7) > I see. In that case, unless there's some nice packaging trick available, I > think those are basically two conflicting goals - not have it installed by > default, but don't remove it by dnf autoremove after upgrade. Isn't Suggests a convenient middle ground then? Not made available by default, won't get used on server and envs that ignore weak deps. And will hopefully get removed entirely after a few podman releases. WDYT?
Lokesh, Suggests is basically a no-op. It doesn't do anything (anywhere, not just in environments with install_weak_deps=False, dnf doesn't act on it even with install_weak_deps=True), and users don't know about it (dnf doesn't show it). So it achieves the first goal, and doesn't achieve the second one. I'm not aware of any "middle-ground" solution available.
Closing this as WONTFIX. I'll make a doc update at https://github.com/containers/podman.io/blob/main/docs/installation.md#fedora