I raised a ticket. (https://ggus.eu/ws/ticket_info.php?ticket=75689)
I think it boils down to the fact that
http://www.mirrorservice.org/sites/download.fedora.redhat.com/pub/epel/5/x86_64/repodata/repomd.xml
has the following section...
<data type="filelists_db">
<location
href="repodata/b38aad9db628346f8b929d294c16d1a75183110c-filelists.sqlite.bz2"/>
<checksum type="sha">b38aad9db628346f8b929d294c16d1a75183110c</checksum>
<timestamp>1318448100</timestamp>
<size>5707441</size>
<open-size>26924032</open-size>
<open-checksum
type="sha">eb570fd5f6864c64b422b86bc5c2936b03260566</open-checksum>
<database_version>10</database_version>
</data>
and
repodata/b38aad9db628346f8b929d294c16d1a75183110c-filelists.sqlite.bz2
seems to have been removed over the weekend. Something epel have to fix.
Regards,
Emyr
On 25/10/11 12:22, Daniela Bauer wrote:
> Hi,
>
> If the instructions given on the UMD website don't work, please file a
> GGUS ticket: www.ggus.eu
> (You might have to register.) That way it will reach the people who
> can actually fix the problem/the documentation.
>
> Cheers,
>
> Daniela
>
>
>
> On 25 October 2011 12:07, emyr.james<[log in to unmask]> wrote:
>> Hi,
>> I'm narrowing down this issue...
>> I did a fresh install of a minimum SL5.7, did yum install openldap-servers
>> and it worked fine. I then removed the openldap-servers package and
>> installed the epel-release rpm that is recommended here...
>> http://repository.egi.eu/category/umd_releases/distribution/umd_1/.
>> I then tried to yum install openldap-servers again and it no longer works (I
>> get the mirror issue reported earlier). So I guess the epel-release package
>> is now broken ?
>> Any ideas where to go from here ?
>> Regards,
>> Emyr
>>
>> On 24/10/11 16:40, Stephen Jones wrote:
>>> Hi Emyr,
>>>
>>> I take a snapshot of the whole repository first to isolate us because it
>>> totally does your head in when it keeps changing. The whole directory was
>>> updated again 22 Oct. I'd try a "yum clean all", and see if it's still
>>> broken. When it works, take a snapshot and use that from then on. But you'll
>>> have to make custom entries in /etc/yum.repos.d.
>>>
>>> Steve
>>>
>>> emyr.james wrote:
>>>> Hi,
>>>> I'm redoing the auto install that I was working on last week but it's
>>>> failing this week. I think something has changed regarding the epel
>>>> repositories and that is causing a problem.
>>>>
>>>> I've installed the epel and umd repositories as detailed here...
>>>>
>>>> http://repository.egi.eu/category/umd_releases/distribution/umd_1/
>>>>
>>>> When I try to do a yum install emi-bdii-site it gets so far but then
>>>> bombs out with...
>>>>
>>>> [root@grid-bdii ~]# yum install emi-bdii-site
>>>> Loaded plugins: kernel-module, priorities
>>>> 448 packages excluded due to repository priority protections
>>>> Setting up Install Process
>>>> Resolving Dependencies
>>>> --> Running transaction check
>>>> ---> Package emi-bdii-site.x86_64 0:1.0.0-1.sl5 set to be updated
>>>> --> Processing Dependency: emi-version for package: emi-bdii-site
>>>> --> Processing Dependency: glite-yaim-bdii for package: emi-bdii-site
>>>> --> Processing Dependency: glite-info-site for package: emi-bdii-site
>>>> --> Processing Dependency: glite-info-static for package: emi-bdii-site
>>>> --> Processing Dependency: bdii for package: emi-bdii-site
>>>> --> Processing Dependency: glue-schema for package: emi-bdii-site
>>>> --> Processing Dependency: glite-info-provider-service for package:
>>>> emi-bdii-site
>>>> --> Processing Dependency: bdii-config-site for package: emi-bdii-site
>>>> --> Processing Dependency: glite-yaim-core for package: emi-bdii-site
>>>> --> Processing Dependency: glite-info-provider-ldap for package:
>>>> emi-bdii-site
>>>> --> Running transaction check
>>>> ---> Package bdii.noarch 0:5.2.4-1.el5 set to be updated
>>>> --> Processing Dependency: expect for package: bdii
>>>> --> Processing Dependency: openldap-servers for package: bdii
>>>> --> Processing Dependency: openldap-clients for package: bdii
>>>> ---> Package bdii-config-site.noarch 0:1.0.3-1.el5 set to be updated
>>>> ---> Package emi-version.x86_64 0:1.2.0-1.sl5 set to be updated
>>>> ---> Package glite-info-provider-ldap.noarch 0:1.4.0-1.el5 set to be
>>>> updated
>>>> --> Processing Dependency: perl(LWP::Simple) for package:
>>>> glite-info-provider-ldap
>>>> ---> Package glite-info-provider-service.noarch 0:1.6.3-1.el5 set to be
>>>> updated
>>>> ---> Package glite-info-site.noarch 0:0.4.0-1.el5 set to be updated
>>>> ---> Package glite-info-static.noarch 0:0.2.0-1.el5 set to be updated
>>>> ---> Package glite-yaim-bdii.noarch 0:4.3.3-1.el5 set to be updated
>>>> ---> Package glite-yaim-core.noarch 0:5.0.0-1.sl5 set to be updated
>>>> ---> Package glue-schema.noarch 0:2.0.7-1.el5 set to be updated
>>>> --> Running transaction check
>>>> ---> Package expect.x86_64 0:5.43.0-5.1 set to be updated
>>>> ---> Package openldap-clients.x86_64 0:2.3.43-12.el5_6.7 set to be
>>>> updated
>>>> ---> Package openldap-servers.x86_64 0:2.3.43-12.el5_6.7 set to be
>>>> updated
>>>>
>>>> http://www.mirrorservice.org/sites/download.fedora.redhat.com/pub/epel/5/x86_64/repodata/b38aad9db628346f8b929d294c16d1a75183110c-filelists.sqlite.bz2:
>>>> [Errno 14] HTTP Error 404: Not Found
>>>> Trying other mirror.
>>>>
>>>> http://mirror.bytemark.co.uk/fedora/epel/5/x86_64/repodata/b38aad9db628346f8b929d294c16d1a75183110c-filelists.sqlite.bz2:
>>>> [Errno 14] HTTP Error 404: Not Found
>>>> Trying other mirror.
>>>>
>>>> http://mirror01.th.ifl.net/epel/5/x86_64/repodata/b38aad9db628346f8b929d294c16d1a75183110c-filelists.sqlite.bz2:
>>>> [Errno 14] HTTP Error 404: Not Found
>>>> Trying other mirror.
>>>>
>>>> http://mirrors.coreix.net/fedora-epel/5/x86_64/repodata/b38aad9db628346f8b929d294c16d1a75183110c-filelists.sqlite.bz2:
>>>> [Errno 14] HTTP Error 404: Not Found
>>>> Trying other mirror.
>>>> Error: failure:
>>>> repodata/b38aad9db628346f8b929d294c16d1a75183110c-filelists.sqlite.bz2 from
>>>> epel: [Errno 256] No more mirrors to try.
>>>> You could try using --skip-broken to work around the problem
>>>> You could try running: package-cleanup --problems
>>>> package-cleanup --dupes
>>>> rpm -Va --nofiles --nodigest
>>>> The program package-cleanup is found in the yum-utils package.
>>>>
>>>> The directory listing@
>>>> http://www.mirrorservice.org/sites/download.fedora.redhat.com/pub/epel/5/i386/repodata/
>>>> doesn't have anything related to b38aad9db628346f8b929d294c16d1a75183110c,
>>>> and the files were modified on the 18th of October 2011. This was working ok
>>>> up till friday. Maybe some files were removed from the mirror over the
>>>> weekend. Any ideas how I can proceed from here ? I take it there must be a
>>>> problem with umd-release-1.0.2-1.el5.noarch.rpm now referring to out of
>>>> date files ?
>>>>
>>>> Regards,
>>>> Emyr
>>>> On 21/10/11 10:21, Daniela Bauer wrote:
>>>>> No, SGE doesn't change things, if in doubt it's worse.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Daniela
>>>>>
>>>>> On 20 October 2011 16:39, Stuart Purdie<[log in to unmask]>
>>>>> wrote:
>>>>>> On 20 Oct 2011, at 15:34, emyr.james wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>> I'm currently trying to finish off installing the grid middleware
>>>>>>> stack so we can become a fully fledged tier 2.
>>>>>>> I'm installing 4 machines, setting them up as
>>>>>>>
>>>>>>> * Site BDII
>>>>>>> * Cream CE
>>>>>>> * Storm SE
>>>>>>> * APEL
>>>>>>>
>>>>>>> I'm splitting the CE ans SE across their respective nodes and feynman
>>>>>>> - our cluster head node. I.e. The blah parser will go on feynman since that
>>>>>>> is running SGE, with the rest of the CE stuff on it's own dedicated machine,
>>>>>> My general advice is: Don't do this. The Blah parser is the most
>>>>>> fragile of the parts of the CREAM CE, so for multiple CE's for reliability
>>>>>> you want multiple Blah parsers. Those with SGE can no doubt point out if
>>>>>> SGE changes things, but I doubt it.
>>>>>>
>>>>>
>>>>
>>>
>
>
|