Updater fails: unable to resolve host address 'repo.turris.cz'

Dan · March 26, 2018, 6:26pm

Turris is failing updating. In Forris it says (multiple):

Error from 2018/03/26 16:03:19
Updater failed: Unknown error

If I try to start the updater manually, I get an “unreachable” error:

unreachable: https://repo.turris.cz/omnia/lists/base.lua: Couldn't resolve host 'repo.turris.cz'

But the source is accessible via the browser. When I read the header from Turris via wget, I get the following error:

root@turris:~# wget -d https://repo.turris.cz/omnia/lists/base.lua
DEBUG output created by Wget 1.18 on linux-gnu.

Reading HSTS entries from /root/.wget-hsts
Converted file name 'base.lua' (UTF-8) -> 'base.lua' (ASCII)
--2018-03-26 20:19:43--  https://repo.turris.cz/omnia/lists/base.lua
Resolving repo.turris.cz... failed: Try again.
wget: unable to resolve host address 'repo.turris.cz'

Is it me or is there a problem?

Big_boss · March 28, 2018, 6:56am

Could you post the output of this command.

cat /etc/resolv.conf

Dan · April 3, 2018, 5:05pm

I’m sorry for my late answer. I’ve been busy for a few days.

The problem still seems to exist. The content of cat /etc/resolv.conf looks like this:

nameserver 127.0.0.1

The funny thing is that when I use wget, The target is reachable.

Any ideas?

Big_boss · April 3, 2018, 5:30pm

REMOVED THIS HARMFULL comment. Please read the comment below.

Big_boss · April 10, 2018, 9:21am

@Dan @MiKe

Guys, and everybody else who read this topic, please undo the action i advised previously. By replacing the resolv.conf every minute, i TOTALLY FORGET about the continuously writing the eMMC…which is a BAD thing.

I have now tried a different approach not sure if it is gonna hold for now, but copied the resolv.conf to my m.SATA partition and made a new option to use that resolv.conf in the /etc/config/dhcp under dnsmasq

config dnsmasq
        option domainneeded '1'
        option boguspriv '1'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option localservice '1'
        option nonwildcard '0'
        option port '0'
        list server '8.8.8.8'
        list server '8.8.4.4'
        option logqueries '1'
        option resolvfile '/mnt/LXC/backup/resolv.conf'

Dan · April 21, 2018, 12:04pm

Thank you. But unfortunately, that doesn’t solve my problem.

Can anyone help on this? nslookup fails as well:

root@turris:~# nslookup google.de
nslookup: can't resolve '(null)': Name does not resolve

I’m using a local DNS server (Raspberry Pi), so ot seems to be related, but I can’t find the cause.

vcunat · April 21, 2018, 4:49pm

This line from nslookup is a bug in nslookup itself (busybox). It will also ignore parameter setting which server to ask.

Dan · April 23, 2018, 6:32pm

Still no soluition.

dhempling · April 24, 2018, 1:26am

No word yet from support? It is odd. Just started having this issue, myself.

repo,turris.cz resolves to the same IP as forum.turris.cz. My home network can’t resolve those two host addresses but can resolve everything else. It’s like TO’s are in revolt against turris.cv.

Dan · April 24, 2018, 7:36am

Do you also use an external DNS? I’m using Pi-Hole as DNS in my local network. I think it’s a configuration thing, but unfortunately I can’t find the solution.

dhempling · April 24, 2018, 8:32am

Up to this point, my TO’s used the DNS provided by my ISP and machines on my network deferred to the TO. It’s only now that I’ve had to slip in “nameserver 8.8.8.8”.

Pepe · April 24, 2018, 9:24am

Hello,

No word yet from support? It is odd. Just started having this issue, myself.

I’d need to repeat this:
The forum is not intended to request support, because

It’s really hard to find and track bugs
when the thread has many posts
when the users are reviving topics, which are old (usually 3 months and more)
when it’s related to an old version and the issue is and should be fixed in a newer release
Diagnostics or some information are sensitive, which shouldn’t be upload to any public file hosting server and in the worst case to the cloud.

Our former CM said this:

The forum is mainly for reasons of mutual cooperation between the community and the possibility of mass addressing. We have never guaranteed answer/support here on the forum. We’re trying to improve our support on the forum, but it won’t be right now.

We’re primarily looking at issues in Community office, where you can find notifications about new releases including RC and we appreciate every feedback.

If you have any issues, which belongs to the support then we’re available on email address tech.support@turris.cz

Known bugs can be split into

Short-term issues, which will be fixed in the next release and which you can find in our documentation
Turris Documentation
Long-term issues, which won’t be fixed soon and we know about them:
Turris Documentation

Anyway 2 posts above yours you can see that Dan replied:

I’m using a local DNS server (Raspberry Pi), so it seems to be related, but I can’t find the cause.

It’s really hard to find the cause, where we don’t have details or any information about what can be wrong until a few minutes ago we at least know that he uses Pi-Hole, but we’d need more details as I said because from @Dan replies I see that DNS resolving doesn’t work.
Keep in mind that this is not supported, because we can’t provide support when somebody interferes with DNS traffic (Pi-Hole and so on), but what I can do as one-time courtesy is to bring some SBC to work on which I will try it and will look, where the problem could be.

Maybe @Dan can tell me if he has enabled DNSSEC at Foris or if he followed some article, which he found on the internet and which version of Turris OS he has. And as you can see it seems that you have a different issue than @Dan, which doesn’t help to this thread, because in this thread we have two different issues.

Anyway, thanks for email and I’ll look into it!

Dan · May 12, 2018, 3:10pm

Hi @Pepe

Thank you for your reply.

First of all I would like to apologize for the bad communication and the missing information. I am well aware that this is not an official support are, but it is still a chance to get help from other people with more know-how than I have… I also think that the information may help others. And I continue to believe that this is a misconfiguration on my side.

I only run the Turris Omnia as DHCP and use a Raspberry Pi (Pi-Hole) for DNS. The DNS is announced via DHCP option 6.

192.168.1.1 Turris
192.168.1.2 Pi-Hole

No DNSSEC. Turris version 3.9.6 and Kernel 4.4.119.

I really appreciate the help and I didn’t want to give the impression that I am demanding support here! I was hoping for the expertise of other users. If there is experience from the Turris Team, maybe from other users who run a similar setup, and you can pass it on, then I am very grateful for it.

Is there other information that can help?

Big_boss · May 13, 2018, 8:03am

I now also experienced the same problem. I created a workaround by pinging repo.turris.cz then get the ipaddress and create a new line in the hosts file of the Omnia.

As it has some issue with the DNS, it also cannot resolve repo.turris.cz, so now by manually editing your hosts-file and creating a line where you direct the repo.turris.cz to the ipaddress yourself it can now resolve it. This off course is a temporary solution until a new firmware update has appeared that fixes this problem.

If you do not use this workaround or any workaround you off course also would not be able to update to latest version of Turris-OS as it needs to resolve the dns. I hope that this can also help you right now.

Dan · May 13, 2018, 12:45pm

I just made a static host entry.

217.31.192.69   repo.turris.cz

I was able to upgrade my Turris Omnia to 3.10. Now I just need to know the target for sending uCollect and Firewall data for additional host entries. Otherwise I’ll deativate this services…

Of course this is no propper way and doen’t solve my problem, but for the moment it works.

Zveela · August 5, 2018, 1:49pm

Hello,
I have got the same issue while trying to get my Omnia turris even going.
I have flashed to the newest version with USB

root@turris:~# cat /etc/turris-version
3.10.3

Windows 10, Provider is NetBox in Brno - I kind of think that might be the cause

These are the errors I have so far, trying different methods found here on the forum.

This is on my basic settings page

Aktualizace z 05. 08. 2018 14:57:29
Updater failed: 

unreachable: https://repo.turris.cz/omnia/lists/base.lua: Couldn't resolve host 'repo.turris.cz'

Error on LuCi - package download

curl: (6) Couldn't resolve host 'repo.turris.cz'
curl: (6) Couldn't resolve host 'repo.turris.cz'
curl: (6) Couldn't resolve host 'repo.turris.cz'
curl: (6) Couldn't resolve host 'repo.turris.cz'
curl: (6) Couldn't resolve host 'repo.turris.cz'
curl: (6) Couldn't resolve host 'repo.turris.cz'
curl: (6) Couldn't resolve host 'repo.turris.cz'
curl: (6) Couldn't resolve host 'repo.turris.cz'
curl: (6) Couldn't resolve host 'repo.turris.cz'
curl: (6) Couldn't resolve host 'repo.turris.cz'
curl: (6) Couldn't resolve host 'repo.turris.cz'
Collected errors:
 * opkg_download: Failed to download https://repo.turris.cz/omnia/packages//base/Packages.gz, curl returned 6.
 * file_move: Failed to rename /tmp/opkg-gihjaI/Packages.gz to /var/opkg-lists/omnia_base: No such file or directory.
 * opkg_download: Failed to download https://repo.turris.cz/omnia/packages//hardware/Packages.gz, curl returned 6.
 * file_move: Failed to rename /tmp/opkg-gihjaI/Packages.gz to /var/opkg-lists/omnia_hardware: No such file or directory.
 * opkg_download: Failed to download https://repo.turris.cz/omnia/packages//lucics/Packages.gz, curl returned 6.
 * file_move: Failed to rename /tmp/opkg-gihjaI/Packages.gz to /var/opkg-lists/omnia_lucics: No such file or directory.
 * opkg_download: Failed to download https://repo.turris.cz/omnia/packages//management/Packages.gz, curl returned 6.
 * file_move: Failed to rename /tmp/opkg-gihjaI/Packages.gz to /var/opkg-lists/omnia_management: No such file or directory.
 * opkg_download: Failed to download https://repo.turris.cz/omnia/packages//openwisp/Packages.gz, curl returned 6.
 * file_move: Failed to rename /tmp/opkg-gihjaI/Packages.gz to /var/opkg-lists/omnia_openwisp: No such file or directory.
 * opkg_download: Failed to download https://repo.turris.cz/omnia/packages//packages/Packages.gz, curl returned 6.
 * file_move: Failed to rename /tmp/opkg-gihjaI/Packages.gz to /var/opkg-lists/omnia_packages: No such file or directory.
 * opkg_download: Failed to download https://repo.turris.cz/omnia/packages//php/Packages.gz, curl returned 6.
 * file_move: Failed to rename /tmp/opkg-gihjaI/Packages.gz to /var/opkg-lists/omnia_php: No such file or directory.
 * opkg_download: Failed to download https://repo.turris.cz/omnia/packages//printing/Packages.gz, curl returned 6.
 * file_move: Failed to rename /tmp/opkg-gihjaI/Packages.gz to /var/opkg-lists/omnia_printing: No such file or directory.
 * opkg_download: Failed to download https://repo.turris.cz/omnia/packages//routing/Packages.gz, curl returned 6.
 * file_move: Failed to rename /tmp/opkg-gihjaI/Packages.gz to /var/opkg-lists/omnia_routing: No such file or directory.
 * opkg_download: Failed to download https://repo.turris.cz/omnia/packages//telephony/Packages.gz, curl returned 6.
 * file_move: Failed to rename /tmp/opkg-gihjaI/Packages.gz to /var/opkg-lists/omnia_telephony: No such file or directory.
 * opkg_download: Failed to download https://repo.turris.cz/omnia/packages//turrispackages/Packages.gz, curl returned 6.
 * file_move: Failed to rename /tmp/opkg-gihjaI/Packages.gz to /var/opkg-lists/omnia_turrispackages: No such file or directory.

Same as with OPKG update

root@turris:~# opkg update
Downloading https://repo.turris.cz/omnia/packages//base/Packages.gz
curl: (6) Couldn't resolve host 'repo.turris.cz'
*** Failed to download the package list from https://repo.turris.cz/omnia/packages//base/Packages.gz

I thought it might be certificate as well, but with no succes either

root@turris:~# wget http://repo.turris.cz/omnia/packages/base/ca-certificates_20170717_mvebu.ipk
--2018-08-05 15:47:14--  http://repo.turris.cz/omnia/packages/base/ca-certificates_20170717_mvebu.ipk
Resolving repo.turris.cz... failed: Try again.
wget: unable to resolve host address 'repo.turris.cz'

Please advise. Tell me what information you need from me, i will try to proide it at my best. I am kind of lost here. Thanks for any help

-Peter

Pex · August 10, 2018, 12:22pm

I got the same problem since a while and was wondering what happened.
Did a reboot with an image-backup from before, but got still the same problem.
But i recognized, that some SecureDNS were not working properly. Couldnt reach the internet (every 5 mins up to some hours randomly) by using DNS from my ISP. Added some more SecureDNS on luci and at least the connectivity since yesterday seems to work. Not testet at all whether it works with the updater, but i guess that could be the solution.

saltcafe · August 23, 2018, 7:01pm

here is what I had on my router today … after upgrading overnight to the latest and greatest version of Omnia software.

the updater can’t reach the host:

the DNS diagnostics shows that everything is fine:

and I have the latest version of Omnia software installed:

cynerd · August 24, 2018, 7:14am

This is caused by temporally Internet access outage. Most probably your ISP was at night maintaining its infrastructure. There is no problen with router it self.

Dan · August 24, 2018, 7:34am

In my case, I still think it’s a configuration problem of me and not a bug in Turris OS. For me the problem with the static host entry is solved. Possibly users with this kind of problem should open their own thread to get individual support*.

* I know this isn’t a support forum