Failed to access debian repos

I'm seeing some error messages as:

Temporary failure resolving 'deb.debian.org'

Does the debian repos works for you? (run apu)

In fact i think that one of them comes from the @maxinou install, seems like its install didn't installed correctly all the extra needed packages, like libreoffice ones

@maxinou can you see if "apu" works? and also check if your package "libreoffice" is on the last version installed:

appo libreoffice

1 Like

as for me, everything "apu normaly"

1 Like

Works fine for me. :+1:

Works for me too...

I'd like to know what mirrir you are using, @Thanatermesis

For me it is;:

bm@lydia:~$ ping -c2 deb.debian.org
PING debian.map.fastly.net (151.101.114.133) 56(84) bytes of data.
64 bytes from 151.101.114.133 (151.101.114.133): icmp_seq=1 ttl=59 time=9.84 ms
64 bytes from 151.101.114.133 (151.101.114.133): icmp_seq=2 ttl=59 time=9.32 ms

--- debian.map.fastly.net ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 9.321/9.583/9.845/0.262 ms

As far as I know, the deb.debian.org is using only roundrobin as loadbalancing. I'm not sure if they are using even a little geoIP here.

Hi,

I'll perform the test next week end, last Sunday I installed last 32 bit beta in my HP Mini and I aborted the installation to change my bad HDD for an old HDD in good condition that I found in a box while I'm moving. In Acer I still have an old 32 bit beta an is my wife at home who use it actually.

I'll test both and I'll tell you the results in the next week end.

I'll came also into the forum from next week end finally!!!

1 Like

Okay, I wasn't correct. There is a CDN behind deb.debian.org ... Short and simple described at https://deb.debian.org/ ...
That could also be the reason for the Temporary failure resolving 'deb.debian.org'. See:

If you hit the server behind deb.debian.org directly, either because you use an older apt or because you use a HTTP proxy that does not support SRV records, your requests will get HTTP redirected to one of the CDN instances. If you want to avoid the redirects, you can pick one instance directly. For instance, this also works in your sources.list :

1 Like

deb.debian.org is the one used by default, so if their redirection fails, yes we can have the issue

@LupusE can you try to switch http to httpS in your sources.list.d/debian* file ? to see if the problem is solved ? :thinking:

I don't think this will help.

'cant resolve deb.debian.org' means the client isn't able to translate the Domain Name to a useable IP (or any further record, that will lead to get an IP). The explaination is 'because the client or a proxy or similar in between is not able to read SRV entrys from the DNS'.
http (80) and https (443) will only change the used port (and a little cryptmagic in the transportation), but the IP still is unresolved.
Except the proxy doesn't handle https and will ignore the whole request. But in this case I would expect a 404 answer, not a DNS resolve issue.

Yes, apu works

~ ❯❯❯ appo libreoffice
libreoffice:
Installé : (aucun)
Candidat : 1:6.4.1-1~bpo10+1
Table de version :
1:6.4.1-1~bpo10+1 600
100 http://deb.debian.org/debian buster-backports/main i386 Packages
1:6.1.5-3+deb10u5 500
500 http://deb.debian.org/debian buster/main i386 Packages
1:6.1.5-3+deb10u4 500
500 http://deb.debian.org/debian-security buster/updates/main i386 Packages

And in 3.8.7 32 installation I have not LibreOffice installed by default, as shown before

Today I've got a similar issue, without Debian/Elive involved. But the proxy/DHCP is wrong configured.

lupus@k411e:~$ LANG=C sudo apt update
Err:1 http://http.kali.org/kali kali-rolling InRelease
  Temporary failure resolving 'http.kali.org'

An other distribution, but the same result. Let me show my steps of analysis:

Is the cable plugged in? Or the Wifi connected?

lupus@k411e:~$ sudo ethtool eth0 |grep Link
        Link detected: yes

Okay, where should all the traffic go to?

lupus@k411e:~$ ip r
default via 10.0.2.2 dev eth0 
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15 

Here we have a VirtualBox VM with NAT to the Host network ... Not very helpful at this moment.

But let's try to resolve the hostname by hand:

lupus@k411e:~$ dig http.kali.org
[...]
;; connection timed out; no servers could be reached

I've expected this result ... Lets use another DNS Server:

lupus@k411e:~$ dig http.kali.org @8.8.8.8
[...]
;; ANSWER SECTION:
http.kali.org.          184     IN      CNAME   hebe.kali.org.
hebe.kali.org.          184     IN      A       192.99.200.113
[...]

Okay, here we go. But how?

lupus@k411e:~$ cat /etc/resolv.conf 
domain fritz.box
search fritz.box
nameserver 192.168.178.1

At this point it is helpful to know the real net of the host is 192.168.151.0/24 and 192.168.178.0/24 is existing, but only a transfer network for an old environment. The root cause is a wrong plugged cable from the hub of the transfer net to the hub of the work net. The DHCP of the transfer net answered first and the configuration for the client is not to use.

But even if we know the right network, what is the IP of the DNS? We don't care, because we already have a working DNS ... With the google DNS we can perfectly work in the internet, but not with local servers. Be careful while using a local ADS or something like this for your credentials.

The really short way is:

lupus@k411e:~$ echo "echo nameserver 8.8.8.8 >> /etc/resolv.conf" | sudo bash

lupus@k411e:~$ sudo apt update; sudo apt dist-upgrade 
[...]
397 upgraded, 79 newly installed, 0 to remove and 0 not upgraded.
Need to get 1124 MB of archives.
After this operation, 1540 MB of additional disk space will be used.
Do you want to continue? [Y/n] 
[...]

Maybe we should delete the wrong lines in the /etc/resolv.conf. for a better performance. But the system will try every name server listed, until one is answering.
Our changes should be overwritten after a restart or a new DHCP request (after unplugging the false cable).

If it was a proxy issue, the switching to https should be better. Using https is always a good idea. Because if somebody is performing a MITM (man in the middle) attach between your system and the repo, it is easy to change the whole repo, including the list of the checksum, which should protect us from malicious packages.
See SecureApt - Debian Wiki ... Because apt is still using MD5, it should not be rated as secure.

yes, maybe the 8.8.8.8 should be appended as a default conf provided in elive :thinking: (appended after the default ones, so i have seen isp's in the past that fails if you don't use specifically their own dns)

The possibillity of 8.8.8.8 and 8.8.4.4 to fail are at the moment really low. But in some environments is a own DNS not allowed. They are blocking port 53 for all systems, except the own/internal DNS Server. And there are good reasons to do so.
For an example at home: https://pi-hole.net/

In my experience (Germany), the smaller a provider, the more likely the DNS is unreliable. But in home environments I use them anyway and set 8.8.8.8 as second source. This is good practice for some years. In company environments it is not so simple and depending on the business/provided services.
To be fair, also the bigger companies, like Telekom, Versanet or Telefonica, sometimes have odd behavior in the DNS, so I needed to switch the primary and secondary DNS ... Mostly because of some BPJM (German magic solution to block the bad guys in the dangerous internet).

I would strongly dis-advise using Google as a fixed DNS.
I know it's the easiest and most robust solution ... that after all is the major strategy Google uses to lock people in.

Elive, being part of the free and open community should not propagate or even put that in there blindly, especially if there are good alternatives. If Elive does put that in, then I'm certainly out of here. :imp:


or:

or:
https://dnsprivacy.org/wiki/

If you want to become active.

I feel the same about this as I felt about adding Amazon to the default search options by Ubuntu, at the time.
I also think that we should replace Google as default search engine with (or at least offer a choice on first start) Ecosia:
https://www.ecosia.org/
and help plant some trees in the process.:smiley14:

M$ isn't the only bogeyman anymore it's Google, Amazon and Facebook c.s.
In case you're wondering why I'm passionate about this
441533

2 Likes

This is only for debugging purpose. As I was young we haven't much alternatives that are easy to remember, when you are offline. Even the bash line is just temporary, it will be overwritten by the next reboot.

I am at your side, there are a lot of open source solutions. But I am not familiar with the outcome. In case of a issue that need to be resolved I am rather use something that worked quite a long time, than experiment with new tools.

If 8.8.8.8 won't work, I'm searching for the DHCP and lookup if the set DNS is working. And than I'm out and handover the issue to the networking guys ...

In fact there are good reasons to take a look at the free alternatives, such as 1.1.1.1 or FreeDNS. But the time. Sometimes I stumble over settings, where the admin is setup his own Bind9 (or dnsmasq) and forwarding the all requests to .root-servers.net ...

There are no boogeyman. You have always the choice, they providing the tools. Sometimes they are more toys than tools, but what are you paying for?
I am using a lot of Google services in private. They are using my data and do also improve the services. And make some BigData AdWare crap ... But they are using my data, so it could went better.
For example, if I am searching for shoes, why is Amazon providing me women shoes or shoes far away from my size? ... I am happy to tell them the length of my feet to get better results.

But I don't want them to know all my business knowledge. They don't need to have the spreadsheet with the planned IT Invest 2020. Or my documentation about opening a new store. In fact if my knowledge will be public, it well help a lot of people in similar situations. But I am selling these to companies.
In my personal Google Drive you'll find a lot of spreadsheets and maps about every kind of LEGO game. With Locations of in-game collectibles or trophy guides. And I am working on a Database to put all lists together and later write an Android app ... Since I haven't much time between my Job and my Family, I would be happy if someone will working on that project with me. Maybe I should make them available at Github? ..

So, enough Offtopic. My intention was to 'What could I do, if I run into this error?'. Because of the plenty different setups, there is no universal answer. But with the mentioned tools, we've (the people that want to help) got a good overview about the current situation. I think. Correct me, if I am wrong.

1 Like

I wasn't planning on doing so as I can't find anything wrong there.
I was thinking that by itself, your post is almost a nice howto on solving nameserver problems. Although I do think it could be written a tad more simple. :wink:

My initial reaction was bent on the thoughtless idea of defaulting to the use of google for DNS.

As to data collection: Most people tend to take data collection as a very personal thing, which isn' always the case. It's also about collecting metadata and feeding that through (secret) algorithms to acquire predictability or even influencing certain social constructs like elections.

The point being: We would find it totally unacceptable if a state did this but are letting unaccountable big tech corporations simply get away with it under the "but it's so easy" pretext.

1 Like

Yeah, 1.1.1.1 is supposed to be a good one (website is https://1.1.1.1) (like you said)

Or maybe Givero...... https://givero.com