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

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 (217.31.192.84) 56(84) bytes of data.
64 bytes from 217.31.192.84 (217.31.192.84): icmp_req=1 ttl=55 time=29.5 ms
64 bytes from 217.31.192.84 (217.31.192.84): icmp_req=2 ttl=55 time=29.5 ms
64 bytes from 217.31.192.84 (217.31.192.84): icmp_req=3 ttl=55 time=26.0 ms
^C

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!")
end

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"
        else
                DIE("Unsupported Turris model: " .. tostring(model))
        end
end

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

-- 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})
        end
end
----------------------------------------------------------------------------------
if features.request_condition then -- Advanced dependencies guard

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

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

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

end

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

root@rawter:~# cat /etc/resolv.conf
search lan
nameserver 127.0.0.1
root@rawter:~# nslookup example.com
Server:         127.0.0.1
Address:        127.0.0.1#53

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

Name:      google.com
Address 1: 142.250.179.174
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?

1 Like

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