[opensuse] Curl errors in opensuse 12 and 13
Hi Does anyone know why i always get "curl" errors using "zypper" or Yast to refresh/ update the repos? Its random as to which repos fails. see example below I don't ever recall this happening prior to opensuse 12. I expect this email might get dumped by the checking system because i did a copy and paste from a CLI session regards Ian sudo zypper ref root's password: Download (curl) error for 'http://download.opensuse.org/repositories/KDE:/Current/openSUSE_13.1/repodat...': Error code: Connection failed Error message: Could not resolve host: download.opensuse.org Abort, retry, ignore? [a/r/i/? shows all options] (a): r Retrieving repository 'KDE Current' metadata...........................[done] Building repository 'KDE Current' cache ...........................[done] Retrieving repository 'LibreOffice' metadata ...........................[done] Building repository 'LibreOffice' cache ...........................[done] Download (curl) error for 'http://download.videolan.org/pub/vlc/SuSE/13.1/repodata/repomd.xml': Error code: Connection failed Error message: Could not resolve host: download.videolan.org Abort, retry, ignore? [a/r/i/? shows all options] (a): r Download (curl) error for 'http://dl.google.com/linux/earth/rpm/stable/x86_64/repodata/repomd.xml': Error code: Connection failed Error message: Could not resolve host: dl.google.com Abort, retry, ignore? [a/r/i/? shows all options] (a): r Download (curl) error for 'http://packman.inode.at/suse/openSUSE_13.1/Essentials/repodata/repomd.xml': Error code: Connection failed Error message: Could not resolve host: packman.inode.at Abort, retry, ignore? [a/r/i/? shows all options] (a): r Retrieving repository 'packman-multimedia' metadata ...................[done] Building repository 'packman-multimedia' cache .......................[done] Loading repository data... Reading installed packages... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/24/2014 01:37 PM, ianseeks wrote:
Error message: Could not resolve host: download.opensuse.org
DNS failures. To rule this out, you could temporarily add that server's IP to the file /etc/hosts. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday 24 Jul 2014 13:48:50 Bernhard Voelker wrote:
On 07/24/2014 01:37 PM, ianseeks wrote:
Error message: Could not resolve host: download.opensuse.org
DNS failures.
To rule this out, you could temporarily add that server's IP to the file /etc/hosts.
thanks, but it always works when i press "retry" but i'll add it to the hosts anyway.
Have a nice day, Berny
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/24/2014 10:35 PM, ianseeks wrote:
On Thursday 24 Jul 2014 13:48:50 Bernhard Voelker wrote:
On 07/24/2014 01:37 PM, ianseeks wrote:
Error message: Could not resolve host: download.opensuse.org
DNS failures.
To rule this out, you could temporarily add that server's IP to the file /etc/hosts.
thanks, but it always works when i press "retry" but i'll add it to the hosts anyway.
Hmm, then I guess that the DNS reply hit a timeout at the first try while it is cached during the second try. You could try to do a "nslookup" before zypper to test next time. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Friday 25 Jul 2014 00:13:37 Bernhard Voelker wrote:
On 07/24/2014 10:35 PM, ianseeks wrote:
On Thursday 24 Jul 2014 13:48:50 Bernhard Voelker wrote:
On 07/24/2014 01:37 PM, ianseeks wrote:
Error message: Could not resolve host: download.opensuse.org
DNS failures.
To rule this out, you could temporarily add that server's IP to the file /etc/hosts.
thanks, but it always works when i press "retry" but i'll add it to the hosts anyway.
Hmm, then I guess that the DNS reply hit a timeout at the first try while it is cached during the second try. You could try to do a "nslookup" before zypper to test next time.
Have a nice day, Berny
Guess what. Today "zypper" installed a new version of curl and libcurl and the problem seems to have gone away !! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/18/2014 04:42 PM, ianseeks wrote:
Guess what. Today "zypper" installed a new version of curl and libcurl and the problem seems to have gone away !!
hmm, the update was about cookies now not to be set to top-level domains like .org anymore. So probably another domain's server set a cookie which the opensuse.org server was confused about? Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday 18 Sep 2014 17:21:35 Bernhard Voelker wrote:
On 09/18/2014 04:42 PM, ianseeks wrote:
Guess what. Today "zypper" installed a new version of curl and libcurl and the problem seems to have gone away !!
hmm, the update was about cookies now not to be set to top-level domains like .org anymore. So probably another domain's server set a cookie which the opensuse.org server was confused about?
Have a nice day, Berny
Yep, I spoke too soon but..... it has improved. Previously if i used 2 different logins to run zypper, they both used to fail with the connection errors but now it seems it only fails on the first one with the second one flying through. of well, i'll just have to content with the memories of it working properly on pre opensuse 12.x versions :o) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 7/24/2014 4:35 PM, ianseeks wrote:
On Thursday 24 Jul 2014 13:48:50 Bernhard Voelker wrote:
On 07/24/2014 01:37 PM, ianseeks wrote:
Error message: Could not resolve host: download.opensuse.org
DNS failures.
To rule this out, you could temporarily add that server's IP to the file /etc/hosts.
thanks, but it always works when i press "retry"
There is a round-robin thing in effect where the the same name does not always resolve to the same ip, or even the same TYPE of ip (ipv4 vs ipv6). You could ping that hostname 4 times in a row and see that it t flip flops between two different IP's. (separate ping commands, not just letting one ping command ping for 4 seconds.) So there is nothing strange about the retry working with no other changes that you notice. And that lack of obviousness to the user is a problem with the very idea of such in-line on the fly transparent smoke & mirrors in my opinion, but in practical terms there is no real way around it. They must do load balancing. The /etc/hosts work-around basically makes your machine always use that exact IP instead of picking one of a pool of mirrors. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Content-ID:
There is a round-robin thing in effect where the the same name does not always resolve to the same ip, or even the same TYPE of ip (ipv4 vs ipv6).
You could ping that hostname 4 times in a row and see that it t flip flops between two different IP's. (separate ping commands, not just letting one ping command ping for 4 seconds.)
That's not a good test for this case. The download server may use some kind of round robin IP, maybe. But when you actually request a package from it, you get an http redirection to another mirror, by name, not by IP, which changes depending on your location and availability (it is the Mirror Brain, if I recall the name correctly). And this mirror name your machine resolves again, and they may as well use another load balancing method of their own. It is far from simple. The Mirror Brain is not exactly transparent, the actual mirror you get redirected to should be logged in your logs. - -- Cheers Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlPRvGkACgkQja8UbcUWM1yeGwD9FikZmMoREcnkbjMSf2RaOHIB Tf+eEsHVe83vbH/OEkgBAIpDyxciqWqBcsTMxhyw9pJGvDeXbHhL1GVskVOpVL99 =TAIK -----END PGP SIGNATURE-----
On Thursday 24 Jul 2014 18:23:31 Brian K. White wrote:
On 7/24/2014 4:35 PM, ianseeks wrote:
On Thursday 24 Jul 2014 13:48:50 Bernhard Voelker wrote:
On 07/24/2014 01:37 PM, ianseeks wrote:
Error message: Could not resolve host: download.opensuse.org
DNS failures.
To rule this out, you could temporarily add that server's IP to the file /etc/hosts.
thanks, but it always works when i press "retry"
There is a round-robin thing in effect where the the same name does not always resolve to the same ip, or even the same TYPE of ip (ipv4 vs ipv6).
You could ping that hostname 4 times in a row and see that it t flip flops between two different IP's. (separate ping commands, not just letting one ping command ping for 4 seconds.)
So there is nothing strange about the retry working with no other changes that you notice.
And that lack of obviousness to the user is a problem with the very idea of such in-line on the fly transparent smoke & mirrors in my opinion, but in practical terms there is no real way around it. They must do load balancing.
The /etc/hosts work-around basically makes your machine always use that exact IP instead of picking one of a pool of mirrors.
But if its one "zypper ref" session and there happens to be 5 or 6 repos to refresh in the session , why does it fail after the a successful retry. Should "zypper" do a silent retry once before failing to continue without user intervention? I can't find an option on "zypper" for retries. Does "apper" or any other silent update mechanism fall foul of this process? I know doing the refresh/update via Yast also suffers this problem. Its not a great user experience thanks -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (4)
-
Bernhard Voelker -
Brian K. White -
Carlos E. R. -
ianseeks