Updater failed: Couldn't resolve host 'repo.turris.cz'

UPDATE: This has been fixed for quite a while now.

I’m running the Omnia with the latest updates (5.2.6)

From time to time I’m getting this error:

Updater failed: 

runtime: [string "requests"]:430: [string "utils"]:420: Getting URI (https://repo.turris.cz/hbs/omnia/lists/pkglists/net_monitoring.lua) failed: Couldn't resolve host 'repo.turris.cz'

But if I SSH into my Omnia, pinging that address seems just fine:

root@rawter:~# ping repo.turris.cz
PING repo.turris.cz ( 56(84) bytes of data.
64 bytes from ( icmp_req=1 ttl=55 time=29.5 ms
64 bytes from ( icmp_req=2 ttl=55 time=29.5 ms
64 bytes from ( icmp_req=3 ttl=55 time=26.0 ms

Even getting that file seems to be fine from the CLI:

root@rawter:~# curl https://repo.turris.cz/hbs/omnia/lists/pkglists/net_monitoring.lua
if not version_match or not self_version or version_match(self_version, "<60.0.1") then
        DIE("Minimal required version of Updater-ng for Turris repository is 60.0.1!")

if not board then
        local model = model or os_release["OPENWRT_DEVICE_PRODUCT"] or os_release["LEDE_DEVICE_PRODUCT"]
        if model:match("[Mm]ox") then
                board = "mox"
        elseif model:match("[Oo]mnia") then
                board = "omnia"
        elseif model:match("^[Tt]urris$") or model:match("[Tt]urris ?1%.?x") then
                board = "turris1x"
                DIE("Unsupported Turris model: " .. tostring(model))

-- Script simplifying lists inclusion when older version of updater is used
function list_script(list)
        if features["relative_uri"] then
                Script((repo_base_uri or "https://repo.turris.cz/hbs") .. "/" .. board .. "/lists/" .. list)

-- Our own version of for_l10n to override priority
function for_l10n(fragment)
        for _, lang in pairs(l10n or {}) do
                Install(fragment .. lang, {optional = true, priority = 10})
if features.request_condition then -- Advanced dependencies guard

if options and options.netmetr then
        Install("netmetr", { priority = 40 })

if options and options.dev_detect then
        Install("dev-detect", { priority = 40 })

if options and options.pakon then
        Install("pakon", { priority = 40 })


Also my resolv.conf and nslookups look fine, right?

root@rawter:~# cat /etc/resolv.conf
search lan
root@rawter:~# nslookup example.com

Name:      example.com
Address 1:
Address 2: 2606:2800:220:1:248:1893:25c8:1946
root@rawter:~# nslookup google.com

Name:      google.com
Address 1:
Address 2: 2a00:1450:400e:802::200e

Looking at other threads, I don’t think I have the same issues:

Updater failed: unreachable: https://repo.turris.cz/omnia/lists/base.lua: Couldn't resolve host 'repo.turris.cz' - #8 by Zveela - The Turris Omnia by default ships with a static WAN interface MAC address, no? I haven’t touched its MAC config at least.
Updater fails: unable to resolve host address 'repo.turris.cz' - My /etc/resolv.conf looks pretty normal and in line with a working config.

It also doesn’t look like the ISP Internet was broken since I am testing & logging its operation.

So what could it be?


I’d expect the same cause as (some of) the other reports.

Our latest theory is that DNS may not perform well if you don’t have working IPv6, in combination with some other circumstances/settings. (I don’t know much so far.)

I’ve been getting this for months, usually once or twice each day.

Occasionally also, in the web browser, a DNS resolution fails, even on a site like google.com that should be reliable. I click “Try Again” and it succeeds. I’m guessing that knot sometimes glitches and drops a request or response. Maybe repo.turris.cz is unusually susceptible to this error. Or maybe the turris updater doesn’t retry when DNS resolution fails. Apparently the resolution succeeds frequently enough that I haven’t missed any updates.

My ISP doesn’t support IPv6.

So suppose the updater fails (because of this reason), after what amount of time will it then retry?

I believe the updater runs six times a day.

1 Like

I have the same problem and I also don’t have an IPv6 :upside_down_face:

I had these messages when probably problem with DNS. I enabled DNS forwarding to CZ.NIC and after that looks OK.

Sometimes I get the following error several times a day:

Updater failed:

runtime: [string "requests"]:430: [string "utils"]:422: Unable to finish URI (https://repo.turris.cz/hbs/omnia/lists/pkglists/lxc.lua): Download failed:

There is no problem when I try to download the URL later.

I don’t know if there is a connection with this but I noticed when visiting some websites there are lags during initial page load. No further delays on refresh or loading other pages from the same domain. Seems like some DNS timeouts, haven’t had a chance to take a look closely.

Might be the culprit? My ISP does not support IPv6.

try DNS forwarding in DNS settings in FORIS and use CZ.NIC

Yes. If someone’s case is that IPv6 doesn’t work and the built-in detection misfires, occasionally failing update doesn’t seem to be the most important concern, as DNS resolution would get extra latency (for everything and not just the updater).

In that case, the only helpful setting I know in GUIs is the DNS forwarding option. My personally favorite approach is that disabling IPv6 in (re)Foris WAN tab will also disable attempts to use IPv6 when resolving DNS queries, but that behavior comes with Turris OS 5.3.0 (HBK currently). There’s also another change queued that reduces the latency penalty.

I have IPv6 and forward DNS queries to my ISP, which is known for its reliable and fast DNS service.

But I’m still getting those two or three times a month on each of my routers.


I have the same issue. Also my ISP does not support IPv6 - I have IPv6 disabled on omnia. Still receives this notifications several times a day. When trying to update manually it seems ok.

What is your configuration of option “net_ipv6” in DNS resolver configuration (uci show resolver.common.net_ipv6)?
If it is “1” you can try to switch this option to “0” in /etc/config/resolver:

config resolver ‘common’
option net_ipv6 ‘0’

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.