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?
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.
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.
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.
*** Bug 507057 has been marked as a duplicate of this bug. ***
*** Bug 507040 has been marked as a duplicate of this bug. ***
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.
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.
Would it be worthwhile to make certain that one of the updated fedora unity releases contains an updated version of yum for F11?
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.
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.
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.
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.
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.
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.
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.
*** Bug 507116 has been marked as a duplicate of this bug. ***
*** Bug 509624 has been marked as a duplicate of this bug. ***
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.
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.
Here you go, it's now re-documented: https://fedoraproject.org/wiki/Common_F11_bugs#506685
Thanks!