You are not logged in.
Pages: 1
Hello,
since a few days "apt update" no longer works, meaning deb.devuan.org does not respond to apt update, and to ping neither.
All other update repos do work normally.
I have modified sources.list to make it work.
fr.deb.devuan.org, ch.deb.devuan.org, de.deb.devuan.org, us.deb.devuan.org all work well.
Is there something wrong?
Offline
Hello:
... something wrong?
No, at least not where I am:
~$ date
Wed Sep 11 12:37:42 -03 2024
~$
~$ sudo apt update
---- snip ---
Get:1 http://deb.devuan.org/merged daedalus InRelease [43.0 kB]
Get:2 http://deb.devuan.org/merged daedalus-updates InRelease [33.4 kB]
Get:3 http://deb.devuan.org/merged daedalus-security InRelease [33.2 kB]
Get:4 http://deb.devuan.org/merged daedalus/main i386 Packages [8931 kB]
Get:5 http://deb.devuan.org/merged daedalus/main amd64 Packages [9043 kB]
Get:6 http://deb.devuan.org/merged daedalus-updates/main i386 Packages [2488 B]
Get:7 http://deb.devuan.org/merged daedalus-updates/main amd64 Packages [2492 B]
Fetched 18.1 MB in 7s (2663 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
1 package can be upgraded. Run 'apt list --upgradable' to see it.
~$
Also, have a look here.
May have to do with connman, dnsproxy and how they interact.
Best,
A.
Last edited by Altoid (2024-09-11 15:48:11)
Offline
Just checked and could post the same as @Altoid.
You might try:
deb http://us.deb.devuan.org/merged ...
Offline
I just checked to see if it's being blocked at the DNS level, and there's no problem here.
$ nslookup deb.devuan.org
Server: 192.168.4.1
Address: 192.168.4.1#53
Non-authoritative answer:
deb.devuan.org canonical name = deb.rr.devuan.org.
Name: deb.rr.devuan.org
Address: 131.188.12.211
Name: deb.rr.devuan.org
Address: 147.78.194.22
Name: deb.rr.devuan.org
Address: 195.85.215.180
Name: deb.rr.devuan.org
Address: 103.146.168.12
Name: deb.rr.devuan.org
Address: 95.216.15.86
Name: deb.rr.devuan.org
Address: 200.236.31.1
Name: deb.rr.devuan.org
Address: 46.4.50.2
Name: deb.rr.devuan.org
Address: 130.225.254.116
Name: deb.rr.devuan.org
Address: 141.84.43.19
Name: deb.rr.devuan.org
Address: 190.64.49.124
Name: deb.rr.devuan.org
Address: 160.16.137.156
Name: deb.rr.devuan.org
Address: 185.178.192.43
Name: deb.rr.devuan.org
Address: 198.58.118.8
Name: deb.rr.devuan.org
Address: 125.228.189.120
Name: deb.rr.devuan.org
Address: 94.16.114.15
Name: deb.rr.devuan.org
Address: 185.236.240.103
Name: deb.rr.devuan.org
Address: 106.178.112.231
Name: deb.rr.devuan.org
Address: 5.161.180.234
Name: deb.rr.devuan.org
Address: 67.219.104.166
Name: deb.rr.devuan.org
Address: 202.61.197.17
Name: deb.rr.devuan.org
Address: 185.183.113.131
;; Truncated, retrying in TCP mode.
Name: deb.rr.devuan.org
Address: 2800:a8:c001::a
Name: deb.rr.devuan.org
Address: 2001:e42:102:1704:160:16:137:156
Name: deb.rr.devuan.org
Address: 2a03:4000:28:24c::
Name: deb.rr.devuan.org
Address: 2a0d:eb00:8006::acab
Name: deb.rr.devuan.org
Address: 240b:10:f00:1b00::240
Name: deb.rr.devuan.org
Address: 2a01:4ff:f0:dd3a::1
Name: deb.rr.devuan.org
Address: 2401:c080:2000:229e:4b70:fe82:36ed:f788
Name: deb.rr.devuan.org
Address: 2a03:4000:59:123:68cc:97ff:fee1:c81
Name: deb.rr.devuan.org
Address: 2001:638:a000:1021:21::1
Name: deb.rr.devuan.org
Address: 2a0a:e5c0:10:3::6eeb
Name: deb.rr.devuan.org
Address: 2a01:9e40::180
Name: deb.rr.devuan.org
Address: 2407:b6c0::12
Name: deb.rr.devuan.org
Address: 2a01:4f9:2a:fa9::2
Name: deb.rr.devuan.org
Address: 2801:82:80ff:8000::2
Name: deb.rr.devuan.org
Address: 2a01:4f8:140:1102:2b76:955d:b48f:bdf3
Name: deb.rr.devuan.org
Address: 2001:878:346::116
Name: deb.rr.devuan.org
Address: 2001:4ca0:4300::1:19
Try using deb.rr.devuan.org instead.
Online
Thank you all for your response.
Using deb.rr.devuan.org works perfectly well, as do all (most) other mirrors as well.
deb.devuan.org remains blocking, wondering why.
@Altoid: I have no connman and no dnsproxy installed, I always use the standard network-manager as it comes with the Cinnamon-environment.
Anyway, thank you for your kind help.
Have a good day!
Andre
Offline
For a long time I have found that this happens rather frequently and it is a pain in the backside, so choose a mirror, e.g.,
deb http://devuan.sedf.de/merged daedalus-security main
deb http://devuan.sedf.de/merged daedalus-updates main
deb http://devuan.sedf.de/merged daedalus main
Other pains include not having testing netinstall iso's.
Offline
My almost-always-painless update process glitched today with a 404 when it tried to get the DEB. Immediately re-ran the (self-written) bash-file & it performed perfectly.
Offline
Hello:
deb.devuan.org remains blocking ...
Still good here:
~$ date
Thu Sep 12 07:07:39 -03 2024
~$
~$ ping deb.devuan.org
PING deb.rr.devuan.org (95.216.15.86) 56(84) bytes of data.
64 bytes from megumin.packet-gain.de (95.216.15.86): icmp_seq=1 ttl=47 time=257 ms
64 bytes from megumin.packet-gain.de (95.216.15.86): icmp_seq=2 ttl=47 time=257 ms
--- snip ---
--- deb.rr.devuan.org ping statistics ---
12 packets transmitted, 12 received, 0% packet loss, time 12187ms
rtt min/avg/max/mdev = 256.589/256.769/256.948/0.120 ms
~$
As you can see, a ping to deb.devuan.org will act on deb.rr.devuan.org which would indicate that it is (?) working correctly.
Does a traceroute from this end of the world render any useful data?
~$ traceroute deb.devuan.org
traceroute to deb.devuan.org (103.146.168.12), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 1.755 ms 1.706 ms 1.672 ms
2 XXX.XX.XXX.X (XXX.XX.XXX.X) 3.094 ms 3.149 ms 3.125 ms
3 10.192.4.36 (10.192.4.36) 3.152 ms 3.430 ms 3.947 ms
4 * * *
5 176.52.255.29 (176.52.255.29) 132.642 ms 10.192.17.1 (10.192.17.1) 4.898 ms 176.52.255.29 (176.52.255.29) 132.540 ms
6 213.140.39.116 (213.140.39.116) 4.794 ms * 1.374 ms
7 * 176.52.255.29 (176.52.255.29) 121.977 ms 127.727 ms
8 * ix-be-26.ecore1.mln-miami.as6453.net (66.110.72.30) 120.381 ms *
9 if-ae-45-2.tcore1.mln-miami.as6453.net (63.243.152.34) 148.806 ms 148.678 ms *
10 if-bundle-37-2.qcore1.mln-miami.as6453.net (66.110.9.112) 149.087 ms * *
11 if-ae-45-2.tcore1.mln-miami.as6453.net (63.243.152.34) 148.287 ms 147.865 ms 147.742 ms
12 * if-bundle-2-2.qcore2.aeq-ashburn.as6453.net (216.6.87.9) 148.239 ms *
13 if-ae-12-2.tcore4.njy-newark.as6453.net (66.198.155.33) 148.661 ms * 149.464 ms
14 if-ae-1-3.tcore3.njy-newark.as6453.net (216.6.57.5) 147.936 ms * *
15 if-ae-12-2.tcore4.njy-newark.as6453.net (66.198.155.33) 148.054 ms 209.58.124.6 (209.58.124.6) 343.277 ms if-ae-12-2.tcore4.njy-newark.as6453.net (66.198.155.33) 149.337 ms
16 * * *
17 121.240.236.6.static-Delhi.vsnl.net.in (121.240.236.6) 354.318 ms 354.241 ms 209.58.124.6 (209.58.124.6) 343.408 ms
18 103.196.223.166 (103.196.223.166) 355.967 ms 356.725 ms 354.336 ms
19 121.240.236.6.static-Delhi.vsnl.net.in (121.240.236.6) 355.794 ms 103.146.168.12.ipacct.in (103.146.168.12) 363.173 ms 361.877 ms
~$
Best,
A.
Last edited by Altoid (2024-09-12 10:25:56)
Offline
Same here. Works perfectly fine.
~ % ping deb.devuan.org
PING deb.rr.devuan.org (185.178.192.43) 56(84) bytes of data.
64 bytes from mx.mail.13390.hostserv.eu (185.178.192.43): icmp_seq=1 ttl=250 time=36.8 ms
64 bytes from mx.mail.13390.hostserv.eu (185.178.192.43): icmp_seq=2 ttl=250 time=36.7 ms
64 bytes from mx.mail.13390.hostserv.eu (185.178.192.43): icmp_seq=3 ttl=250 time=36.6 ms
64 bytes from mx.mail.13390.hostserv.eu (185.178.192.43): icmp_seq=4 ttl=250 time=36.6 ms
^C
--- deb.rr.devuan.org ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 36.613/36.681/36.836/0.090 ms
Offline
Using deb.rr.devuan.org works perfectly well, as do all (most) other mirrors as well.
deb.devuan.org remains blocking, wondering why.
Try this and reply with the result:
nslookup deb.devuan.org
Online
nslookup shows:
andre@yokohama:~$ nslookup deb.devuan.org
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
deb.devuan.org canonical name = deb.rr.devuan.org.
Name: deb.rr.devuan.org
Address: 190.64.49.124
Name: deb.rr.devuan.org
Address: 160.16.137.156
Name: deb.rr.devuan.org
Address: 185.178.192.43
Name: deb.rr.devuan.org
Address: 198.58.118.8
Name: deb.rr.devuan.org
Address: 125.228.189.120
Name: deb.rr.devuan.org
Address: 94.16.114.15
Name: deb.rr.devuan.org
Address: 185.236.240.103
Name: deb.rr.devuan.org
Address: 106.178.112.231
Name: deb.rr.devuan.org
Address: 5.161.180.234
Name: deb.rr.devuan.org
Address: 67.219.104.166
Name: deb.rr.devuan.org
Address: 202.61.197.17
Name: deb.rr.devuan.org
Address: 185.183.113.131
Name: deb.rr.devuan.org
Address: 131.188.12.211
Name: deb.rr.devuan.org
Address: 147.78.194.22
Name: deb.rr.devuan.org
Address: 195.85.215.180
Name: deb.rr.devuan.org
Address: 103.146.168.12
Name: deb.rr.devuan.org
Address: 95.216.15.86
Name: deb.rr.devuan.org
Address: 200.236.31.1
Name: deb.rr.devuan.org
Address: 46.4.50.2
Name: deb.rr.devuan.org
Address: 130.225.254.116
Name: deb.rr.devuan.org
Address: 141.84.43.19
Name: deb.rr.devuan.org
Address: 2a01:4f9:2a:fa9::2
Name: deb.rr.devuan.org
Address: 2801:82:80ff:8000::2
Name: deb.rr.devuan.org
Address: 2a01:4f8:140:1102:2b76:955d:b48f:bdf3
Name: deb.rr.devuan.org
Address: 2001:878:346::116
Name: deb.rr.devuan.org
Address: 2001:4ca0:4300::1:19
Name: deb.rr.devuan.org
Address: 2800:a8:c001::a
Name: deb.rr.devuan.org
Address: 2001:e42:102:1704:160:16:137:156
Name: deb.rr.devuan.org
Address: 2a03:4000:28:24c::
Name: deb.rr.devuan.org
Address: 2a0d:eb00:8006::acab
Name: deb.rr.devuan.org
Address: 240b:10:f00:1b00::240
Name: deb.rr.devuan.org
Address: 2a01:4ff:f0:dd3a::1
Name: deb.rr.devuan.org
Address: 2401:c080:2000:229e:4b70:fe82:36ed:f788
Name: deb.rr.devuan.org
Address: 2a03:4000:59:123:68cc:97ff:fee1:c81
Name: deb.rr.devuan.org
Address: 2001:638:a000:1021:21::1
Name: deb.rr.devuan.org
Address: 2a0a:e5c0:10:3::6eeb
Name: deb.rr.devuan.org
Address: 2a01:9e40::180
Name: deb.rr.devuan.org
Address: 2407:b6c0::12
andre@yokohama:~$
traceroute never responds:
andre@yokohama:~$ traceroute deb.devuan.org
As I wrote: every address responds well with the only exception of deb.org.devuan.
I can live with the situation, but I will try again next weekend when I will be at another place, physically.
Then I will report back. Thanks to you all for your good will.
Oh, after a long while traceroute came back with some answer:
andre@yokohama:~$ traceroute deb.devuan.org
deb.devuan.org: Name or service not known
Cannot handle "host" cmdline arg `deb.devuan.org' on position 1 (argc 1)
andre@yokohama:~$
funny, isn't it?
Last edited by Andre4freedom (2024-09-12 13:00:22)
Offline
Hello:
traceroute never responds ...
Hmm ...
Could you please post the output of:
$ cat /etc/resolv.conf
Thanks.
Best,
A.
Offline
Sure:
andre@yokohama:~$ cat /etc/resolv.conf
# Generated by NetworkManager
search home
nameserver 192.168.1.1
nameserver XXXX.XXXX.XXXX.XXXX.XXXX.XXXX.XXXX
andre@yokohama:~$
Last edited by Andre4freedom (2024-09-12 22:32:03)
Offline
The first things I'd try would be ping -c 1 deb.devuan.org and ping -c 1 deb.rr.devuan.org
If the first fails and the second works the I'd try host -v deb.devuan.org which gives more details of how the DNS query works. But I'd be reaching the limit of my knowledge of DNS trying to work out why the one fails and the other works.
Other questions are which country are you in and which ISP do you use (I'm assuming you are doing this from home)? It might be ISP specific.
Offline
Hello:
~$ cat /etc/resolv.conf
# Generated by NetworkManager
search home
nameserver 192.168.1.1
nameserver 2a02:1210:3236:f500:a2b5:49ff:feb7:9ea0
~$
Right ...
Let's try something.
As sudo, please edit resolv.conf so that it ends up like this:
~$ cat /etc/resolv.conf
# Generated by NetworkManager
# search home
#
nameserver 8.8.8.8
nameserver 8.8.4.4
#
# nameserver 192.168.1.1
# nameserver 2a02:1210:3236:f500:a2b5:49ff:feb7:9ea0
~$
Save the file, reboot and see if your problem is still there.
If things work, now you know that you have some DNS configuration problem.
TL;DR
192.168.1.1 is (most probably) a/your router's IP address.
2a02:1210:3236:f500:a2b5:49ff:feb7:9ea0 is a valid IPv6 address but I cannot say what it belongs to, maybe the router also.
You can check it here: http://sqa.fyicenter.com/1000334_IPv6_A … idator.htm
By editing resolv.conf you will have set Google's DNS servers as nameservers for your box and things should work as expected now.
Bear in mind that Google's DNS servers are not the only ones you can use, you can also use your service provider's DNS servers or freely available public DNS servers.
Let us know how you fared with this.
Best,
A.
Offline
Other options: if "not responding" shows again, check https://downdetector.com/status/googlepublicdns, or try Cloudflare (1.1.1.1/1.0.0.1) to see if another DNS has same/different results.
Offline
@altoid, @chris2be8
These tests don't change the result. NetworkManager resets the resolv.conf file to the old value at restart.
It must be the ISP's problem. I'm actually on holiday, hence at another location.
No further analysis is required. I will report back next week.
Thank you all, greetings, Andre
Offline
Hello:
NetworkManager resets the resolv.conf file ...
Quite so.
... the ISP's problem.
No.
It is the default behaviour for NetworkManager. 8^°
--- snip ---
dns
Set the DNS (resolv.conf) processing mode.default: The default if the key is not specified. NetworkManager will update
resolv.conf to reflect the nameservers provided by currently active connections.dnsmasq: NetworkManager will run dnsmasq as a local caching nameserver, using a "split
DNS" configuration if you are connected to a VPN, and then update resolv.conf to point
to the local nameserver.none: NetworkManager will not modify resolv.conf.
--- snip ---
https://people.freedesktop.org/~lkundra … .conf.html
See these two posts for a solution:
https://dev1galaxy.org/viewtopic.php?pid=47932#p47932
and
https://stackoverflow.com/questions/517 … esolv-conf
Best,
A.
Offline
@Altoid
I temporarily disabled the NetworkManager to acquire the DNS address from the local DHCP server, and set the nameserver to 8.8.8.8, as you requested.
After restarting the network-manager, for the first time deb.devuan.org was resolved by a ping request! Thanks a lot!
Now I reset the default Network-Manager configuration, and deb.devuan.org is not resolved again.
That proves that nothing is wrong with deb.devuan.org, nor with my workstation.
The local ISP provides the DNS service by the means of that cable-modem box, and the culprit really is the ISP.
Just as a side note: deb.debian.org was always resolved correctly by ping queries.
That concludes the matter and I thank you all for your hints and kind suggestions.
I will close the case.
Have a great weekend! with or without snow ;-)
André
Offline
It sound as if your next step is to ask your ISP to investigate.
As an aside, host accepts a 3rd parameter, the IP address of the DNS server it should query. So you could try host deb.devuan.org 1.1.1.1 to see what Cloudflare's DNS server would return. It's quicker than temporarily changing /etc/resolv.conf.
Offline
@chris2be8
Thank you for your suggestion.
The problem is: to check with this ISP is absolutely hopeless.
I would waste my time with them.
I will tell how it works in other places, next week.
Have a nice weekend. André
Offline
Which ISP is it? That at least tells other people in your country which ISP to avoid.
If you look through the admin screens on the router your ISP provided you might find one saying what IP address it queries (the router will at most cache DNS entries). Assuming it's at 1.2.3.4 (replace that with whatever it is) run the following:
host deb.devuan.org 192.168.1.1
host deb.devuan.org 1.2.3.4
host deb.devuan.org 1.1.1.1
If only the first fails your router is confused. Try power cycling it.
If the first two fail your ISP's DNS server is confused.
If the last one fails something very strange is going on.
Offline
Report from another place:
Now away from that nice place where I spent a week, and back home to my environment:
deb.devuan.org resolves as it is supposed to and everything works. Great.
Ping, apt update and Co. all do well.
The provider of that other place is the most widely used here in our country, and usually their networks just work. Sort of. But f you have a problem, don't try to get support, even paid-for support.
I was the unlucky one who had to use that unfortunate router/network with no access to whatever equipment of it.
So my first question was: is there something wrong. Well, there was: the provider's equipment.
And all of you were quick to confirm that deb.devuan.org works well.
Devuan is great and always was. As is the Devuan-community.
Thank you all for your suggestions. Lovely.
Offline
Hello:
... something wrong. Well, there was: the provider's equipment.
I don't think so.
For reasons I can only adscribe to syncronicity, serendipity, karma or just bad luck my box started behaving like yours.
This in spite of having set my fibre router to use my specific DNS.
ie: PiHole/Unbound in a VM running Devuan Chimaera.
Before that, it happened once every two weeks or so, when the fibre provider did a remote reset of the router, the result being the DNS1 and DNS2 settings being restored to their default IP addresses.
But, if my provider's router is set to use my own DNS (192.168.1.11) and NetworkManager's settings are set to use that very same IP adress why in holy fuck's name is this POS NetworkManager setting /etc/resolv.conf to an IP address reflecting one of my fibre provider's DNS servers?
I found the answer here.
It seems that every clueless moron who writes some half-arsed network management tool or script thinks that it is acceptable to blow away a hand-crafted /etc/resolv.conf and replace it with some garbage that only works in the imaginary fantasy-land of the author's imagination, not in the real world. If you don't want your /etc/resolv.conf being mangled by programs like systemd-resolved or network manager, then you need to either a) configure them to stop doing that, or b) stop using them. In your case, something (probably systemd-resolved) has replaced your /etc/resolv.conf with a symlink. –
Unfortunately, I have not been able to make option a) work and b) needs WiCD to get made into the Debian/Devuan repositories.
Other available options seem to be worse.
The author also (quite eloquently) said this:
... said it before but apt-get purge is effective but unsatisfyingly inadequate, there should be a --kill-it-with-fire or --banish-to-hell option for miserable system-breaking junk like that. –
I wholeheartedly agree with his opinion, NetworkManager fits the description perfectly.
In short:
I tried all the solutions I found posted on line and (up to now) the only one that worked (jury still out) is the one posted by fsmithred here.
But there's a twist.
As /etc/resolv.conf is a symlink, the right syntax to use is this:
~$ sudo chattr -f +i /etc/resolv.conf
Otherwise you get an error:
~$ sudo chattr +i /etc/resolv.conf
--- snip ---
chattr: Operation not supported while reading flags on /etc/resolv.conf
~$
So now we know ... 8^°
Best,
A.
Last edited by Altoid (2024-09-17 02:43:13)
Offline
i keep my /etc/resolv.conf from being changed by forcing it with /etc/NetworkManager/conf.d/90-dns-none.conf
here is the note to myself that i left in /etc/resolv.conf
# created file with sudo nano
# /etc/NetworkManager/conf.d/90-dns-none.conf
# with contents:
# [main]
# dns=none
# then check with command:
# sudo NetworkManager --print-config
and the only active line in /etc/resolv.conf is "nameserver 192.168.1.1"
i don't remember where i found out about that particular solution but this link might be helpful to future thread visitors:
https://www.networkmanager.dev/docs/api/latest/NetworkManager.html
as always, your mileage may vary
Be Excellent to each other and Party On!
https://www.youtube.com/watch?v=rph_1DODXDU
https://en.wikipedia.org/wiki/Bill_%26_Ted%27s_Excellent_Adventure
Do unto others as you would have them do instantaneously back to you!
Offline
Pages: 1