Red Hat Bugzilla – Bug 448012
yum clean fails when non-RHN repositories are configured
Last modified: 2010-11-10 06:46:39 EST
Description of problem:
The latest release of yum for RHEL5 (yum-3.2.8-9.el5_2.1), fails to successfully
execute the command "yum clean" when third-party yum repositories are configured
(e.g. in /etc/yum/repos.d ). This problem did not exist in yum-3.0.1-5.el5.
It appears that the function formReposForClean() in
/usr/lib/yum-plugins/rhnplugin.py is trying to create a list of repos to clean
up including the repos that yum loads from its configuration files, as well as
the repos that are provided by the rhnplugin. It tries to find the latter by
looking in the yum cache directory directly and appending them to the list of
repos to clean, but this causes the RepoStorage object to raise an exception
when formReposForClean() tries to add a repo that is provided by a configuration
file and not the rhnplugin. This is because those repos are already added to the
RepoStorage object by the earlier call to conduit.getRepos().
Steps to Reproduce:
1. add a third-party yum repository configuration file in /etc/yum.repos.d
2. yum list foo
# to read metadata into cache
3. yum clean all
# yum clean all
Loading "rhnplugin" plugin
Loading "security" plugin
Repository rpmforge is listed more than once in the configuration
# yum clean all
Loading "rhnplugin" plugin
Loading "security" plugin
Cleaning up Everything
This can be fixed easily by simply checking whether the repo to add (whose name
was found in the cache directory) already exists in the RepoStorage object (i.e.
it was loaded from a configuration file). If it already exists; don't try to add
it again. I am attaching a patch illustrating this fix.
Created attachment 306426 [details]
patch formReposForClean() in rhnplugin.py to not add repos to RepoStorage object that already exist in it
Correction: the file /usr/lib/yum-plugins/rhnplugin.py is actually owned by the
package yum-rhn-plugin (not yum itself), and the patch is against
*** Bug 448138 has been marked as a duplicate of this bug. ***
I have also opened Red Hat Support case #1829520 to attempt to promote QA
acceptance of a fix for this issue. It is unclear from a customer perspective
how the public-facing Bugzilla system and the paid-customer-facing Oracle CRM
system are integrated, so I figured it best to submit entries in each and
Based on the suggestion of the Red Hat Support tech, I tried downgrading to the
previous version of the yum-rhn-plugin package (yum-rhn-plugin-0.5.3-6.el5), and
confirmed that the problem does not occur with this version of the package. This
seems to indicate that the bug was introduced in yum-rhn-plugin-0.5.3-6.el5_2.6.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
What are the advantages of yum-rhn-plugin-0.5.3-6.el5_2.6 vs the 0.5.3-6.el5
release? The changelog
not explicit at all. If I understand correctly, by trying to fix Bug 447402, the
annoyance was introduced.
(In reply to comment #6)
> What are the advantages of yum-rhn-plugin-0.5.3-6.el5_2.6 vs the 0.5.3-6.el5
The bug fixed was noted in the errata:
This package addresses the following bug:
* yum clean all would not remove packages from the cache correctly, leaving
downloaded rpms in /var/cache/yum/rhel*/packages/. This updated package
fixes the issue and yum clean all now removes packages from the cache
Bugs fixed (see bugzilla for more information)
447402 - yum-rhn-plugin doesn't enable RHN repos for 'yum clean' command, so
As I understand the situation: with yum-rhn-plugin-0.5.3-6.el5 running "yum
clean all" would not clear the yum cache for RHN repos (bug 447402), but would
clear the yum cache for non-RHN repos. With yum-rhn-plugin-0.5.3-6.el5_2.6
running "yum clean all" will clear the yum cache for RHN repos if and only if
there are no non-RHN repos configured; if any non-RHN repos are configured yum
throws an error and the cache is not cleared.
*** Bug 455401 has been marked as a duplicate of this bug. ***
I had opened a support ticket about this very issue. I, for some reason, had difficulties noticing that this issue was previously reported. The response that I received from technical support was:
"Unfortunately this is a bug. With yum-rhn-plugin-0.5.3-6.el5_2.6 running "yum clean all" will clear the yum cache for RHN repos if and only if there are no non-RHN repos configured; if any non-RHN repos are configured yum throws an error and the cache is not cleared.
Which will get fixed in release 5.3.0."
So assume this means that it is definitely on the 5.3.0 release schedule.
We'll be addressing this issue in 5.3.0.
It seems that the root cause of the problem with yum-rhn-plugin-0.5.3-6.el5_2.6
is that it cycles through all repos twice twice and carefully shoots itself in the foot, first putting the external repos into its list, and then complaining on the second pass that it put the repo into its list.
Please note that if this bug had been fixed in a timely manner, Satellite Server customers running Satellite Server 4.2 receiving the hot fix for database corruption might have been able to clean up the mess on client systems with
yum clean all
rm -rf /var/cache yum
Fixing this problem with an errata rather than waiting until the quarterly release might forestall more problems in the event of another Satellite Server or other RHN server-side cache corruption issue.
I have also opened a service request on this issue. SR 1833690
I have documented the use case of
yum clean all --noplugins
not cleaning up the cache in BZ 459666
I should never have been told to use the "--noplugins" option.
To get the RHN repos, you need a functioning yum-rhn-plugin.
I edited /usr/lib/yum-plugins/rhnplugin.py with the patch offered above as an attachment, and confirmed that "yum clean all" runs and cleans up properly.
DEFINITELY get this patch out to the world.
(Mind you, my personal taste would be to find out why yum was stepping through all the repos twice, and fix the way the loop runs rather than to just add
a try/except to prevent the redundant repos.add calls from operating,
but its you're codebase...)
*** Bug 459666 has been marked as a duplicate of this bug. ***
*** Bug 460294 has been marked as a duplicate of this bug. ***
This bugzilla has Keywords: Regression.
Since no regressions are allowed between releases,
it is also being marked as a blocker for this release.
Please resolve ASAP.
Fix confirmed with 0.5.3-26.el5.
When is this moving out of beta so that it actually gets on production systems?
Soon. We can't release/announce GA dates, but you can most likely extrapolate from previous Beta to GA dates...
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.