cleaned yum, but: Error Downloading Packages: ghostscript-fonts - 5.50-13.1.1.noarch: failure: CentOS/ghostscript-fonts-5.50-13.1.1.noarch.rpm from base: [Errno 256] No more mirrors to try. texi2html - 1.76-4.fc6.noarch: failure: CentOS/texi2html-1.76-4.fc6.noarch.rpm from base: [Errno 256] No more mirrors to try.
jerry
On Tue, Jul 22, 2008 at 12:21 AM, Jerry Amundson jamundso@gmail.com wrote:
cleaned yum, but: Error Downloading Packages: ghostscript-fonts - 5.50-13.1.1.noarch: failure: CentOS/ghostscript-fonts-5.50-13.1.1.noarch.rpm from base: [Errno 256] No more mirrors to try. texi2html - 1.76-4.fc6.noarch: failure: CentOS/texi2html-1.76-4.fc6.noarch.rpm from base: [Errno 256] No more mirrors to try.
All mirrors failed with -
[Errno 9] Requested Range Not Satisfiable
jerry
On Tue, Jul 22, 2008 at 12:36 AM, Jerry Amundson jamundso@gmail.com wrote:
On Tue, Jul 22, 2008 at 12:21 AM, Jerry Amundson jamundso@gmail.com wrote:
cleaned yum, but: Error Downloading Packages: ghostscript-fonts - 5.50-13.1.1.noarch: failure: CentOS/ghostscript-fonts-5.50-13.1.1.noarch.rpm from base: [Errno 256] No more mirrors to try. texi2html - 1.76-4.fc6.noarch: failure: CentOS/texi2html-1.76-4.fc6.noarch.rpm from base: [Errno 256] No more mirrors to try.
All mirrors failed with -
[Errno 9] Requested Range Not Satisfiable
Only x86_64. i386 installs successfully.
jerry
(Cross-posted to Mirror list due to probable relevancy)
Jerry Amundson wrote:
Error Downloading Packages: ghostscript-fonts - 5.50-13.1.1.noarch: failure: CentOS/ghostscript-fonts-5.50-13.1.1.noarch.rpm from base: [Errno 256] No more mirrors to try. texi2html - 1.76-4.fc6.noarch: failure: CentOS/texi2html-1.76-4.fc6.noarch.rpm from base: [Errno 256] No more mirrors to try.
All mirrors failed with -
[Errno 9] Requested Range Not Satisfiable
Only x86_64. i386 installs successfully.
I'm showing a number of 416 errors in my mirror's Apache log files. They all appear to be for CentOS 5.2 x86_64 noarch packages.
It's possible that this is due to some problems that are currently being discussed in -mirror. hughesjr recently rebuilt the hardlink structure for 5.2 x86_64 noarch packages, following reports of files that failed to match their checksums.
I personally have set:
FileETag MTime
in my mirror Apache config, which probably has left my server caching information and advertising ETag validity for files that have since shrunk following the relinking. Clients are left asking for more file than currently exists.
Restarting the server is an immediate fix; but I should probably also be including at least Size in there... or maybe just unset it and let the default "INode MTime Size" work its magic.
It's possible that the metadata files also have some influence on what content ranges are requested, but I'm not a Yum expert so I can't say for sure.
-Brandon
Brandon Davidson wrote:
Restarting the server is an immediate fix; but I should probably also be including at least Size in there... or maybe just unset it and let the default "INode MTime Size" work its magic.
It's possible that the metadata files also have some influence on what content ranges are requested, but I'm not a Yum expert so I can't say for sure.
It appears that I was too quick to assign blame. I am still seeing 416 errors, and there are apparently other problems with the metadata. I guess Yum requests a content range based on the size reported in the primary metadata, which is now incorrect for a significant number of files.
-Brandon
Brandon Davidson wrote:
Brandon Davidson wrote:
Restarting the server is an immediate fix; but I should probably also be including at least Size in there... or maybe just unset it and let the default "INode MTime Size" work its magic.
It's possible that the metadata files also have some influence on what content ranges are requested, but I'm not a Yum expert so I can't say for sure.
It appears that I was too quick to assign blame. I am still seeing 416 errors, and there are apparently other problems with the metadata. I guess Yum requests a content range based on the size reported in the primary metadata, which is now incorrect for a significant number of files.
I have rerun the metadata on the master mirror and it is going out to the other mirrors, this should clear up soon.
-
Brandon Davidson -
Jerry Amundson -
Johnny Hughes