On Tue, 8 Nov 2005, Colm MacCarthaigh wrote:
On Tue, Nov 08, 2005 at 11:45:21AM +0100, Dag Wieers wrote:
On Mon, 7 Nov 2005, Johnny Hughes wrote:
On Mon, 2005-11-07 at 17:00 -0500, John Hinton wrote:
Yes and I'm glad I have both version 3 and version 4 servers as version 3 is updating just fine, but all of my CentOS v 4 machines are stuck in lala land for about 5 days now. Happened once before, but was fixed, but it's back....
Setting up Update Process Setting up repositories //var/cache/yum/dag/repomd.xml:1: parser error : Document is empty
^ //var/cache/yum/dag/repomd.xml:1: parser error : Start tag expected, '<' not found
^ dag 100% |=========================| 0 B 00:00 http://apt.sw.be/redhat/el4/en/i386/dag/repodata/repomd.xml: [Errno -1] Error importing repomd.xml for dag: Error: could not parse file //var/cache/yum/dag/repomd.xml Trying other mirror. Cannot open/read repomd.xml file for repository: dag failure: repodata/repomd.xml from dag: [Errno 256] No more mirrors to try. Error: failure: repodata/repomd.xml from dag: [Errno 256] No more mirrors to try.
Same deal since about Wednesday or Friday of last week.
I'm about to go comment out my chance at beautiful women. :)
Pick a different mirror, that one is also an Apache Project test server :)
Sigh. And chances are they don't know something has been wrong for the last couple of weeks...
This mail contains no useful information. What is the problem, and what do you want us to do?
I don't know what the problem is. Either the file is empty on the filesystem (corruption on the filesystem level or problems with rsync or NFS) or the web server is handing out empty files under certain conditions.
Without access to the system I have no clue whether the filesystem is the problem or it is Apache related. I bet it is Apache's problem as mirrors of Heanet do not seem to have this problem. (This is different than when it was a NFS problem with the same symptoms)
I checked and I currently do not see a problem:
http://apt.sw.be/redhat/el4/en/i386/dag/repodata/repomd.xml http://mirrors.ircam.fr/pub/dag/redhat/el4/en/i386/dag/repodata/repomd.xml
I have seen all sorts of reports from people saying that it sometimes works, sometimes not, and people saying it never works.
Also not sure if it could be proxy or transparant-proxy related.
If you could check whether there are times where Apache logs a zero-file transfer for repomd.xml (or other files in the repository) that might help find the cause.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
Dag Wieers wrote:
On Tue, 8 Nov 2005, Colm MacCarthaigh wrote:
On Tue, Nov 08, 2005 at 11:45:21AM +0100, Dag Wieers wrote:
On Mon, 7 Nov 2005, Johnny Hughes wrote:
On Mon, 2005-11-07 at 17:00 -0500, John Hinton wrote:
Yes and I'm glad I have both version 3 and version 4 servers as version 3 is updating just fine, but all of my CentOS v 4 machines are stuck in lala land for about 5 days now. Happened once before, but was fixed, but it's back....
Setting up Update Process Setting up repositories //var/cache/yum/dag/repomd.xml:1: parser error : Document is empty
^ //var/cache/yum/dag/repomd.xml:1: parser error : Start tag expected, '<' not found
^ dag 100% |=========================| 0 B 00:00 http://apt.sw.be/redhat/el4/en/i386/dag/repodata/repomd.xml: [Errno -1] Error importing repomd.xml for dag: Error: could not parse file //var/cache/yum/dag/repomd.xml Trying other mirror. Cannot open/read repomd.xml file for repository: dag failure: repodata/repomd.xml from dag: [Errno 256] No more mirrors to try. Error: failure: repodata/repomd.xml from dag: [Errno 256] No more mirrors to try.
Same deal since about Wednesday or Friday of last week.
I'm about to go comment out my chance at beautiful women. :)
Pick a different mirror, that one is also an Apache Project test server :)
Sigh. And chances are they don't know something has been wrong for the last couple of weeks...
This mail contains no useful information. What is the problem, and what do you want us to do?
I don't know what the problem is. Either the file is empty on the filesystem (corruption on the filesystem level or problems with rsync or NFS) or the web server is handing out empty files under certain conditions.
Without access to the system I have no clue whether the filesystem is the problem or it is Apache related. I bet it is Apache's problem as mirrors of Heanet do not seem to have this problem. (This is different than when it was a NFS problem with the same symptoms)
I checked and I currently do not see a problem:
http://apt.sw.be/redhat/el4/en/i386/dag/repodata/repomd.xml http://mirrors.ircam.fr/pub/dag/redhat/el4/en/i386/dag/repodata/repomd.xml
I have seen all sorts of reports from people saying that it sometimes works, sometimes not, and people saying it never works.
Also not sure if it could be proxy or transparant-proxy related.
If you could check whether there are times where Apache logs a zero-file transfer for repomd.xml (or other files in the repository) that might help find the cause.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] _______________________________________________
Well, as per usual, the TV fixed itself on the way to the repair shop. An hour or so after posting the original, it was fixed (after about three to five days).
The repomd.xml file on my machine was empty. Looking at the message from yum, it couldn't find '<' which I would assume is an opening tag which is expected. My 'best guess' is that the file is empty, or a cache of the file is empty. I assume yum on CentOS 4 uses xml whereas yum on CentOS 3 does not? As I have never had this problem on v.3 machines.
This has been an on again and off again problem. Perhaps the 'some' who never connect, are just trying at bad times?
What would be helpful, at least until you can get to the root of the problem, is to post in the FAQ section, alternative mirrors. As these could change, and I would assume you would know about that pretty quickly... the 'official' DAG mirror list could be kept current on the site, allowing us to feel more secure about selections.
It's just a bit of a pain to go comment you out on 6 or so machines in order to get CentOS updates. Not to mention the chance of 'not' having beautiful women flocking to your door.
Thanks so much for all of your work. It is really appreciated and so well done... Stuff like this is just so non-Dag-like.
John Hinton
On Tue, 8 Nov 2005, John Hinton wrote:
Dag Wieers wrote:
What would be helpful, at least until you can get to the root of the problem, is to post in the FAQ section, alternative mirrors. As these could change, and I would assume you would know about that pretty quickly... the 'official' DAG mirror list could be kept current on the site, allowing us to feel more secure about selections.
Well, the best way to configure the RPMforge repository is to install the rpmforge-release package. It includes the configuration for using a mirror-list.
I should put this into the RPMforge FAQ at:
It's just a bit of a pain to go comment you out on 6 or so machines in order to get CentOS updates. Not to mention the chance of 'not' having beautiful women flocking to your door.
Well, in my opinion you should file a bug-report (or feature request) for yum. As it seems silly that 1 defunct mirror is blocking all other updates.
Thanks so much for all of your work. It is really appreciated and so well done... Stuff like this is just so non-Dag-like.
You're welcome. I have little to do with problems on the server/mirror side. Especially when problems seems random. I have no other access than my users for the HEAnet main mirror. And I have no alternative for HEAnet (especially since I don't know how much visitors or bandwidth is required to run the main mirror).
I guess my best bet is to add contact-information for HEAnet available in the FAQ, but I am afraid to forward unrelated issues to them.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]