Red Hat Bugzilla – Bug 645860
preupgrade error F13->F14 - Unable to read package metadata
Last modified: 2012-08-16 15:56:16 EDT
Description of problem:
On a F13 system, after successfully running preupgrade, and booting into the upgrade, I get an error "Unable to read package metadata".
Farther down, it says:
Cannot retrieve repository metadata (repomd.xml) for repository: anaconda-InstallationRepo-201010211522.x86_64. Please verify it's path and try again.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
The files are all here:
Note: the root filesystem containing the preupgrade repositories has a couple of layers, in particular:
Two lvm devices:
LV Name /dev/fastvg/slash_mirror_1
LV Name /dev/fastvg/slash_mirror_2
Are mirrored together into an md array:
md1 : active raid1 dm-9 dm-10
46706624 blocks [2/2] [UU]
As I recall, this configuration worked just fine preupgrading from F12 to F13.
I'm seeing the same problem. I've got a fairly basic system with two VG groups, one for the root/swap partitions and one for /srv.
Created attachment 456277 [details]
1st error message
Created attachment 456278 [details]
2nd error message
I've added a couple of screenshots of the error messages that I get. The 2nd error message is what you get when you click "continue" in the 1st diaglog box.
Another data point: Regular upgrade with the Fedora 14 RC DVD does not have this problem.
These are anaconda messages, no?
(In reply to comment #8)
> These are anaconda messages, no?
Yes, but is the bug in Anaconda that can't read a valid repository or is the bug with preupgrade that is creating an invalid repository?
I have a question. Does preupgrade use the existing repositories defined in /etc/yum.repos.d, or does it download new mirror/repo information from the internet somewhere?
To rephrase: If I have customized my /etc/yum.repos.d directory, will it affect the preupgrade process?
I had the same problem with an i386 system, get the same error messages.
I have the same problem upgrading a 64 bit installation of F13. I installed and ran preupgrade. But there are no repomd files in /mnt/sysimage/var/cache/preupgrade. Instead, there's a mirros.txt and an empty packages/ directory.
Is there supposed to be a difference between running preupgrade as a regular user and typing the root password, vs. doing su and running preupgrade? After rebooting, I ran su, then preupgrade, and it downloaded a bunch more stuff... Now there is most definitely a repomd.xml file. I'm also trying to determine if it somehow got confused: I have a backup file system with an old installation of fedora and it might be trying to upgrade that when I reboot?
(Sorry for the duplicate comment...)
I figured out that when I reboot, anaconda is stubbornly insisting on trying to upgrade my backup disk which has an old installation of Fedora on it, and of course, there's nothing useful in /var/cache/yum there.
I got the upgrade to work by changing /boot/upgrade/ks.cfg. I had to google for the documentation for this file,
and after a lot of trial and error, I came up with changing some lines in this file to:
where my useful fedora installation has its root at /dev/mapper/Grograman00-root, and the device for that particular whole hard disk is /dev/sdh. With that fix, the upgrade seems to be working now, fingers crossed.
I tried upgrade --root-device=LABEL=ROOT, because my root file system has the label "ROOT" and I boot with the option root=LABEL=BOOT, and that didn't work. It still tried to install to my backup disk. I also tried ignoredisk --drives=/dev/sdg which I think should have told anaconda to ignore my backup disk sdg, and that didn't work either.
Anyway, the problem seems to be that something goes wrong when anaconda tries to figure out which of multiple installations to upgrade, and it's not clear to me exactly how to specify it in the kickstart file /boot/upgrade/ks.cfg.
I got around this particular problem by removing the --root-device= option to kickstart upgrade command in /boot/upgard/ks.cfg. I.E. by changing
preupgrade had correctly set the UUID for the root filesystem containing the /var/cache/yum/ repositories, but it appears that anaconda found it easier to locate these repositories when it was left to guess where they were rather than being given the UUID as a hint. Therefore, this would appear to be a bug in the way that anaconda handles of the --root-device=UUID= option to the upgrade command in the kickstart file.
BTW - the root filesystem in question was a LV in a VG on a RAID 10 PV.
This message is a notice that Fedora 14 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 14. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.
(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 14 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here: