Repository - invalid metadata ??

Hi all, over the past few months I find zypper updates often stall with repository access errors, usually with reports like this:
“Valid metadata not found at specified …” (repo)

I have stripped out everything non-essential (a good thing, anyway) but the problem persists. Today it is “Update repository with updates from SUSE Linux Enterprise 15”

The problems usually resolve after a day or so. I have had to switch mirrors on a few occasions.

I’m not sure what is causing this or what to to do, so I am checking in to chit-chat to ask if anyone else is seeing errors like this?

Thanks for reading.

Likely hitting an incomplete/slow syncing mirror, you could try mirrorcache and see if that helps, see

If you run a forced refresh with verbosity to see what is happening as well…

zypper -vvv ref -f

Thanks for the helpful pointers, malcolmlewis.

After running zypper -vvv ref -f the most notable reports related to the step “Forcing raw metadata refresh”
The following similar responses were received for these two entries:

Retrieving: ...[done (139 B/s)]
Retrieving: ...[done (139 B/s)]

The responses to all seven (7) other entries were in this form:

Retrieving: ...[not found]

This seems odd but I am not clear what it means. Can you comment?

No, that’s normal as it refers to the install media and can be ignored with online repositories.

This is a follow-up report on my experience implementing the wonderful mirrorcache.

Do not be confused! Despite the injunction to “choose one of the MirrorCache instances that are closely to you” and (oh dear) “adjust it for your needs” the URL you actually want is ‘

Like a mug, I followed the guide and choose the nearby one. It failed with words like:
Error code: Connection failed.
After amending that base url to everything just works - as it should.

Just a quiet mention that, even here in Germany, about 20 km from the SUSE building, sometimes the SLE 15 update repository is more than a little bit unresponsive – meaning, give up and try again on the next day.

  • Just a suspicion – it could be a repository update load issue and/or the number of systems accessing that repository at a given time-of-day …
**Leap-15-3:~ #** zypper lr -E 
#  | Alias                 | Enabled | GPG Check | Priority | URI 
 4 | packman               | Yes     | (r ) Yes  |   90     | 
 1 | Application_Geo       | Yes     | (r ) Yes  |   99     | 
 2 | home_kukuk_qmapshack  | Yes     | (r ) Yes  |   99     | 
 6 | repo-backports-update | Yes     | (r ) Yes  |   99     | 
11 | repo-non-oss          | Yes     | (r ) Yes  |   99     | 
12 | repo-oss              | Yes     | (r ) Yes  |   99     | 
14 | repo-sle-update       | Yes     | (r ) Yes  |   99     | 
16 | repo-update           | Yes     | (r ) Yes  |   99     | 
17 | repo-update-non-oss   | Yes     | (r ) Yes  |   99     | 
**Leap-15-3:~ #**

Big repos are currently pretty slow:

**Leap-15-3:~ #** for i in $(zypper lr |grep Yes| cut -d '|' -f2); do echo $i; time zypper ref -f $i|grep real;done 

real    0m0.686s 
user    0m0.251s 
sys     0m0.065s 

real    0m0.568s 
user    0m0.123s 
sys     0m0.044s 

real    0m0.493s 
user    0m0.058s 
sys     0m0.041s 

real    0m1.362s 
user    0m0.570s 
sys     0m0.116s 

real    0m0.398s 
user    0m0.078s 
sys     0m0.019s 
**repo-oss **

**real    0m7.250s **
user    0m6.738s 
sys     0m0.214s 
**repo-sle-update **

**real    0m9.770s 
**user    0m8.923s 
sys     0m0.144s 

real    0m0.795s 
user    0m0.330s 
sys     0m0.042s 

real    0m0.519s 
user    0m0.073s 
sys     0m0.026s 
**Leap-15-3:~ #**


**6700K:~ #** zypper lr -E 
#  | Alias   | Enabled | GPG Check | Priority | URI 
 4 | mozilla | Yes     | (r ) Yes  |   80     | 
 7 | packman | Yes     | (r ) Yes  |   90     | 
 5 | non-oss | Yes     | (r ) Yes  |   99     | 
 6 | oss     | Yes     | (r ) Yes  |   99     | 
11 | update  | Yes     | (r ) Yes  |   99     | 
6700K:~ #**  for i in $(zypper lr |grep Yes| cut -d '|' -f2); do echo $i; time zypper ref -f $i|grep real;done 

real    0m0.633s 
user    0m0.104s 
sys     0m0.074s 

real    0m0.837s 
user    0m0.311s 
sys     0m0.050s 

real    0m0.412s 
user    0m0.071s 
sys     0m0.028s 

real    0m4.973s 
user    0m4.494s 
sys     0m0.189s 

real    0m1.581s 
user    0m0.069s 
sys     0m0.031s 
**6700K:~ #**

In my case the SLE updates repo was unavailable every second or third update attempt, with a long wait each time. It seemed like more than normal down time. There have been no further access errors with base url =

I note that in the reports kindly provided by ‘karlmistelberger’ the service at base url = is performing as expected. That was not my experience with the service at (I am in Sydney).
This is the error report:

Problem retrieving files from 'Update repository of openSUSE Backports'.
Download (curl) error for '':
Error code: Connection failed
Error message: Failed to connect to port 443: Connection refused
Please see the above error message for a hint.

Similar errors were reported for all other instances with base url =
Changing those entries to resolved the issue.

Entering “” in a browser brings up the page as expected.

I remain mystified.