If I switch to using rsync, that will let me get rid of the createrepo
portion of the task won't it?
I had tried it a year or two ago and something about made it not work
well for us but I can't recall now what it was. But I'm willing to give
it another shot.
On 04/10/2013 11:44 AM, Pat Riehecky wrote:
Hi Stephen,
I'd suggest a 'yum clean expire-cache' on the systems not recognizing
the new packages. You may have old metadata on them.
I would encourage you to consider mirroring via rsync, rather than
reposync. Rsync will let you preserve hardlinks (and we've got a lot
of them) which should translate into less space used on your end.
http://www.scientificlinux.org/download/mirroring/mirror.rsync
Pat
On 04/10/2013 11:30 AM, Stephen Berg (Contractor) wrote:
I have a locally hosted mirror of SL 6.[234] to manage about 200
systems. I use a reposync and createrepo to keep them updated daily.
So far I've been accomplishing my upgrades for minor releases using
yum and haven't had any troubles. But the systems that I've upgraded
to 6.4 are showing some strange yum behavior.
After the upgrade the system does not see any updates. For instance
on 6.3 the autofs package is 5.0.5-55, 6.4 has 5.0.5-73. Systems that
I did a yum upgrade on will not see 5.0.5-73 as an available update.
What I've tried so far:
If I change yum to use the scientificlinux.org repos the updated
package is seen with no problem.
I can install the new autofs package with a "yum localinstall
<filename>" and that has no problems so it shouldn't a problem in the
rpm itself unless there's a problem that effects createrepo but not
installation of the rpm.
I've poked around in the primary.xml.gz file and it appears to be
correct but I'm not sure that I'd spot a problem in there.
It seems to be some problem with the createrepo utility but I've had
no luck finding any errors or warnings to indicate where the fault
might be.
I'm going to try to find a spare system that I can do a clean install
of 6.4 and see what happens with that.
Does anyone have an idea of what could cause this?
--
Stephen Berg
Systems Administrator
NRL Code: 7320
Office: 228-688-5738
[email protected]
