Bug 509624
| Summary: | F10->11 upgrade failed to upgrade many rpms; broke yum | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | D. Wagner <daw-redhatbugzilla> |
| Component: | yum | Assignee: | Seth Vidal <skvidal> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | low | ||
| Version: | 11 | CC: | ffesti, james.antill, maxamillion, mike.fleetwood, pmatilai, rmaximo, tim.lauridsen, vanmeeuwen+fedora |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-07-07 15:41:23 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
D. Wagner
2009-07-04 07:43:26 UTC
FYI, from reading the forums, I see that I'm not the only one with this problem: several others have reported it. http://forums.fedoraforum.org/showthread.php?t=224053 http://forums.fedoraforum.org/showthread.php?t=224308 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' rpm-4.7.0-1.fc11.i586.rpm rpm-libs-4.7.0-1.fc11.i586.rpm rpm-python-4.7.0-1.fc11.i586.rpm yum-3.2.23-3.fc10.noarch.rpm yum-metadata-parser-1.1.2-12.fc11.i586.rpm yum-utils-1.1.22-1.fc10.noarch.rpm [root@bridge ~]# egrep 'rpm-|yum-' upgrade.log Upgrading PackageKit-yum-plugin-0.4.6-8.fc11.i586 Upgrading rpm-4.7.0-1.fc11.i586 Upgrading rpm-libs-4.7.0-1.fc11.i586 Upgrading rpm-python-4.7.0-1.fc11.i586 Upgrading PackageKit-yum-0.4.6-8.fc11.i586 Upgrading deltarpm-3.4-16.fc11.i586 Upgrading yum-metadata-parser-1.1.2-12.fc11.i586 Upgrading anaconda-yum-plugins-1.0-4.fc11.noarch It also looks like this is another report of the same bug, but that is now closed. https://bugzilla.redhat.com/show_bug.cgi?id=504888 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. Thanks, Mike 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 *** |