|Summary:||install error: unable to read package metadata|
|Product:||[Fedora] Fedora||Reporter:||Gianluca Cecchi <gianluca.cecchi>|
|Component:||anaconda||Assignee:||Anaconda Maintenance Team <anaconda-maint-list>|
|Status:||CLOSED NOTABUG||QA Contact:||Mike McLean <mikem>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-03-08 19:04:25 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Gianluca Cecchi 2006-03-08 17:44:24 UTC
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:126.96.36.199) Gecko/20060111 Firefox/188.8.131.52 Description of problem: I'm trying to install via pxe+nfs from rsync of today on x86 and I get this error window during anaconda: unable to read package metadata. this may be due to a missing repodata. Please ensure that your install tree has been correctly generated. failure: repodata/comps.xml from anaconda: [errno 256] no more mirrors to try switching to the shell with Ctrl+Alt+F2, I see inside anaconda.log in /tmp I have [snip] 10:42:24 INFO : NFS install method detected, will use RHupdates/ 10:42:24 INFO : Running anaconda script /usr/bin/anaconda 10:42:27 INFO : Display mode = g 10:42:27 INFO : Method = nfs://mnt/source/. 10:42:44 INFO : Started mini-wm 10:42:44 INFO : Starting graphical installation... 10:42:45 INFO : anaconda floppy device None 10:42:45 DEBUG : self.driveList(): ['sda', 'sdb'] 10:42:45 DEBUG : DiskSet.skippedDisks:  10:42:45 DEBUG : DiskSet.skippedDisks:  10:42:45 DEBUG : starting all dmraids on drives ['sda', 'sdb'] 10:42:45 DEBUG : scanning for dmraid on drives ['sda', 'sdb'] 10:42:45 WARNING : Couldnt lookup monitor type Smart Cable. 10:42:45 WARNING : step partitionmethod does not exist 10:42:45 WARNING : step partitionmethodsetup does not exist 10:42:45 WARNING : step autopartition does not exist 10:42:45 WARNING : step readcomps does not exist 10:42:45 WARNING : step selectlangpackages does not exist 10:42:45 WARNING : step handleX11pkgs does not exist 10:42:45 WARNING : step handlemiscpkgs does not exist 10:42:45 WARNING : step fixupconditionals does not exist 10:42:45 WARNING : step complete does not exist 10:42:45 WARNING : step complete does not exist 10:42:45 WARNING : step complete does not exist 10:42:45 WARNING : step complete does not exist 10:42:45 WARNING : step complete does not exist 10:42:45 WARNING : step complete does not exist 10:42:45 WARNING : step complete does not exist 10:42:45 WARNING : step complete does not exist 10:42:45 WARNING : step complete does not exist 10:42:46 INFO : moving (1) to step partitionobjinit 10:42:46 DEBUG : self.driveList(): ['sda', 'sdb'] 10:42:46 DEBUG : DiskSet.skippedDisks:  10:42:46 DEBUG : DiskSet.skippedDisks:  10:42:46 INFO : moving (1) to step autopartitionexecute 10:42:46 INFO : moving (1) to step partitiondone 10:42:46 INFO : moving (1) to step bootloadersetup 10:42:46 INFO : moving (1) to step networkdevicecheck 10:42:46 INFO : moving (1) to step reposetup 10:42:47 INFO : anaconda [1/1] 10:42:47 ERROR : reading package metadata: failure: repodata/comps.xml from anaconda: [Errno 256] No more mirrors to try. df -k gives: Filesystem 1K-blocks Used Available Use% Mounted on /dev 1948452 0 1948452 0% /dev 192.168.0.110:/fc5nfs 14200000 9822368 3644672 73% /mnt/source /tmp/loop0 70720 70720 0 100% /mnt/runtime and I can edit /mnt/source/repodata/comps.xml .... Is this a problem on my part about rsync or what? Same process is ok if using as nfs repository the dvd iso for test3, dumped to the directory. I skip debug and SRPMS directory under tree for rsync but I think this doesn't matter... How can I dig into this? Version-Release number of selected component (if applicable): anaconda-11.0.1-1 How reproducible: Always Steps to Reproduce: 1.setup pxe+dhcp+tftp server1 2.setup ks file on http server2 3. install server3 via pxe Actual Results: installation stops with the window message above and I can only exit the installation Expected Results: installation progress Additional info:
Comment 1 Jeremy Katz 2006-03-08 18:11:54 UTC
Is your repodata properly synced? Does the sha1sum of the comps file there match that in repomd.xml
Comment 2 Gianluca Cecchi 2006-03-08 18:47:29 UTC
no, [gcecchi@pevit00 fc5nfs]$ sha1sum repodata/comps.xml a2f21fa1128ee7381d838216c310f371ac90caf6 repodata/comps.xml inside repomd.xml instead I have: <data type="group"> <location href="repodata/comps.xml"/> <checksum type="sha">424026225e0cea73daefa7fb7fe5623093b82b10</checksum> <timestamp>1139337044</timestamp> while on dvd for test3 [gcecchi@pevit00 repodata]$ sha1sum comps.xml dce353c5157588b329aa4e6b8975b9ee9b54ed34 comps.xml and in repomd.xml: <location xml:base="media://1140120001.114809#1" href="repodata/comps.xml"/> <checksum type="sha">dce353c5157588b329aa4e6b8975b9ee9b54ed34</checksum> <timestamp>1140050497</timestamp> so it seems also time stamp take role.... how to sync time stamps..? I used --size-only option in rsync command: rsync -av --delete --size-only --exclude "debug/*" rsync://mirrors.kernel.org/fedora/core/development/i386/ . contents in rsynced dir are: [gcecchi@pevit00 fc5nfs]$ ll repodata/ total 14356 -rw-r--r-- 1 gcecchi gcecchi 700983 Mar 8 08:27 comps.xml -rw-r--r-- 1 gcecchi gcecchi 3623816 Mar 8 08:27 filelists.xml.gz -rw-r--r-- 1 gcecchi gcecchi 28302 Mar 8 08:28 index.html -rw-r--r-- 1 gcecchi gcecchi 8830850 Mar 8 08:27 other.xml.gz -rw-r--r-- 1 gcecchi gcecchi 1266094 Mar 8 08:27 primary.xml.gz -rw-r--r-- 1 gcecchi root 1140 Mar 8 08:27 repomd.xml drwxr-xr-x 3 gcecchi root 204800 Mar 8 08:28 repoview how can i see what means 1140050497 timestamp?
Comment 3 Warren Togami 2006-03-08 19:04:25 UTC
Please don't take this too harshly, but you are using our limited time with a simple rsync usage problem. For this reason I am closing NOTABUG. However in my past experience running a Linux mirror, I believe I might be able to help you. Sometimes rsync even with seemingly proper options fails to have an exact copy on the local side. In those cases (like a corrupted package) I would have to erase the local copy and run rsync again. So try deleting that stuff locally and rsync again, is it better? I have no real explanation for why rsync sometimes fails in this way. Maybe one spot on a disk was going bad, and deleting the file and syncing again put the file on a different physical spot on the disk so it worked around that problem. I don't know...
Comment 4 Gianluca Cecchi 2006-03-09 07:51:41 UTC
No problem with closing the issue. Sorry for your time stolen in this. Release team requested to try devel kernels and installation kits, so I presumed that also original mirror repodata dir download was involved in testing. Running "createrepo -g repodata/comps.xml ." from nfs tree root, I can recreate the repodata directory and install successfully from pxe+nfs, with updates at rawhide report: 20060308 changes. Probably you had better define two kinds of rsync mirrors: - one for continuous updates - one refreshed once a day with the directory tree suited for daily installation only and during its own updates (its rsync client activity) its rsync server services are stopped, so that if I try to rsync from my PC with this repository, the tree is always consistent or I get an error because service is not available. today, if I delete and re-sync the repodata dir, it seems I get consistent results, thanks for the hint.