Bug 506685 - (yum-f10-evr) Upgrade from F10 (all updates) to F11 (no updates) leaves non functional yum
Upgrade from F10 (all updates) to F11 (no updates) leaves non functional yum
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
https://fedoraproject.org/wiki/Common...
: CommonBugs
: 507040 507057 507116 509624 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-18 06:23 EDT by Simon Andrews
Modified: 2014-01-21 18:10 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-22 10:29:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Upgrade log from the affected machine (46.15 KB, text/plain)
2009-06-18 06:25 EDT, Simon Andrews
no flags Details

  None (edit)
Description Simon Andrews 2009-06-18 06:23:02 EDT
Description of problem:
I did an nfsiso upgrade of a fully up to date F10 install and upon booting the new F11 system yum was not functional but gave an error saying it could not find the yum python module.

Looking in rpm I could see that the system still had the F10 yum installed.  Trying to manually upgrade to the yum rpm on the DVD failed since the F10 yum was considered to be newer.

This didn't affect some earlier upgrades I did, and seems to be the result of installing the latest yum (yum-3.2.23-3.fc10.noarch) before the upgrade.

Forcibly uninstalling the F10 yum and then installing the F11 release yum made everything work again. 


Version-Release number of selected component (if applicable):
yum-3.2.23-3.fc10.noarch
yum-3.2.22-4.fc11.noarch

How reproducible:
Probably always


Steps to Reproduce:
1.Upgrade a F10 install to yum-3.2.23-3.fc10.noarch
2.Do a DVD based upgrade
3.Reboot into F11 and try to run yum
  
Actual results:
Yum fails with a python error.  The F10 yum is still installed.

Expected results:
F11 yum is installed and yum works on the newly upgraded F11

Additional info:
I'm adding this initially as a yum bug, but it may be that this is the sort of situation which anaconda is supposed to handle?
Comment 1 Simon Andrews 2009-06-18 06:25:17 EDT
Created attachment 348409 [details]
Upgrade log from the affected machine

You'll notice that although various yum components are upgraded, yum itself is not on the upgrade list.
Comment 2 James Antill 2009-06-18 17:55:37 EDT
 You need the latest update from Fed-11, I thought anaconda wouldn't break this ... gah.
 Basically:

1. su -
2. export PYTHONPATH=/usr/lib/python2.5/site-packages
3. yum update yum -y
4. exit

...this should get you to 3.2.23-3.fc11, which will work fine.
 Not sure what to do about this, apart from get everyone to use F11 updates too.
Comment 3 Simon Andrews 2009-06-18 18:28:59 EDT
Should this get reassigned as an anaconda bug?  I thought one of the main reasons for using anaconda to upgrade was that it could bypass the normal dependency checking mechanism to ensure a working (albeit only partially upgraded) system which didn't depend on the packages originally installed.
Comment 4 James Antill 2009-06-21 02:03:13 EDT
*** Bug 507057 has been marked as a duplicate of this bug. ***
Comment 5 James Antill 2009-06-21 02:03:30 EDT
*** Bug 507040 has been marked as a duplicate of this bug. ***
Comment 6 James Antill 2009-06-21 02:06:47 EDT
 I just did an update using netinst.iso, which auto enables the updates repo. ... and so worked fine.

 I'm still not sure what we can do about this BZ now though, even if we released an updated python in Fedora-11 that specially looks for yum in the old place ... anyone using just the DVD to update won't get it. About the only thing would be to remove the update from F10 ... which is probably useless now, as everyone probably already has it.
Comment 7 Simon Andrews 2009-06-21 05:37:39 EDT
I suppose that the best we can do now is to add a note about this to the online release notes, add it to the frequently seen bugs list and maybe pass this on to the Anaconda team so that they can look to see what they can do to ensure this doesn't happen again in the future.
Comment 8 John Guthrie 2009-06-21 14:30:49 EDT
Would it be worthwhile to make certain that one of the updated fedora unity releases contains an updated version of yum for F11?
Comment 9 James Antill 2009-06-22 02:19:05 EDT
I think I have an ugly fix (tested it by installing it on a f10 box and on a f11 box, and it works in both):

http://koji.fedoraproject.org/koji/taskinfo?taskID=1428732

...even so it'd be great to get a Unity release out with the f11 3.2.23 yum installed as default.

 If someone could test an update that'd be great, assuming Seth doesn't have any objections one of us will probably ask for it to go into F10-updates asap.
Comment 10 seth vidal 2009-06-22 08:35:01 EDT
1. fedora unity releases are not official releases
2. Backporting a new pkg to f10 is not going to solve this problem - it only complicates what we have to follow - the only way to solve this problem is through magic.
3. We've documented and explained that if yum is not able to be run when you upgrade to F11 from F10 that you can run:

export PYTHONPATH=/usr/lib/python2.5/site-packages
then
yum clean all
yum update yum

and you'll be all set.

We do not need to be chasing packages back into F10 for this, Especially not packages which add a python2.6 path.

It's just extra steps to support and just a hack.

Document the issue and work around it.

It's also worth noting - that sense preupgrade looks in the updates repo, too, that when the new f11 yum pkg that is in updates hits all the mirrors that preupgrade users will get the new pkg and anaconda will be able to do the right thing.

James: I do not think we should backport the pkg you made. It just creates new problems for us.
Comment 11 Simon Andrews 2009-06-22 08:55:27 EDT
I think I'm missing something in all of this.

This problem arose because the yum in F10 updates was 'newer' than the yum on the F11 DVD release.  Anaconda saw this and didn't update the F10 yum to the F11 version.

If this is the case then did anaconda ignore whichever python dependency caused the subsequent yum failure?  If so then surely we can't have this both ways, either Anaconda is given carte blanche to ignore dependencies and version checks to install a core set of known working packages, or it has to obey dependencies so it doesn't do half an upgrade and leave stuff broken.

I've always had good luck doing DVD/nfs updates on Fedora releases, but then I've always done them very early after the release.  Gradually breaking the upgrade path from older releases over time seems like a very bad idea.  Some of us have awkward network setups which make it easier to do an initial upgrade from fixed media, and this sort of problem could be a real pain.

There seems to be a reluctance to let anaconda downgrade packages during an install, but I don't see why.  The point of the release package set is that they are a tested, internally consistent set of packages which are assumed to work and serve as a base to expand from.  In this case I'd prefer anaconda to forcibly install the known working packages from the install media regardless of what updates I may or may not have applied in my existing install. This doesn't need to affect subsequent yum invocations, but anaconda is a very specific exception which deserves to be treated differently.
Comment 12 seth vidal 2009-06-22 09:27:34 EDT
All that happened was that anaconda left a package in a dependency-broken state b/c it was able to ignore the python dep it left over.

the solution to the problem is what I mentioned above in 3.

export PYTHONPATH=/usr/lib/python2.5/site-packages
yum clean all
yum update yum

if your mirrors are not up to current you could also do

yum --enablerepo=updates-testing update yum yum-utils


The point is - it is a temporary issue, and not one we need to instrument a bunch of packaging hacks to work around.
Comment 13 Simon Andrews 2009-06-22 09:35:10 EDT
Would it make sense to add as a feature to anaconda that it can't leave critical path packages (http://fedoraproject.org/wiki/Critical_Path_Packages_Proposal) in a broken state after an upgrade?  Maybe even to force the installation of those packages from the media regardless of the state of the original system?

You could argue that this is a temporary issue, but it's one which will be hitting people upgrading for the next 18 months and one for which there isn't a GUI based fix.

I agree that it's not worth doing anything more for this release (other than making sure this is well documented), but it seems prudent to try to learn from this for future releases.
Comment 14 seth vidal 2009-06-22 09:42:16 EDT
well:
1. critical path packages are not defined, yet - I should know - I'm leading that effort
2. anaconda won't need to do anything here - critical path packages will have pre-inclusion rules which will test long before they ever reach a release.
Comment 15 seth vidal 2009-06-22 10:29:29 EDT
So to close this bug:
if you get to a bug that is closed as a duplicate of this you should run the following as root:

export PYTHONPATH=/usr/lib/python2.5/site-packages/
yum clean all
yum update yum yum-utils

and that should do it.
Comment 16 seth vidal 2009-06-22 11:34:50 EDT
*** Bug 507116 has been marked as a duplicate of this bug. ***
Comment 17 James Antill 2009-07-07 11:41:23 EDT
*** Bug 509624 has been marked as a duplicate of this bug. ***
Comment 18 D. Wagner 2009-07-07 12:55:00 EDT
I do not think this bug should have been closed.  As far as I can tell, this is not fixed.  "CLOSED WORKSFORME" is inappropriate if it is correct that it has not been fixed.

People asked what Fedora could do about it.  Well, here are a few things Fedora could do:
1) Immediately ship an update to F10's updates repository that provides a newer yum or a newer python package that will work correctly after a DVD-upgrade to F11.
2) Document this on the F11 Common Bugs page, along with the fix.
3) Re-spin a new version of the F11 install disk with a workaround for this problem and replace the .iso on the F11 download page with the new version.
4) Decide on some process to ensure it doesn't happen again in the future for future releases.

See bug #509624 for more discussion.

Perhaps the most important thing is to declare that the current situation is broken.  It seems to me each developer of each component is saying "my component did exactly what it's supposed to!", and that may be, but the final experience for the user is not acceptable.

Seth Vidal says this has been documented.  Can you give a pointer to where it was documented?  I spent a bunch of time looking on the Fedora web pages when I ran into the problem, and I couldn't find the documentation, so I wonder if it could be more prominently documented.  Can I suggest an entry on:
http://fedoraproject.org/wiki/Common_F11_bugs

Can I suggest re-opening this, please?  I can't re-open it because I wasn't the reporter; I reported bug #509624 which got marked as a duplicate of this and got closed as a result; but I think this should be re-opened.
Comment 19 seth vidal 2009-07-07 13:00:49 EDT
1. it WAS documented on http://fedoraproject.org/wiki/Common_F11_bugs - at some point in time but it has, apparently, vanished.

2. the installed yum still works it just needs you to specify a path:
 - see comment #15

it's staying closed. other processes are in place to make this situation a bit harder to get into.
Comment 20 seth vidal 2009-07-07 13:11:44 EDT
Here you go, it's now re-documented:

https://fedoraproject.org/wiki/Common_F11_bugs#506685
Comment 21 D. Wagner 2009-07-07 15:39:00 EDT
Thanks!

Note You need to log in before you can comment on or make changes to this bug.