Red Hat Bugzilla – Bug 509624
F10->11 upgrade failed to upgrade many rpms; broke yum
Last modified: 2014-01-21 18:10:16 EST
Description of problem:
I upgraded from Fedora 10 to Fedora 11, using the Fedora 11 DVD. After upgrading, "yum" no longer worked! Running "yum" gave the following error message:
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:
No module named yum
Please install a package which provides this module, or
verify that the module is installed correctly.
It's possible that the above module doesn't match the
current version of Python, which is:
2.6 (r26:66714, Mar 17 2009, 11:44:14)
[GCC 4.4.0 20090313 (Red Hat 4.4.0-0.26)]
If you cannot solve this problem yourself, please go to
the yum faq at:
Before upgrading, I had done a "yum -y upgrade" on Fedora 10 and was fully upgraded. Then I upgraded using the Fedora 11 DVD. After the DVD upgrade, there were around 400 packages left over from prior versions of Fedora (e.g., Fedora 9 or Fedora 10) that had not been upgraded. Prominent among them was "yum".
In particular, anaconda (the Fedora 11 DVD) failed to upgrade "yum" from the Fedora 10 version to the Fedora 11 version. After DVD upgrade, I still had
installed, instead of
I had to download the latter version by hand from
and install it by hand using "rpm -Uvh --force" to get "yum" working again.
The problem seems to be that anaconda/rpm/yum thought that yum-3.2.23-3.fc10 (the version on my system before upgrading; the latest version of yum available in Fedora 10) was newer than yum-3.2.22-4.fc11 (the version on the Fedora 11 DVD), and so declined to install the "older" package. In other words, it sees to be going by the version string (3.2.23-3 vs 3.2.22-4) instead of the distribution string (fc10 vs fc11).
This also broke a bunch of other components as well: there were around 400 other rpm packages that had not been upgraded, and this caused other parts of my system to break (but none as badly as being unable to use "yum"). Upgrading those manually fixed the problems.
This seems to be a serious problem: a novice probably can't be expected to diagnose and repair this problem, and the problem renders the system broken in various subtle ways with no easy way to get yum updates working again so the system can get into an unbroken state.
I'm afraid I don't have an easy way to reproduce this bug myself; I needed to use this system, so I fixed everything up by hand.
FYI, from reading the forums, I see that I'm not the only one with this problem: several others have reported it.
It occurs to me that I do have another F10 machine that I'll be upgrading to F11 at some point; if there's a fix, I can test it out on the other machine, if you like.
I had exactly the same problem on x86. After upgrading from an up to date F10 to F11 using the DVD I was left with F10's yum RPMs.
[root@bridge ~]# rpm -qa | egrep '^rpm|^yum'
[root@bridge ~]# egrep 'rpm-|yum-' upgrade.log
It also looks like this is another report of the same bug, but that is now closed.
Please excuse the "me to" post, but this will continue to affect upgrades and as pointed out above non-technical people will struggle to fix the fault.
Unfortunately, anaconda is doing exactly what it ought to be doing here. It sees a version of yum on the installed system that's version 3.2.23-3. You attempt to perform an upgrade from a source that has version 3.2.22-4. We ask yum to determine which version is newer in order to see if the yum package itself should be marked for upgrade. The already installed one has a later version number, so the package should not be upgraded.
In general, this is the behavior you want. You only get into trouble when an updates repo ships a later version of a package than is shipped with the installation source. I think you would hit the same problem if you tried to upgrade on the command line with yum. So, you either need to (1) enable the F11 updates repo and hope that the version of yum in there is later than the one you've got installed, or (2) downgrade the yum installed on your system before performing an upgrade. I'm not sure how you would know to do (2) beforehand.
Is this packaging/repo issue known to the yum guys?
> Unfortunately, anaconda is doing exactly what it ought to be doing here.
OK. Thanks for the explanation. Perhaps I filed this against the wrong Fedora component (it's often a bit mysterious to me how I should be filling out that part of the web form). Who should this bug be re-assigned to, to minimize the chances of it happening again?
I'm surprised you haven't gotten more reports of this bug, which makes me wonder if I'm understanding the impact of the bug correctly. If I understand it correctly, everyone who (a) starts from a F10 that's been recently updated, and (b) upgrades to F11 using the DVD, is going to end up with this problem and end up with a borked F11 install -- borked in a way that a large fraction of Fedora users probably can't be expected to know how to diagnose or recover from. Did I get that right? If so, that doesn't sound good. It means the F11 install DVD just doesn't work right for a significant fraction of users, despite the best intentions of everyone involved.
Does this need to be documented on the F11 Common Bugs page, to tell people how to fix it? Should it be re-assigned to someone working on documentation?
Should this be re-assigned to the yum team, to ensure that if someone ends up with a more recent version of yum (e.g., 3.2.23-3) than what's on the install disk (e.g., 3.2.22-4) then yum will still work? It's not clear to me why yum failed to be backwards compatible in this case. I wonder if that was intentional.
I have to say that I disagree with closing the bug as CANTFIX. I think this bug should be re-opened. It's sounding to me like this ought to be re-assigned to someone so that it doesn't happen again and so that users can be informed about how to recover from this problem. From the viewpoint of an Anaconda developer, it may well be that Anaconda is doing what it was specified to do. But look at it from the viewpoint of a user. The resulting behavior is totally screwed up. Can you help me figure out who it should be re-assigned to?
Further thoughts: should it be re-assigned to the team in charge of the f10-updates repository, so they can push out a new version of yum to the F10 updates repository that both works on F10 and is forwards compatible (in the sense that when it doesn't get replaced by the F11 install disk, then it will work on F11 as well)?
Should this be re-assigned to the folks who build the F11 install disk, so that they can re-spin a new F11 install disk to ensure that people who upgrade from here on in don't experience this problem?
I'll reassign to yum so they are aware of what's happened, but I'm not sure there's much they will be able to do either.
*** This bug has been marked as a duplicate of bug 506685 ***