podman run --rm -it alpine sh (apk update or any egress doesn't work) #7613
Labels
kind/bug
Categorizes issue or PR as related to a bug.
locked - please file new issue/PR
Assist humans wanting to comment on an old issue or PR with locked comments.
Comments
openshift-ci-robot
added
the
kind/bug
|
What is the output of |
And from ubuntu image where things appear to work. |
|
could you try this: |
|
That seems to work. Does that shed some light on the underlying reason for the issue? No issue with ubuntu image, without the --net host. |
|
So I read issue #3277 and a comment suggested adding --dns 10.0.2.3 to the podman run command to force the dns being used, which allowed apk update to pull down the payload from the internet. It seems on my ubuntu host /etc/resolv.conf has nameserver 127.0.0.53 where as my sles15sp2 host which doesn't show this issue doesn't have the dns set to local(127.0.0.53). So unless I uncovered something of value for the podman devs, I think this issue can be closed. Though it still feels a little odd, for someone coming from docker I haven't experienced this issue. Though maybe I should re-test that statement and see if my ubuntu host with docker installed has the same issue. |
|
Are the contents of resolve.conf different based on the image you run?
Podman should always be generating a fresh one, based on the host's and not
the one in the image, so it would surprise me if that was the case.
…On Sat, Sep 12, 2020, 23:30 Bob Henkel ***@***.***> wrote:
So I read issue #3277 <#3277>
and a comment suggested adding --dns 10.0.2.3 to the podman run command to
force the dns being used. Seems there's some dynamic values being added
resolve.conf file that can cause the issue I see.
While this works around my issue, why does this not happen on a ubuntu
image? So far I have it happen on both a debian and alpine image? It would
be nice to have a consistent behavior regardless of the image, assuming the
image hasn't done something odd with dns. As someone coming from docker,
when using docker I have never needed to think about the the dns value in
my docker image based on which image it was. Also this is just general
observation but on podman version 1.8 on sles15sp2 with cgroupsv1 or
cgroupsv2 I didn't see this behavior.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#7613 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB3AOCCA5R4B3UDDNSCBXZ3SFQ4GJANCNFSM4RIMRLPA>
.
|
|
"Are the contents of resolve.conf different based on the image you run?" |
|
could you try this: |
|
|
From my Arch Linux: ~ » podman run --rm -ti docker.io/frolvlad/alpine-glibc sh
/ # cat /etc/resolv.conf
nameserver 10.0.2.3
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888
nameserver 2001:4860:4860::8844
/ #
/ # apk update
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86_64/APKINDEX.tar.gz
ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.12/main: temporary error (try again later)
WARNING: Ignoring APKINDEX.2c4ac24e.tar.gz: No such file or directory
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/community/x86_64/APKINDEX.tar.gz
ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.12/community: temporary error (try again later)
WARNING: Ignoring APKINDEX.40a3604f.tar.gz: No such file or directory
2 errors; 17 distinct packages available~ » podman run --rm -it --net=host alpine sh
/ # cat /etc/resolv.conf
/ # apk update
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86_64/APKINDEX.tar.gz
ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.12/main: temporary error (try again later)
WARNING: Ignoring APKINDEX.2c4ac24e.tar.gz: No such file or directory
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/community/x86_64/APKINDEX.tar.gz
ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.12/community: temporary error (try again later)
WARNING: Ignoring APKINDEX.40a3604f.tar.gz: No such file or directory
2 errors; 14 distinct packages available~ » podman info
host:
arch: amd64
buildahVersion: 1.16.1
cgroupManager: systemd
cgroupVersion: v2
conmon:
package: Unknown
path: /usr/bin/conmon
version: 'conmon version 2.0.21, commit: 35a2fa83022e56e18af7e6a865ba5d7165fa2a4a'
cpus: 8
distribution:
distribution: arch
version: unknown
eventLogger: journald
hostname: user1-nb1
idMappings:
gidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 100000
size: 65536
uidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 100000
size: 65536
kernel: 5.8.12-arch1-1
linkmode: dynamic
memFree: 12956086272
memTotal: 16428888064
ociRuntime:
name: crun
package: Unknown
path: /usr/bin/crun
version: |-
crun version 0.15
commit: 56ca95e61639510c7dbd39ff512f80f626404969
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
os: linux
remoteSocket:
path: /run/user/1000/podman/podman.sock
rootless: true
slirp4netns:
executable: /usr/bin/slirp4netns
package: Unknown
version: |-
slirp4netns version 1.1.4
commit: b66ffa8e262507e37fca689822d23430f3357fe8
libslirp: 4.3.1
SLIRP_CONFIG_VERSION_MAX: 3
swapFree: 2147479552
swapTotal: 2147479552
uptime: 29m 56.03s
registries:
search:
- docker.io
- registry.fedoraproject.org
- quay.io
- registry.access.redhat.com
- registry.centos.org
store:
configFile: /home/user1/.config/containers/storage.conf
containerStore:
number: 0
paused: 0
running: 0
stopped: 0
graphDriverName: overlay
graphOptions:
overlay.mount_program:
Executable: /usr/bin/fuse-overlayfs
Package: Unknown
Version: |-
fusermount3 version: 3.9.3
fuse-overlayfs: version 1.1.0
FUSE library version 3.9.3
using FUSE kernel interface version 7.31
graphRoot: /home/user1/.local/share/containers/storage
graphStatus:
Backing Filesystem: extfs
Native Overlay Diff: "false"
Supports d_type: "true"
Using metacopy: "false"
imageStore:
number: 2
runRoot: /run/user/1000/containers
volumePath: /home/user1/.local/share/containers/storage/volumes
version:
APIVersion: 2.0.0
Built: 1601135437
BuiltTime: Sat Sep 26 17:50:37 2020
GitCommit: 9f6d6ba0b314d86521b66183c9ce48eaa2da1de2
GoVersion: go1.15.2
OsArch: linux/amd64
Version: 2.1.1 |
|
It works now (systemd-resolved.service | /etc/resolv.conf): nameserver 127.0.0.53
options edns0 trust-ad |
|
@dR3b @bobhenkel Can I close this issue then? |
|
@rhatdan |
|
/close |
|
@zhangguanzhang: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
github-actions
bot
added
the
locked - please file new issue/PR
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
I'm running podman run --rm -it debian sh and podman run --rm -it alpine sh with the root account on a ubuntu 20.04 instance. When running alpine and debian images I can't resolve addresses from inside the container, but with the ubuntu image I can. From the host OS I'm able to hit the internet.
From host OS:
Steps to reproduce the issue:
Describe the results you received:
Describe the results you expected:
I was expecting for apk upgrade command to be able to reach the internet and update the packages. The odd thing is
if I do the same with the ubuntu image apt-get update works fine. However if I try with the debian image apt update also fails as it can't resolve.
Additional information you deem important (e.g. issue happens only occasionally):
Happens 100% of the time.
Output of
podman version:Output of
podman info --debug:Package info (e.g. output of
rpm -q podmanorapt list podman):Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?
Yes/Yes
Additional environment details (OpenStack):
The text was updated successfully, but these errors were encountered: