Bug 184426
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> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | wtogami |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-03-08 19:04:25 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Gianluca Cecchi
2006-03-08 17:44:24 UTC
Is your repodata properly synced? Does the sha1sum of the comps file there match that in repomd.xml 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? 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... 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. |