On Fri, Dec 09, 2022 at 01:11:39PM +1000, onefang wrote:
> On 2022-12-08 07:42:04, Hendrik Boom wrote:
> > Aptitude gives me this message when I try to update my package list:
> >
> > Temporary failure resolving 'deb.devuan,org'
> >
> > Now I know that deb.devuan.org is a stand-in for many mirrors.
> >
> > But if I've been directed to a dud mirror, shouldn't dns resolution
> > still work but leave me waiting for the chosen mirror to respond?
> >
> > Repeating the operation just repeats the message.
> >
> > (1) So is something wrong with the dns resolution for deb.devuan.org?
> > Doing dig deb.devuan.org gives me a nice list of mirrors.
> >
> > (2) Or is aptitude giving me a misleading message?
>
> Sounds a bit odd, but yeah sounds like something odd with DNS at your end.
>
> > In any case, repeating the operation just repeats the message, so it's presumably not giving me a new mirror. Or maybe my dns resolver has cached the broken one.
> >
> > Is there some way to ask for a change of mirror? Or clear that cache?
>
> https://pkgmaster.devuan.org/mirror_list.txt gives you a list of mirrors
> you can choose from manually. Then update /etc/sources.list with your
> chosen mirror.
>
> > Panopticon lists a few failed mirrors and many working ones. Presumably as usual.
>
> You need to check which column the errors are under. Most of the time
> it's the same mirrors failing the URL sanity check. Coz they have not
> been convinced to fix something I have no idea how you manage to break.
>
> Also check the DNS round robin column, those with a green tick there are
> part of deb.devuan.org, and you'll notice none of those have errors most
> of the time. Those that do get errors probably still have the green tick
> coz it's a temporary error, or I haven't noticed and it's still amanual
> process. We have plans to automate things, but life is getting in the
> way for me all the time. lol
>
> Hover over the column headings for a short explanation of each test.
>
> > -- hendrik
> >
> > P.S. running a recent, but not completely up-to-date chimaera.
>
> --
> A big old stinking pile of genius that no one wants
> coz there are too many silver coated monkeys in the world.
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
I managed to do an upgrade *WITHOUT* changing /etc/apt/sources.list
More clues.
(i) connman seems to have taken over my local DNS lookup. The command
lsof -i :53 -S
gives a lot of entries, all of which have connmand in the COMMAND column/
What's more, the /etc/resolv.conf contains
# Generated by Connection Manager
nameserver ::1
nameserver 127.0.0.1
so that all DNS queries will be directed to locol host, where connmand
eats them up.
When I edit /etc/resolv.com so that it instead requests
nameserver 8.8.8.8
atitude's update and ugrde work properly, except that somethin in the
process sets /etc/resolv.confback to connmand's preferred settings.
So it looks like connman is a potential culprit.
But wait! My VDSL modem has local IP number 192.168.1.1.
If I set
nameserver 192.168.1.1
I have the same old Temporary failure resolving 'deb.devuan.org'
message.
So in addition to connman monopolising DNS activity, it looks as if
the VDSL modem also likes to fixate on one faulty devuan mirror.
SO, presumably, there are two places that might be caching the IP number
Devuan's name servers give me: the connman demon and the VDSL modem.
-- hendrik
::
[DNG] WORKAROUND and FURTHER CLUES …
