Bug 2123246

Summary: cri-o: run `podman build` failed with "Curl error (6): Couldn't resolve host name"
Product: Red Hat Enterprise Linux 9 Reporter: HuijingHei <hhei>
Component: conmonAssignee: Peter Hunt <pehunt>
Status: CLOSED DUPLICATE QA Contact: atomic-bugs <atomic-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: CentOS StreamCC: bstinson, jwboyer, nalin, pehunt, tsweeney, walters, ypu
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-02-14 15:21:44 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description HuijingHei 2022-09-01 08:38:28 UTC
Description of problem:
Install cri-o(from rhaos repo) and podman, run `podman build -t test .` failed with "Error: Failed to download metadata for repo 'fedora': Cannot prepare internal mirrorlist: Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-36&arch=x86_64 [getaddrinfo() thread failed to start]"

The root cause is that podman build load config `SeccompProfilePath:"/etc/crio/seccomp.json"` from cri-o, according to log from "podman --log-level debug build -t test .", can not reproduce if add option `--security-opt seccomp=unconfined`, there might be some configs in crio which stop container to resolve the dns

Version-Release number of selected component (if applicable):
[core@cosa-devsh ~]$ rpm -q podman runc crun containers-common cri-o
podman-4.1.1-6.el9.x86_64
runc-1.1.3-2.el9.x86_64
crun-1.5-1.el9.x86_64
containers-common-1-40.el9.x86_64
cri-o-1.25.0-48.rhaos4.12.git315a0cb.el9.x86_64

How reproducible:
100%

Steps to Reproduce:
[core@cosa-devsh ~]$ cat Dockerfile 
FROM registry.fedoraproject.org/fedora:36
RUN dnf -y install systemd dnsmasq iproute iputils && dnf clean all && systemctl enable dnsmasq

[core@cosa-devsh ~]$ podman build -t test .
STEP 1/2: FROM registry.fedoraproject.org/fedora:36
Trying to pull registry.fedoraproject.org/fedora:36...
Getting image source signatures
Copying blob 62946078034b done  
Copying config 2ecb6df959 done  
Writing manifest to image destination
Storing signatures
STEP 2/2: RUN dnf -y install systemd dnsmasq iproute iputils && dnf clean all && systemctl enable dnsmasq
Fedora 36 - x86_64                              0.0  B/s |   0  B     00:00    
Errors during downloading metadata for repository 'fedora':
  - Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-36&arch=x86_64 [getaddrinfo() thread failed to start]
Error: Failed to download metadata for repo 'fedora': Cannot prepare internal mirrorlist: Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-36&arch=x86_64 [getaddrinfo() thread failed to start]
Error: error building at STEP "RUN dnf -y install systemd dnsmasq iproute iputils && dnf clean all && systemctl enable dnsmasq": error while running runtime: exit status 1


Actual results:
`podman build` failed

Expected results:
`podman build` works

Additional info:
`podman --log-level debug run -it --rm --name test registry.fedoraproject.org/fedora:36 dnf -y install systemd dnsmasq iproute iputils` works, because it will read config `Loading seccomp profile from "/usr/share/containers/seccomp.json"` which is from containers-common, while podman loads different config when exec build and run, this might be the podman issue which will be tracked by another bug

Comment 1 HuijingHei 2022-09-01 08:41:16 UTC
Not sure this is the right component, feel free to change if not correct

Comment 2 HuijingHei 2022-09-01 10:01:28 UTC
Thanks Yiqiao for the help to find the root cause.

Additional info, can not reproduce on 412.86.202208311537-0
$ rpm -q podman cri-o
podman-4.2.0-1.rhaos4.12.el8.x86_64
cri-o-1.25.0-51.rhaos4.12.git315a0cb.el8.x86_64

Comment 3 Nalin Dahyabhai 2022-09-09 14:14:50 UTC
This is the same as bug #2123251.

Comment 4 HuijingHei 2022-09-09 14:30:42 UTC
(In reply to Nalin Dahyabhai from comment #3)
> This is the same as bug #2123251.

Not quite the same, as can not reproduce with 412.86.202208311537-0, I would say it is a regression issue

Comment 5 Peter Hunt 2022-09-09 14:47:56 UTC
we've recently added a `/etc/crio/seccomp.json` to openshift nodes for cri-o. I would say it's the same root cause: podman and buildah shouldn't be reading that file by default.

Comment 6 HuijingHei 2022-09-13 03:57:30 UTC
Got it, thanks! If in this case, maybe can dup this to bug #2123251.

Comment 7 HuijingHei 2023-02-13 07:05:41 UTC
Verify passed with podman-4.4.0-1.el9.x86_64, podman build read file "/usr/share/containers/seccomp.json"

[core@cosa-devsh ~]$ rpm -q podman cri-o
podman-4.4.0-1.el9.x86_64
cri-o-1.26.1-4.rhaos4.13.gita78722c.el9.x86_64

[core@cosa-devsh ~]$ sudo find /etc/ /usr/ -name "seccomp.json"
/etc/crio/seccomp.json
/usr/etc/crio/seccomp.json
/usr/share/containers/seccomp.json

[core@cosa-devsh ~]$ cat Dockerfile 
FROM registry.fedoraproject.org/fedora:36
RUN dnf -y install systemd dnsmasq iproute iputils && dnf clean all && systemctl enable dnsmasq

[core@cosa-devsh ~]$ podman --log-level debug  build --no-cache -t dnsmasq .
DEBU[0003] Resources: &define.CommonBuildOptions{AddHost:[]string{}, OmitHistory:false, CgroupParent:"", CPUPeriod:0x0, CPUQuota:0, CPUShares:0x0, CPUSetCPUs:"", CPUSetMems:"", HTTPProxy:true, IdentityLabel:0x1, Memory:0, DNSSearch:[]string{}, DNSServers:[]string{}, DNSOptions:[]string{}, LabelOpts:[]string(nil), MemorySwap:0, NoHosts:false, NoNewPrivileges:false, OmitTimestamp:false, SeccompProfilePath:"/usr/share/containers/seccomp.json", ApparmorProfile:"", ShmSize:"65536k", Ulimit:[]string{}, Volumes:[]string{}, Secrets:[]string{}, SSHSources:[]string{}, OCIHooksDir:[]string{}}

Comment 8 HuijingHei 2023-02-14 01:45:40 UTC
Hi Peter, can we close it as the issue is fixed? I am also OK to make it as duplicated, thanks!

Comment 9 Peter Hunt 2023-02-14 15:21:44 UTC
yeah it sounds like this is fixed, we can track it over there

*** This bug has been marked as a duplicate of bug 2123251 ***