yum not working for fc4

[dhufish]

Hiya all,

I've been having troubles with yum recently. We've got several FC4 pc's here that all show a similar error:

http://archives.fedoraproject.org/pub/archive/fedora/linux/core/updates/4/i386/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum
Trying other mirror.
Error: failure: repodata/primary.xml.gz from updates-released: [Errno 256] No more mirrors to try.

I googled about and did a fair bit of homework, asked colleagues here too.

What seems to be happening is:

• yum downloads this 'primary.xml.gz' file in un-zipped form
• the 'archives.fedoraproject.org' site seems to be delivering such .gz files in unzipped form to the downloader
• this is screwing up the checksum tests done by yum

For example:

1. visit the http site in your browser: archives.fedoraproject.org/pub/archive/fedora/linux/core/updates/4/i386/repodata/
2. Notice the file size of "primary.xml.gz" mentioned here is 299KB
3. Download the file. Notice that your downloaded size is now 2MB

This behaviour isn't occuring on other sites with .gz files, just on this fedora archives site, so I'm suspecting something has changed with server settings there?

Anyway, thought I'd better mention it.

[marko]

Fedora 4 is so old it's not even in the archives, the fedora versions I see in the archives are
7 through 14:

(see the URL for updates: http://archives.fedoraproject.org/pub/archive/fedora/linux/updates/
and the URL for releases: http://archives.fedoraproject.org/pu...inux/releases/ )

So that's why you have no yum capability on Fedora 4

[dhufish]

Nope, fc4 is still in the archives, at the address mentioned previously:

archives.fedoraproject.org/pub/archive/fedora/linux/core/updates/4/i386/repodata/

I remember successfully installing things from it just a few weeks ago, so this problem has only arisen recently.

PS. In-case others are having similar problems, I managed to make a dodgy workaround for now, by hacking the yum python code as follows:

• Inside "repos.py", I added an "import pdb" at the start (to install the debugger), and a "pdb.set_trace()" just before the "try: l_csum = self._checksum(...)" checksum test (ie, add a breakpoint just prior to the checksum test)
• I also make sure this checking function always returns 1 (even when checksum doesn't match!)
• I then ran "sudo yum install tree"
• Upon each breakpoint hit:
  • to learn which file is in question, type "p file" in the python debugger, and it will display the path of the .gz file
  • At the cmd-line, I go to the "primary.xml.gz" file in question
  • mv primary.xml.gz primary.xml
  • gzip primary.xml
  • in the python debugger, press 'c' to continue

Very dodgey hack, but proves that the fc4 archived repo still works, and is just having this .gz auto-unzipping problem. So to get around it for now, I'm breaking prior to the checksum test, re-zipping the file, then continuing (while ignoring the actual checksum outcome).

[marko]

Ok, I didn't noticed the slight change in your URL, I didn't know of that archive.

No idea what your problem is

[dhufish]

Yep, mentioned that in the initial post too I visited that site with a browser, I noticed the genuine size of the "primary.xml.gz" file is stated there as being 299KB. But if I download the file, regardless from which machine I try, the downloaded file is about "2MB" in size.

I'm suspecting that the 'archives.fedoraproject.org' site might have some server setting that is automatically unzipping these files prior to offering the download?

Perhaps as a test, could you try download the "primary.xml.gz" file, and see if the file you get is 299KB or 2MB?

If it happens to you too, then this prob is not unique to my pc/environment, but everyone is affected globally, and looks more likely to be due to the fedora server settings (or that's my current guessfor now ).

[marko]

It downloaded as a valid gzip file, about 305kB and tests as okay:

(note, I used "Save Link As")

gzip -tv primary.xml.gz
primary.xml.gz: OK

gzip -lv primary.xml.gz
method crc date time compressed uncompressed ratio uncompressed_name
defla 225c85e6 May 21 21:46 305821 2358694 87.0% primary.xml

[dhufish]

Thanks for checking Marko. Oh... Interesting... So it's not the fedora server then... I remember reading in some threads that another point of suspicion is proxy servers...

Yep, I am using my company's proxy server (mandatory here), so perhaps that is the next point I'll need to investigate. I'll contact the IT team here and delve deeper into it. Maybe they have been fiddling with settings...

Thanks again.

[bob]

Moved to EOL

Originally Posted by dhufish

Hiya all,

I've been having troubles with yum recently. We've got several FC4 pc's here that all show a similar error:

http://archives.fedoraproject.org/pub/archive/fedora/linux/core/updates/4/i386/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum
Trying other mirror.
Error: failure: repodata/primary.xml.gz from updates-released: [Errno 256] No more mirrors to try.

I googled about and did a fair bit of homework, asked colleagues here too.

What seems to be happening is:

• yum downloads this 'primary.xml.gz' file in un-zipped form
• the 'archives.fedoraproject.org' site seems to be delivering such .gz files in unzipped form to the downloader
• this is screwing up the checksum tests done by yum

For example:

1. visit the http site in your browser: archives.fedoraproject.org/pub/archive/fedora/linux/core/updates/4/i386/repodata/
2. Notice the file size of "primary.xml.gz" mentioned here is 299KB
3. Download the file. Notice that your downloaded size is now 2MB

This behaviour isn't occuring on other sites with .gz files, just on this fedora archives site, so I'm suspecting something has changed with server settings there?

Anyway, thought I'd better mention it.

Why would you want FC4?, I hope these machines are isolated from the net as the have many security flaws.

[dhufish]

Well, it's not necessarily that we "want" them, just a certain generation of software within the company seems to have been tied to the various packages that came with that OS version.

So for the most part, yes, most of our machines are running newer OS, just a few remaining to support some legacy software really.

Still, on the occasions they get used, we bump into an issue or two like this. Just wanted to chase this one down a bit further.

Particularly if in this case, if it really is a problem with our proxy server, I'd rather the IT team investigate it and get it fixed, as an issue like this might affect other people, on other/newer OS too.

[dhufish]

Yep, the IT team looked into this. I only managed to comprehend the gist of it. Something to do with the HTTP 1.1 compression settings used by our proxy and/or firewall.

There was some mix-up where our proxy-server was requesting the file with http 1.1 compression (which is gzip), and assuming the response from the fedora-archive server (which provided the "primary.xml.gz" file) to be the file-requested in compressed form, hence it unzipped it.

Our IT team learnt from Microsoft that this problem only seems to happen on older http-servers, as we've downloaded gzip files from other sites without this issue.

So for now, our IT team has just added the archives.fedoraproject.org site onto an exception list, so that the proxy won't request for files via http 1.1 compression, and this has made the problem go away for us.

Thought it was worth mentioning here, in-case others experience this too, probably people trying to access the site from Microsoft-based workplaces?

A colleague noticed that the archives.fedoraproject.org site is using a slightly old apache server "Apache/2.2.15"... Perhaps an upgrade *might* make the problem go away too? Not sure...