[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guix on Android, getaddrinfo, failure in name resolution

From: Julien Lepiller
Subject: Re: Guix on Android, getaddrinfo, failure in name resolution
Date: Tue, 15 Jan 2019 18:24:30 +0100
User-agent: Roundcube Webmail/1.3.8

Le 2019-01-15 18:13, 白い熊 a écrit :
On January 15, 2019 3:30:07 PM UTC, Julien Lepiller <address@hidden> wrote:

Well, if it's a name resolution issue, the first culprit that comes to
mind is /etc/resolv.conf. Do you have that file, and is it correctly

Yes indeed, I have it copied from /system/etc/ and it just has the two
Google nameservers, so that's working.

Maybe it's an selinux thing? You can try with "setenforce 0" and see if that solves the issue. I've had some troubles with selinux too, related
to file-system permissions though.

Yes, I have selinux set to Permissive — without this there's big
problems with permissions. So that should be fine as well…

One thing now that I'm thinking — looking at the error output — could
this be somehow associated with https ufiticil? I see that all the
files from all the substitutes “guix pull” is trying to download are
from https:// locations. The first item that it's trying to download
for the update are certificates from

Could it be that hostnames are resolved fine — which they are, as I
can ping successfully any of the sites it's trying to access — but not
the https:// locations?

If you use ping from the system (android), it uses bionic, which guix
doesn't use. You have to test with a tool that uses glibc.

Is this possible? Can it be tested? I don't think you can nslookup or
whatever an https:// location right? What if guix can't access secure
sites? Is that possible?

I don't think it's possible: nslookup doesn't care about the protocol
that's going to be used, it only needs the domain part. Maybe you can
try to check that you can actually access the name servers?

If that doesn't work, as a workaround, you can resolve the names that
guix tries to reach, and put this in /etc/hosts:

Whether it works or not will tell us more about where the issue could be.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]