Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Arch not resolving mirrors.kernel.org #2

Open
TheNodi opened this issue Apr 18, 2017 · 5 comments
Open

Arch not resolving mirrors.kernel.org #2

TheNodi opened this issue Apr 18, 2017 · 5 comments

Comments

@TheNodi
Copy link
Owner

TheNodi commented Apr 18, 2017

Arch container on Travis CI doesn't want to resolve mirrors.kernel.org: Job #113.4

I've tried to manually re-sync pacman database (c177f0a) before running any command, but it doen't work either ( Job #114.4 ).

I don't use Arch so I don't know if this is a Travis-related problem or a misconfiguration on the box. It's working on my local system using:

./run-tests arch '--privileged  --volume=/sys/fs/cgroup:/sys/fs/cgroup:ro'
@nickurt
Copy link
Contributor

nickurt commented Apr 18, 2017

Did you tried pacman with the ' --debug' parameter or maybe disabling ipv6 could work?

@TheNodi
Copy link
Owner Author

TheNodi commented Apr 22, 2017

It's a DNS problem, but I don't get the reason of it.
I'm gonna try to rebuild the container with dnsutils and see if I find more information.

IPv6 is disabled

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
4: eth0@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.17.0.2/16 scope global eth0
       valid_lft forever preferred_lft forever

/etc/resolv.conf

search c.travis-ci-prod-2.internal google.internal
nameserver 8.8.8.8
nameserver 8.8.4.4

Pings look fine for the dns servers:

$ ping -c 4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=52 time=0.859 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=52 time=0.355 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=52 time=0.355 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=52 time=0.438 ms
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 0.355/0.501/0.859/0.210 ms

$ ping -c 4 8.8.4.4
PING 8.8.4.4 (8.8.4.4) 56(84) bytes of data.
64 bytes from 8.8.4.4: icmp_seq=1 ttl=52 time=0.814 ms
64 bytes from 8.8.4.4: icmp_seq=2 ttl=52 time=0.471 ms
64 bytes from 8.8.4.4: icmp_seq=3 ttl=52 time=0.422 ms
64 bytes from 8.8.4.4: icmp_seq=4 ttl=52 time=0.505 ms
--- 8.8.4.4 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 0.422/0.553/0.814/0.153 ms

But it doesn't resolve them anyway:

$ ping -c 4 google.com
ping: google.com: Name or service not known

$ ping -c 4 mirrors.kernel.org
ping: mirrors.kernel.org: Name or service not known

$ curl https://google.com
curl: (6) Could not resolve host: google.com

$ curl http://mirrors.kernel.org/
curl: (6) Could not resolve host: mirrors.kernel.org

@cpriego
Copy link
Collaborator

cpriego commented Apr 22, 2017

Leo, should we disable the arch travis build in the meanwhile? I don't know why it doesn't work. I tried it locally and it worked perfectly.

@TheNodi
Copy link
Owner Author

TheNodi commented Apr 23, 2017

I was thinking the same thing. It might be connect to the fact that the base image is the only one which doesn't come from the official docker repository.

I don't have the time to debug it so I'll leave this issue here for anyone who wants to help.

@cpriego
Copy link
Collaborator

cpriego commented Apr 23, 2017

It's already done, I did not disabled it but set it on the allowed failures section so that we can test it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants