fedora-silverblue / issue-tracker

Fedora Silverblue issue tracker
https://fedoraproject.org/atomic-desktops/silverblue/
125 stars 3 forks source link

slirp4netns package missing in F40 base commit #547

Closed tcitworld closed 2 months ago

tcitworld commented 3 months ago

Describe the bug I'm trying to run a specific docker container with docker start, which outputs this

Error: unable to start container "7df5ccd4631ccbfbdccafac4aec785f0088686bba5337426cf5b17c36422683b": could not find slirp4netns, the network namespace can't be configured: exec: "slirp4netns": executable file not found in $PATH

The slirp4netns package is indeed not installed in the F40 current base commit, though it was in F39

rpm-ostree db list 708458ed3af814de6ec901e9e04872bb83c9ed8dbedcab42fd0943badce68809 | grep slirp4netns

Returns nothing

rpm-ostree db list 8b2ab1dc8e53e928d23de9ed3be548c0338c3dec3fcb1c28b1caa0df70b35b7f | grep slirp4netns
 slirp4netns-1.2.2-1.fc39.x86_64

Returns the package name.

Adding slirp4netns as a layered package allows to run the container properly.

To Reproduce Please describe the steps needed to reproduce the bug:

  1. docker start $container

Expected behavior The package being installed and docker start executing

OS version:

State: idle
AutomaticUpdates: check; rpm-ostreed-automatic.timer: no runs since boot
BootedDeployment:
● fedora:fedora/40/x86_64/silverblue
                  Version: 40.20240403.n.0 (2024-04-03T08:15:05Z)
               BaseCommit: 708458ed3af814de6ec901e9e04872bb83c9ed8dbedcab42fd0943badce68809
             GPGSignature: Valid signature by 115DF9AEF857853EE8445D0A0727707EA15B79CC
      RemovedBasePackages: noopenh264 0.1.0~openh264_2.4.0-1.fc40
          LayeredPackages: abrt abrt-desktop distrobox ffmpegthumbnailer fido2-tools git gnome-abrt gnome-console gnome-tweak-tool google-noto-sans-bamum-fonts gstreamer1-plugin-openh264 gstreamer1-plugins-bad-free-extras gstreamer1-vaapi htop
                           intel-media-driver langpacks-fr libavcodec-freeworld libva-intel-driver libva-utils mozilla-openh264 nextcloud-client-nautilus openh264 openssl pam-u2f pamu2fcfg pipewire-codec-aptx podman-compose podman-docker
                           rpmfusion-free-release rpmfusion-nonfree-release simple-scan smartmontools solaar teamviewer vim zsh
francoism90 commented 2 months ago

Same bug here, this is still needed also for Podman: https://github.com/containers/podman/issues/22044#issuecomment-2009255504

DNS is not working at all for rootless containers on F40.

travier commented 2 months ago

This looks a lot like https://github.com/coreos/fedora-coreos-tracker/issues/1704

travier commented 2 months ago

See also https://blog.podman.io/2024/03/podman-5-0-breaking-changes-in-detail/

Luap99 commented 2 months ago

I think it would be a good idea to add slirp4netns back, I forgot to mentioned the case for older containers in the blog (I will update it). The reason is rootless containers created with podman 4.X and older (assuming default network option) will continue to use slirp4netns, the new default pasta will only take effect for newly created containers. For regular fedora we changed it to suggests as it is no longer required on a new installs and we assume that slirp4netns will still be installed after a dnf system-upgrade so we did not see any upgrade issues for that, of course with rpm-ostree it works differently so I would suggest to make sure it is added to avoid breaking existing rootless containers.

francoism90 commented 2 months ago

@Luap99 Can you convert to pasta?

I'm new to Podman, so I assume podman network rm name, and recreate is enough, right? :)

It's weird switching back fixed the issue, so hopefully it will all be solved soon.

If you need more testing or debug info, let me know.

Thanks!

Luap99 commented 2 months ago

if you use named networks then it uses whatever is configured (default_rootless_network_cmd, pasta by default) although you will need to stop all containers to apply that on the next start for the rootless-netns.

I was specifically talking about the default --network=slirp4netns (4.X) vs --network=pasta (5.0)

travier commented 2 months ago

We had a similar discussion in https://github.com/fedora-silverblue/issue-tracker/issues/246 when that happen for containernetworking-plugins.

I'm not opposed to adding it back (although it's a bit late for the F40 release, but it can land in an update after) but then we need to plan for removing it in the future.

travier commented 2 months ago

Ideally we would file a bug for https://bodhi.fedoraproject.org/updates/FEDORA-2024-4d3ddadf4d and ask for it to be a blocker for F40, but as it's ready, it will land on the first update right after the release.

dustymabe commented 2 months ago

You can at least file it as FE: https://qa.fedoraproject.org/blockerbugs/milestone/40/final/buglist

travier commented 2 months ago

I've filed https://bugzilla.redhat.com/show_bug.cgi?id=2274195 and submitted as a Freeze Exception.

Luap99 commented 2 months ago

I've filed https://bugzilla.redhat.com/show_bug.cgi?id=2274195 and submitted as a Freeze Exception.

I think this is fine but I do not see how this is relevant for this specific issue here. Existing containers will not work because slirp4netns is missing is what the original report here is and this is not going to change with a passt update.

travier commented 2 months ago

Agree, my comments are a bit off topic.

travier commented 2 months ago

I'll make a PR to add slirp4netns back until it's fully deprecated / unsupported in podman.

travier commented 2 months ago
travier commented 2 months ago

I merged both PRs so this should be fixed in the next update (likely tomorrow)