Red Hat Bugzilla – Bug 505206
Anaconda find comp-f10.xml in wrong directory when network upgrading from f10 to f11
Last modified: 2009-06-11 10:11:45 EDT
Description of problem:
I was trying to upgrade a Fedora 10 box to Fedora 11 using the network install CD. It booted and I inserted "upgrade" in the boot menu option. Then the graphical interface hang with a mouse arrow in the center of the screen. No HD activity, cannot do ctrl-Fn to switch to text info screens, even num-lock on the keyboard and mouse got no response.
The I forced power off and reboot, choose "text upgrade" option. It booted and loaded anaconda, asked me the IP, then infinitely retrying downloading file. I did "Ctrl F3" and figured that it was trying to download 8ffd57eb57a828ed38bbcf103ef17d548c2d36ea-comps-f10.xml from directory
However, obviously the file is in pub/fedora.redhat/linux/updates/11/i386/repodata. Thus anaconda exhausted all servers and cannot find the file and stuck.
I then did "Ctrl-F2" into the sh shell and used ftp to obtain the file, and put it into /mnt/sysimage/var/cache/yum/updates, and reboot.
Wow! The upgrade process started properly like a charm!
Version-Release number of selected component (if applicable):
Steps to Reproduce:
After hand copying the comps-f10.xml file, I got what I want. The system is upgraded properly.
Upgrade Fedora10 to 11 without hand copying that file.
This looks like a typo in the anaconda network installation script for upgrading from 10 to 11. An one letter fix should be sufficient to close this bug. I do not know where. I open this to help the guru to pin down the easy fix.
Oh, I see what's going on here. You've got old repodata in /var/cache/yum/updates from doing an F10 install and then running "yum update" from time to time. However now that all the repodata files have changed names, yum is confused when trying to enable that repo while running under anaconda.
Unfortunately, I don't believe there's anything we can do for you here except offer an explanation. We can't just purge the cache of old repodata on updates since that would break preupgrade. So there's no generic way to handle things here, and there's unlikely to be a way to just clean out the cache of a single troublesome repo. I think the best we can do is document a workaround here - you should run "yum clean metadata" before preforming an upgrade, but only in this one specific case.