You are not logged in.
Try host deb.devuan.org which should get something like:
deb.devuan.org is an alias for deb.rr.devuan.org.
deb.rr.devuan.org has address 106.178.112.231
deb.rr.devuan.org has address 172.234.26.53
deb.rr.devuan.org has address 185.38.15.84
deb.rr.devuan.org has address 185.183.113.131
deb.rr.devuan.org has address 131.188.12.211
deb.rr.devuan.org has address 147.78.194.22
deb.rr.devuan.org has address 195.85.215.180
deb.rr.devuan.org has address 103.146.168.12
deb.rr.devuan.org has address 95.216.15.86
deb.rr.devuan.org has address 200.236.31.1
deb.rr.devuan.org has address 46.4.50.2
deb.rr.devuan.org has address 130.225.254.116
deb.rr.devuan.org has address 141.84.43.19
deb.rr.devuan.org has address 190.64.49.124
deb.rr.devuan.org has address 160.16.137.156
deb.rr.devuan.org has address 185.178.192.43
deb.rr.devuan.org has address 158.69.153.121
deb.rr.devuan.org has address 125.228.189.120
deb.rr.devuan.org has address 89.174.102.150
deb.rr.devuan.org has address 94.16.114.15
deb.rr.devuan.org has address 185.236.240.103
deb.rr.devuan.org has IPv6 address 2407:b6c0::12
deb.rr.devuan.org has IPv6 address 2a01:4f9:2a:fa9::2
deb.rr.devuan.org has IPv6 address 2801:82:80ff:8000::2
deb.rr.devuan.org has IPv6 address 2a01:4f8:140:1102:2b76:955d:b48f:bdf3
deb.rr.devuan.org has IPv6 address 2001:878:346::116
deb.rr.devuan.org has IPv6 address 2001:4ca0:4300::1:19
deb.rr.devuan.org has IPv6 address 2800:a8:c001::a
deb.rr.devuan.org has IPv6 address 2001:e42:102:1704:160:16:137:156
deb.rr.devuan.org has IPv6 address 2607:5300:61:95f:7283:11d9:f86:e691
deb.rr.devuan.org has IPv6 address 2001:4190:801c:1::150
deb.rr.devuan.org has IPv6 address 2a03:4000:28:24c::
deb.rr.devuan.org has IPv6 address 2a0d:eb00:8006::acab
deb.rr.devuan.org has IPv6 address 240b:10:f00:1b00::240
deb.rr.devuan.org has IPv6 address 2a02:2a38:1:400:2a42:2a42:2a42:2a42
deb.rr.devuan.org has IPv6 address 2001:638:a000:1021:21::1
deb.rr.devuan.org has IPv6 address 2a0a:e5c0:10:3::6eeb
deb.rr.devuan.org has IPv6 address 2a01:9e40::180
Then ping deb.devuan.org and see if that gets a response. If it does you should be OK. If not your DNS settings or network must be faulty.
Online
There is what I believe to be a dual post or topic concerning the same issue.
https://dev1galaxy.org/viewtopic.php?id=5133 "Temporary failure resolving 'deb.devuan.org' "
Perhaps some helpful info!
zephyr
Last edited by zephyr (2024-02-09 19:38:30)
CROWZ
easier to light a candle, yet curse the dark instead / experience life, or simply ...merely exist / ride the serpent / molon labe / III%ers / oath keepers
Offline
The same problem began occurring to me roughly two days before this thread began on 7th February, so I am yet another user reporting this problem recently, in case it could help anyone at Devuan to consider whether there is some misconfiguration of any server that ought to be addressed.
The solution used by entropyagent, which included changing the nameserver e.g. to 9.9.9.9, did solve the problem for me when it was implemented about two days ago, followed by chattr +i /etc/resolv.conf as also suggested.
Moments ago, when I tried to revert the nameserver to my original [IP?] nameserver (beginning 192.16x), $ ping deb.devuan.org hung, so the original problem persists when using the original nameserver.
Offline
Well it's still not working for me. After reading the new posts, I have a few questions. If I remove connman and go with network manager, do I:
1) Remove all connman entries (connman, connman-gtk, and connman-ui)?
2) Install network-manager or network-manager-gnome? I see two different posts about either one.
3) Is there any risk of borking my system by doing this?
I also assume a reboot would be necessary. Thanks for the help.
Offline
@ Ron: I used Devuan daedalus netinstall xfce's sources.list to see if it was corrupt in mine and then installed both network-manager & network-manager-gnome the same as the Devuan distro has. Both are used and for a good reason, although I really don't know the answer why both. Perhaps one is a dependency of the other.
It worked for me, on my build machine, laptop, and my daily driver machine, so believe it's a safe to install
zephyr
CROWZ
easier to light a candle, yet curse the dark instead / experience life, or simply ...merely exist / ride the serpent / molon labe / III%ers / oath keepers
Offline
Ron,
Several months ago, I changed over from CMST to Network Manager on my JWM and Openbox systems...mainly because my wife uses the JWM machine, and CMST will periodically drop the wireless connection...and she would go ballistic when that would happen. Hahaha!
I still use CMST on this machine that I'm typing this message on.
On this machine, changing my sources.list to one of the alternatives fixed the issue. I haven't checked my JWM or Openbox systems in over 2 weeks, so I can't attest to whether they were having the issue or not...but I trust what zephyr has told you.
When I switched the other two machines over to network manager, I used synaptic...
1. First, I installed network-manager-gnome (that will pull in everything needed).
2. Second, after it installed the packages, I ran nm-applet from my Run Command utility...to make sure it would show in the system tray. It did, so I disconnected from CMST and connected to network manager.
3. Third, after seeing that I had a good connection, I went back to synaptic and did a search for connman (CMST is based on connman). I marked all installed packages relating to connman to be completely removed.
I don't remember if I rebooted or not. I probably did, just to make sure nm-applet would show up in the system tray after adding it to my autostart files.
That's how I did it. If anyone sees something wrong with those steps, feel free to make corrections.
Offline
Installed network-manager-gnome and uninstalled connman. That fixed it. I had to add 9.9.9.9 first to the resolv.conf file to download network-manager-gnome.
But one thing I now notice since this change is that the resolv.conf file is no longer read only. Is this normal?
Offline
Hmmm...I still had a wireless connection, so I could still use a web browser, run an update, etc...my issue was just with deb.devuan.org in the sources.list.
Are you using an ethernet cable to connect or a wireless connection???
This is my recommendation...only mine. If others have some other input, wait to see what they say.
You are in the US, right?
1. Open your terminal. Then open your file manager as root...sorry, I don't know the name of MATE's file manager...such as...
sudo your-file-manager's-name
Navigate to /etc/apt/sources.list, and open the sources.list with your text editor. If you're more comfortable with this, put a # in front of each line in your sources.list (to disable them), then Copy and paste the sources.list that I gave in a post above...there is another alternative US mirror, but the one I'm using works good for me.
2. Save the file.
3. Run a...
sudo apt update
4. If it doesn't return any errors, you'll be good to go.
Offline
Well everything is running fine now. Is there a reason to do this? I have a wired connection, btw.
Last edited by Ron (2024-02-10 13:35:37)
Offline
No sir. If it's doing fine now, don't worry with it.
It's just my experience that deb.devuan.org has hiccups every now-and-then.
Glad everything is working for you now.
Offline
Thanks to all for your help. Marked as "SOLVED."
sorry, I don't know the name of MATE's file manager
caja
Offline
Perhaps I misunderstood something.
"merged" in sources.list transfers the work of selecting a mirror to amprolla.
Am I wrong?
And second, of course, you can specify a specific address in sources.list, having first checked it.
root@devuan:/# ping deb.devuan.org
PING deb.rr.devuan.org (130.225.254.116) 56(84) bytes of data.
64 bytes from mirrors.dotsrc.org (130.225.254.116): icmp_seq=1 ttl=53 time=54.0 ms
64 bytes from mirrors.dotsrc.org (130.225.254.116): icmp_seq=2 ttl=53 time=54.1 ms
64 bytes from mirrors.dotsrc.org (130.225.254.116): icmp_seq=3 ttl=53 time=54.3 ms
64 bytes from mirrors.dotsrc.org (130.225.254.116): icmp_seq=4 ttl=53 time=53.9 ms
64 bytes from mirrors.dotsrc.org (130.225.254.116): icmp_seq=5 ttl=53 time=53.5 ms
64 bytes from mirrors.dotsrc.org (130.225.254.116): icmp_seq=6 ttl=53 time=54.4 ms
^C
--- deb.rr.devuan.org ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 9078ms
rtt min/avg/max/mdev = 53.546/54.054/54.401/0.289 ms
root@devuan:/# ping dev.beard.ly
PING dev.beard.ly (198.58.118.8) 56(84) bytes of data.
64 bytes from dev.beard.ly (198.58.118.8): icmp_seq=1 ttl=45 time=162 ms
64 bytes from dev.beard.ly (198.58.118.8): icmp_seq=2 ttl=45 time=161 ms
64 bytes from dev.beard.ly (198.58.118.8): icmp_seq=3 ttl=45 time=161 ms
^C
--- dev.beard.ly ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 161.072/161.386/161.805/0.308 ms
root@devuan:/#
Last edited by aluma (2024-02-10 13:50:05)
Offline
I already marked this as solved, but I'm still curious why network manager does not generate the resolv.conf file as read only as does connman. I am assuming this file is generated by either connman or network manager.
Offline
Daedelus, network manager initially
root@AA:/etc# ls -l ./resolv.conf
-rw-r--r-- 1 root root 241 Feb 10 16:28 ./resolv.conf
Offline
My first thought was to say to just be patient and wait, and the issue would be fixed and resolve itself.
In my experience, this issue with deb.devuan.org in the sources.list used to happen maybe once or twice a year? I can't remember since it's so infrequent...plus...I'm amnesiactical...
It's stable after all. In my lowly opinion, the only pressing issue would be if a user was trying to install a package from the repos under those circumstances...I don't think waiting a few days (for an issue like this to be resolved) would be a detriment to security on a stable system, but I digress.
...or...the user could try changing their sources.list or installing a different "network-manager" so as not to have to worry about it in the future???
Offline
For anyone who is running connman and having this problem, there is a simple fix.
Edit this file: /etc/init.d/connman
Change this:
DAEMON=/usr/sbin/connmand
DESC="Connection Manager"
To this:
DAEMON=/usr/sbin/connmand
DAEMON_OPTS='--nodnsproxy'
DESC="Connection Manager"
Reboot.
Online
@aluma, "amprolla" is not involved at all in the delivery of packages. "amprolla" runs a program that reads the meta files from the debian and devuan-only repositories and "merges" them by creating the merged meta files which it then distributes to pkgmaster.devuan.org.
pkgmaster.devuan.org serves packages. It's repository (both the devuan-only and the merged parts) is also mirrored to several other servers, and the domain name "deb.devuan.org" is used to obtain all IP addresses for all those (inkluding pkgmaster.devuan.org).
Of course, DNS resolution is a separate subsystem that mostly doesn't involve devuan servers except for eventually and intemittently obtaining that resolution list for deb.devaun.org, which nameservers here and there digests into their cache for the in-between-times resolution service.
All in all, the most problems arise in the DNS resolution sub system; it almost never leads back to hickups with the cllient networking software. Usually due to the DNS subsystem being in transition with intermediate servers being updated. On occasion there are also transient inconcistencies in downloads due to the meta files have been updated on the actual server queried for those before the package pool of the actual server queried for those.
Offline
@ralph.ronnquist
Thank you very much.
I suspected that if we did not specify a specific address, another program would specify it.
You've made things clear.
Regards.
P.S.
localhost:/ # /usr/sbin/traceroute deb.devuan.org
traceroute to deb.devuan.org (141.84.43.19), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 2.568 ms 3.567 ms 4.584 ms
2 100.67.123.1 (100.67.123.1) 9.859 ms 9.942 ms 10.269 ms
3 100.127.249.225 (100.127.249.225) 10.348 ms 10.772 ms 11.988 ms
4 100.127.243.233 (100.127.243.233) 11.092 ms 11.573 ms 11.152 ms
5 100.127.241.129 (100.127.241.129) 15.257 ms 16.245 ms 16.334 ms
6 100.127.241.109 (100.127.241.109) 16.949 ms 9.811 ms 9.820 ms
7 ae0-420.RT.NTL.KIV.UA.retn.net (87.245.237.4) 16.536 ms 16.631 ms 44.538 ms
8 ae4-9.RT.IPB.BER.DE.retn.net (87.245.233.39) 31.865 ms 32.217 ms ae2-9.RT.IPB.BER.DE.retn.net (87.245.233.47) 33.883 ms
9 dfn.bcix.de (193.178.185.42) 34.434 ms 36.258 ms 36.098 ms
10 cr-erl2-be7.x-win.dfn.de (188.1.146.209) 45.251 ms 46.979 ms 46.820 ms
11 cr-gar1-be3.x-win.dfn.de (188.1.144.214) 51.299 ms 51.810 ms 51.628 ms
12 * * *
13 vl-3002.csr4-kb1.lrz.de (129.187.0.134) 45.573 ms 44.651 ms 45.704 ms
14 vl-3011.csr2-kic.lrz.de (129.187.0.154) 44.403 ms 45.459 ms 45.456 ms
15 * * *
16 * * *
Considering the geography and the fact that deb.devuan.org is located in Germany, it is possible and makes sense to indicate the specific address of the nearest mirror.
But this is the decision of the user himself.
Last edited by aluma (2024-02-11 10:06:50)
Offline
@The-Amnesiac-Philosopher , Thanks ol' buddy, your solution worked for me! Finally was able to update after changing sources.list. Would like to see why this whole issue occurred in the first place.
One thing I noted, it did a kernel update for me, but did not automatically swap to the new kernel on re-boot, went to delete the old kernel after re-boot, got warnings from Synaptic which I foolishly ignored, then wouldn't boot back up, had to go into advanced options on the grub screen and manually enter new kernel, first time i've ever had to do this, wonder why?
https://sourceforge.net/projects/vuu-do/
Vuu-do GNU/Linux, minimal Devuan-based openbox systems to build on, maximal versions if you prefer your linux fully-loaded.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
For anyone who is running connman and having this problem, there is a simple fix.
Edit this file: /etc/init.d/connman
Change this:
DAEMON=/usr/sbin/connmand
DESC="Connection Manager"To this:
DAEMON=/usr/sbin/connmand
DAEMON_OPTS='--nodnsproxy'
DESC="Connection Manager"Reboot.
pcalvert's solution worked for me. No DNS changes, resolv.conf updates, or network manager changes needed.
Offline
I run dnscrypt-proxy and choose resolvers list carefully (except when a trusted VPN is running). Rightly or wrongly, I view a corporate provider's DNS service as potentially unreliable *and* a security risk (surveillance, logging, passing data to who knows who)..
I use Ceres and update most days but never seen that problem before. Except yesterday..
I maintain a friend's machines which run chimaera (and use provider DNS):
Temporary failure resolving 'deb.devuan.org'
Immediately after editing resolv.conf with a known good alternative DNS server, all was well.
Later, at my own machine, again no problem. Why is that?
Offline
pcalvert wrote: For anyone who is running connman and having this problem, there is a simple fix.
DAEMON=/usr/sbin/connmand
DAEMON_OPTS='--nodnsproxy'
DESC="Connection Manager"
Yes it is!
Thanks a million, i have a lot of older drives here and there, a mess actually and needed a fix I could just use from an USB drive.
Appreciate the share!
cheers
zephyr
Last edited by zephyr (2024-02-17 01:03:10)
CROWZ
easier to light a candle, yet curse the dark instead / experience life, or simply ...merely exist / ride the serpent / molon labe / III%ers / oath keepers
Offline
So there are at least two ways in this thread to fix this issue, one fix by editing /etc/init.d/connman and another by replacing connman with network-manager, which is the fix I did. My question is: is one way to be preferred over the other, or does it really make no difference?
Offline
There are objective reasons for choosing. For example, my DE Trinity has support for network-manager in the form of a graphical interface.
And subjective ones... like “what color to paint the fence” are different for everyone.
Offline