From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Lepiller Subject: Re: Guix on Android, getaddrinfo, failure in name resolution Date: Tue, 15 Jan 2019 18:24:30 +0100 Message-ID: <7f97029168c04559580e64d55b29ca6e@lepiller.eu> References: <7DD810A8-FBFF-4609-981B-AD6169C384AB@sumou.com> <7A2A3304-5B19-47D6-91A8-960D60294C3B@sumou.com> <52019D8B-FA10-413E-8776-6B594BABFFA1@sumou.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([209.51.188.92]:55550) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gjSaC-00023v-IM for help-guix@gnu.org; Tue, 15 Jan 2019 12:33:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gjSS3-0004I4-KN for help-guix@gnu.org; Tue, 15 Jan 2019 12:24:37 -0500 Received: from lepiller.eu ([2a00:5884:8208::1]:40110) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gjSS3-0004GC-C8 for help-guix@gnu.org; Tue, 15 Jan 2019 12:24:35 -0500 In-Reply-To: <52019D8B-FA10-413E-8776-6B594BABFFA1@sumou.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: =?UTF-8?Q?=E7=99=BD=E3=81=84=E7=86=8A?= Cc: help-guix@gnu.org Le 2019-01-15 18:13, 白い熊 a écrit : > On January 15, 2019 3:30:07 PM UTC, Julien Lepiller > 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 >> configured? > > 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 letsencrypt.org > > 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: 23.38.13.120 letsencrypt.org Whether it works or not will tell us more about where the issue could be. > -- > 白い熊