Red Hat Bugzilla – Bug 242546
Cannot open/read repomd.xml file for repository: anaconda-base-200705271038.i386
Last modified: 2008-06-16 21:24:44 EDT
Description of problem: When attempting a graphical F7 install, it said that due to low memory (I have 256 MB), it had to enable swap immediately, so it would have to write the partition table immediately. After agreeing, it did this, then failed with an Error message: "Unable to read package metadata. This may be due to a missing repodata directory. Please ensure that your install tree has been correctly generated. Cannot open/read repomd.xml file for repository: anaconda-base-200705271038.i386" Someone on fedora-list had a similar problem: http://www.redhat.com/archives/fedora-list/2007-June/msg00355.html Version-Release number of selected component (if applicable): anaconda-11.2.0.66-1.i386 How reproducible: not sure Steps to Reproduce: 1. attempt clean install from F7 DVD Additional info: Prior to this I had attempted the same type of install with a different HD in the same machine. In that case, the HD wasn't even detected. I subsequently did a successful install using the FC6 CD set which was able to detect said HD properly. I verified all media with mediacheck and by reading the ISO directly off the burned disc and checking its sha1sum before use.
What type of installation were you doing? Was it a network install? If so, what network repo were you pointing at?
It was a local clean install from the F7 DVD. I didn't choose any packages from external repos.
If there are any logfiles created up to the point of the error message that would be of use, I can duplicate the problem by swapping in the hard drive I was using when the problem happened (which has had its partition tables hosed anyway), and attempting the install again. Let me know.
Dont know if will help - but you could try upping swap to around 500-750M
I didn't check but since the box has 256M RAM it probably assigns 512M swap by default.
I'm not sure if this is related or not but one of my F7 UPGRADES failed part way though apparently due to lack of memory. Peter Jones came by my cube and determined that the available swap partitition had not been mounted and there was no swap space. Peter manually mounted the swap partition at the start of the install and it seem to procede although I didn't let it run to completition because I later decided a clean install was preferred to an upgrade on this box and killed it. It appears an upgrade does not properly handle the partitions in some manner, specifically it fails to find and mount swap. This seems to be an issue because upgrades seem to consume much more virtual memory than does an install.
========= similar message with freshrpms ==================== Can someone please explain this message yum under root complains that it Cannot open/read repodata/repomd.xml file for repository: freshrpms -rw-r--r-- 1 root root 2142 2007-06-07 12:43 repomd.xml On my 64 bit system, it works just fine.... Regarding Swap size, I have it set to double the amount of real memory. My system -- 1 gig memory, 2gig swap, Fc7 32 bit. Fc7 64 bit works just fine. ========== repro livna works fine ==================
I am investigating why yum --noplugins works. How to determine which plug-in is causing the problem with the 32 bit version? Need to know where the plug-ins are stored and the parameter file for same.
====== Determined the problem is possibly in the yum parser. (32 bit fc7). The following does not work # $Id: freshrpms.repo 3341 2005-06-28 18:40:26Z thias $ [freshrpms] name=Fedora Core $releasever - $basearch - Freshrpms #baseurl=http://ayo.freshrpms.net/fedora/linux/$releasever/$basearch/freshrpms/ mirrorlist=http://ayo.freshrpms.net/fedora/linux/$releasever/mirrors-freshrpms enabled=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-freshrpms gpgcheck=1 but eliminating the # at the baseurl1 resolved the problem. The same unchanged repo file works just fine in 64 bit mode.
Created attachment 156646 [details] freshrpms.repo The actual raw input from freshrpms.net
My father is currently doing a clean offline install from the F7 DVD on essentially the same machine as mine - same motherboard, different CPU and hard drive. His 20 GB drive was properly detected, he got the same low memory warning as me (both of our machines have 256 MB RAM), but in his case the installer completed this phase successfully. So the low memory message doesn't seem related to the bug.
(In reply to comment #7) > ========= similar message with freshrpms ==================== Please next time fill another bug, because the message is similar, but the situation is very different. It could be misconfigured repo on the freshrpms side.
Andre Robatino: Can you please provide details about hardware in the machine? (harddrives, ide/scsi/sata controller, chipset etc.).
With the exception of the HD, the hardware is the same as that associated with my attachments to bug #242766. The 8.6 GB HD that was installed when I had this bug is a Seagate ST38422A. After buying the 120 GB HD, I'm not anxious to put the smaller drive back. Let me know if this is enough info.
It is enough, but unfortunately it seems to be very closely related to your harddrive detection problems in the mentioned bug. I'll add a dependency on it and watch it some more, but there is very little I can do right now except to wait for kernel guys response.
Andre: I noticed you solved/workarounded the situation in the #242766. Was this bug solved also by correcting the jumper selection?
I experienced this bug while a different, smaller, HDD was installed in the machine (see "Additional info" above). The F7 installer never had any problem detecting that drive. Since I currently have a working F6 installation using the bigger HDD, and since F9 is coming out in about 2 months, I don't plan on attempting another install with the current drive until then - this is just a backup machine and it's unlikely I'll have to use it before then. So I won't know until then whether the bug exists using the current HDD.
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is 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 please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. 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. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. Fedora 7 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.