0

This is part N of "why aren't I getting security updates". What causes this one?

  • OS: Fedora Workstation 23
  • Date: 2016-03-03

1. transient meaning failure, then success

# dnf check-update

Error: Failed to synchronize cache for repo 'updates' from 'http://download.fedoraproject.org/pub/fedora/linux/updates/23/x86_64/': Yum repo downloading error: Downloading error(s): repodata/0e95ae636347564e66b0e600c9a1369d5c57415ed969bc7bba13e1a190d195c1-filelists.xml.gz - Cannot download, all mirrors were already tried without success; repodata/33467a86da0d3b3b24c27bf054700c0e35041a0643054e62f961d687b2a8c628-prestodelta.xml.xz - Cannot download, all mirrors were already tried without success; repodata/6ae21040c8354039ebdaebd0b3ebb99d6b577c0231e83faf5fdd906944bf32ee-primary.xml.gz - Cannot download, all mirrors were already tried without success; repodata/125571cd75bc296f2b59a8f11d92652f8faa8cbfc9e0fe0637b37c26e9a258fd-updateinfo.xml.xz - Cannot download, all mirrors were already tried without success

1.1 so there was an failure, what does wget show?

# wget http://download.fedoraproject.org/pub/fedora/linux/updates/23/x86_64/repodata/0e95ae636347564e66b0e600c9a1369d5c57415ed969bc7bba13e1a190d195c1-filelists.xml.gz
--2016-03-03 23:32:47--  http://download.fedoraproject.org/pub/fedora/linux/updates/23/x86_64/repodata/0e95ae636347564e66b0e600c9a1369d5c57415ed969bc7bba13e1a190d195c1-filelists.xml.gz
Resolving download.fedoraproject.org (download.fedoraproject.org)... 140.211.169.206, 85.236.55.6, 152.19.134.198, ...
Connecting to download.fedoraproject.org (download.fedoraproject.org)|140.211.169.206|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/updates/23/x86_64/repodata/0e95ae636347564e66b0e600c9a1369d5c57415ed969bc7bba13e1a190d195c1-filelists.xml.gz [following]
--2016-03-03 23:32:48--  https://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/updates/23/x86_64/repodata/0e95ae636347564e66b0e600c9a1369d5c57415ed969bc7bba13e1a190d195c1-filelists.xml.gz
Resolving www.mirrorservice.org (www.mirrorservice.org)... 212.219.56.184
Connecting to www.mirrorservice.org (www.mirrorservice.org)|212.219.56.184|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2016-03-03 23:32:48 ERROR 404: Not Found.

1.2 just to be clear, there is no HTTP proxy to worry about here

# echo $http_proxy

#

1.3 scratch my head, try again

# dnf check-update

Fedora 23 - x86_64 - Updates 1.3 MB/s | 20 MB 00:15

google-chrome 55 kB/s | 3.4 kB 00:00

Last metadata expiration check performed 0:00:00 ago on Thu Mar 3 23:35:26 2016.

google-chrome-stable.x86_64 49.0.2623.75-1 google-chrome

^ obviously this includes security updates...

graphite2.x86_64 1.3.6-1.fc23 updates

....Fedora security update...

pcre.x86_64 8.38-6.fc23 updates

...another Fedora security update.

1.4 NOTE

I then looked at the directory on mirrorservice.org in my browser (i.e. after the successful update check). The filelist had changed name to 85f1054756ada3a2a9ab2f6c40c23378c74afb22ba4599c3cbb46334be0820a1-filelists.xml.gz. So we were trying to fetch an old file which had been deleted.

2. Context

The investigation above started because I noticed the Fedora security updates above, but GNOME wasn't notifying me about them. GNOME Software showed 0 updates even after clicking refresh, which is not the behaviour I would expect.

pkcon update did show updates, although I forgot to record it. I don't know whether it included the security updates at that point.

After the successful update check with dnf, refreshing GNOME Software showed updates. At the time of writing, I know that dnf and PackageKit-on-Fedora use totally distinct cache directories. Therefore dnf populating it's cache was not the direct cause for GNOME Software to work.

2

My first guess was that mirrorservice.org didn't read the instructions and don't know how to mirror. In other words, their repository could appear inconsistent while it's being updated. The old filelists.xml.gz could be deleted before repomd.xml is updated to point to the new filelist. But it's very strange that such a big mirror would get it wrong.

Then I remembered the problem. download.fedoraproject.org is just broken. It redirects you to different repositories for each request. The problem is you can't assume individual repositories will update at exactly the same time. (And Fedora's master repository isn't formatted to support this, because it doesn't keep the previous filelist around).

The default configuration doesn't use download.fedoraproject.org, so it's fine. This only happened because I switched from metalink downloads and un-commented the default baseurl line, in the .repo config files. baseurl is great if you create your own Fedora repository to use locally, but otherwise you want to use the default metalink system, where your computer chooses which repositories(s) to download from.

In my case the inconsistency was probably between mirrorservice.org and the bytemark mirror. You can see the redirects with curl:

$ curl --head http://download.fedoraproject.org/
HTTP/1.1 302 Found
Date: Fri, 04 Mar 2016 15:34:58 GMT
Server: Apache/2.4.6 (Red Hat Enterprise Linux) OpenSSL/1.0.1e-fips mod_wsgi/3.4 Python/2.7.5
Location: https://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux//
AppTime: D=328174
AppServer: proxy02.fedoraproject.org
Content-Type: text/html; charset=UTF-8

$ curl --head http://download.fedoraproject.org/
HTTP/1.1 302 Found
Date: Fri, 04 Mar 2016 15:35:00 GMT
Server: Apache/2.4.6 (Red Hat Enterprise Linux) OpenSSL/1.0.1e-fips mod_wsgi/3.4 Python/2.7.5
Location: http://mirror.bytemark.co.uk/fedora/linux//
AppTime: D=363432
AppServer: proxy07.fedoraproject.org
Content-Type: text/html; charset=UTF-8
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.