Description of problem: If you move from F7 -> F8 "fast enough" and then use yum, yum hasn't expired the metadata and so you get errors due to trying to update to F7 packages. Version-Release number of selected component (if applicable): yum(0:3.2.7-1.fc8) ...this might be worth just hacking a "yum clean all" fix into anaconda etc. for F9.
you mean if you move from f7->f8 by anaconda? If so - why file it against yum?
Yeah, probably worth doing. Sticking on the F9 blocker list so we don't forget about it.
Yeh, I did it via. anaconda but I thought that Live CD etc. had plans to do upgrades eventually. But, yeh, I should probably have just filed against anaconda.
Jeremy, are we going to do something like this post-feature freeze?
I thought we did it already -- is it still a problem?
Probably just needs retesting. Putting MODIFIED
It is still a problem....~/md5sum.fedora was created prior to the upgrade. [root@dhcp-137 fedora]# md5sum * d41d8cd98f00b204e9800998ecf8427e cachecookie 76f92af7e30d653a9fa043efa0d5bcd0 filelists.sqlite 5010e7caa981dfe76bdfcd75441599c6 mirrorlist.txt md5sum: packages: Is a directory e6b89f4c535a7a6bc1fd38899e112104 primary.sqlite b97031bc1c23129c2ff771d9094f39cc repomd.xml [root@dhcp-137 fedora]# cat ~/md5sum.fedora d41d8cd98f00b204e9800998ecf8427e cachecookie 76f92af7e30d653a9fa043efa0d5bcd0 filelists.sqlite 5010e7caa981dfe76bdfcd75441599c6 mirrorlist.txt e6b89f4c535a7a6bc1fd38899e112104 primary.sqlite b97031bc1c23129c2ff771d9094f39cc repomd.xml [root@dhcp-137 fedora]# Since this has really been this way forever, it is worth it being a blocker or not?
Fixed
So how do you test this? something like: - Install F8, - let yum-updatesd fetch metadata (but do not install), - immediately upgrade to F9 from a fast mirror. If the bug is present, you'll get errors from a 'yum upgrade' in F9 trying to pull down the F8 packages. Right?
Yeah, that is what I did - you can even install updates if you like (I think that I installed all of them). And I did the much lower tech solution of md5sum in /var/cache/yum before and after.
Tested a couple of different times - no complaints from yum. James, do you want to retest and confirm the fix or should we just consider it closed?
Interesting. This really wasn't fixed til today: commit b3d1e45042843693b2181714296756ce5c2ba7ae Author: Jeremy Katz <katzj> Date: Fri Apr 18 16:06:16 2008 -0400 Listing the directories before expiring yum caches helps Again, this wasn't looking at complaints from yum - this was a simple "is the metadata still there and usable by yum". BTW, if you go the md5sum route tomorrow, note that the data will still be there but the cachecookie will not be.
As long as someone has tested it I'm fine with closing it (I believe y'all :). Note though that the best test is just to make sure all the MD files are gone from /var/cache/yum/* (or at least all the repomd.xml files, but you might as well not leave unused MD files due to the unique names thing) if just the cachecookie is gone then yum can keep the cache. Anyway I'll stop rambling now ... Im' probably just spamming Jeremey's inbox :).
I must have just been testing it wrong. Can someone who has actually seen this bug in action confirm the fix?
Hmm, the code as it exists now removes cachecookie, and I just did a spin with the new anaconda and verified that indeed the cachecookie files are gone now. Are you saying that's not sufficient, James? BTW - the version wasn't bumped to 11.4.0.75 inside anaconda, still says 74.
Yeh, in comment #0 I suggest just doing a "yum clean all". Not sure where the cachecookie fix came from ... maybe because this is a suggested low BW way to make sure you have the latest MD? Just removing cachecookie will _mostly_ work however if yum fails to download new MD (fails to connect to network, mirror broken, etc.), yum will be clever and revert to the old MD. In pretty much all cases this is better, a big exception being if you've updated fedora-release and the old MD is from the previous release.
Oh, the other thing is that if you just remove the cachecookies then running yum as a non-root user (or as root with -C) will still use the old data ... so "yum list updates" as non-root will look like there's a major problem.
Changed to 'yum clean all'. I was trying to go for keeping things simpler
Fix should be testable in tomorrow's rawhide (20080429).
Created attachment 304347 [details] screenshot of PK wanting to install an f8 xterm update Still seems to be happening with today's rawhide (20080501). Note that the updates-testing repo was enabled before I upgraded.
updates-testing could well be in an odd state right now. What's in /var/log/anaconda.log? Also (although it's probably too late now) what was left in /var/cache/yum?
Looking at anaconda in git, we still have: # expire yum caches on upgrade if anaconda.id.getUpgrade() and os.path.exists("%s/var/cache/yum" %(anaconda.rootPath,)): log.info("Expiring yum caches") for d in os.listdir("%s/var/cache/yum" %(anaconda.rootPath,)): try: os.unlink("%s/var/cache/yum/%s/cachecookie" %(anaconda.rootPath, d)) except: pass I thought you changed that awhile back? You did it for preupgrade, just not the normal upgrade case.
*sigh* And that of course is the one that I tried out. Fixed. Again.
I'm retesting with preupgrade, without updates-testing enabled, and still hitting this. I think. Retesting again with both upgrade paths, and also to be double-sure that I'm using the right anaconda.
Yes, still broken. Both normal upgrades and preupgrades have mirrorlist.txt for 'fedora' and 'updates', and they're full of F8 urls. This is anaconda-11.4.0.81. if anaconda.id.getUpgrade() and os.path.exists("%s/var/cache/yum" %(anaconda.rootPath,)): log.info("Expiring yum caches") try: iutil.execWithRedirect("yum", ["clean", "all"], stdout="/dev/tty5", stderr="/dev/tty5", searchPath = 1) Maybe you need to chroot there to make 'yum clean all' DTRT? Because running 'yum clean all' after the reboot definitely does the right thing.
Clearly I should not be allowed to touch this bug anymore, but yeah, a root= would help. Committed. If you really want it for f9 Will, give me a holler. It is pushed to the branch, so if we do another build for something else, we'll pick it up. But I don't see making us go through testing again for it.
These changes got pulled into anaconda-11.4.0.82. Tested a couple of upgrades and it seems to be doing the right thing.