Bug 1927988
Summary: | [conn] Server does not return metadata | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | laolux | ||||||
Component: | dnf | Assignee: | amatej | ||||||
Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | unspecified | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | 33 | CC: | amatej, dmach, jmracek, jrohel, mblaha, mhatina, packaging-team-maint, pkratoch, robinlee.sysu, rpm-software-management, tetsuji.rai, vasintalana, vikigoyal, vmukhame | ||||||
Target Milestone: | --- | Keywords: | Triaged | ||||||
Target Release: | --- | ||||||||
Hardware: | x86_64 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2021-06-18 20:16:09 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
laolux
2021-02-12 02:12:14 UTC
Created attachment 1756499 [details]
dnf.librepo.log
New try, February 27, 2021, 12:45 UTC. Same mirror, same error. Maybe that mirror is broken? Is there a process to contact mirror owners to make them aware of such issues? [root@localhost ~]# dnf --enablerepo=updates-testing update --refresh Fedora 33 openh264 (From Cisco) - x86_64 218 B/s | 543 B 00:02 Fedora Modular 33 - x86_64 10 kB/s | 6.6 kB 00:00 Fedora Modular 33 - x86_64 - Updates 13 kB/s | 4.9 kB 00:00 Fedora 33 - x86_64 - Test Updates 24 kB/s | 8.6 kB 00:00 Fedora 33 - x86_64 - Test Updates 151 kB/s | 510 kB 00:03 Errors during downloading metadata for repository 'updates-testing': - Zchunk error: Unable to find multipart download range - Curl error (52): Server returned nothing (no headers, no data) for http://mirror.sjtu.edu.cn/fedora/linux/updates/testing/33/Everything/x86_64/repodata/f41442ea50bd49897624bfb9be6b1e557192b9748c25bb18a34effe2878c89c2-filelists.xml.zck [Empty reply from server] - Curl error (52): Server returned nothing (no headers, no data) for http://mirror.sjtu.edu.cn/fedora/linux/updates/testing/33/Everything/x86_64/repodata/df256c076486acde5c4f0fe5242640a45fa94dc6f0efab5a44431c79bfef6e97-primary.xml.zck [Empty reply from server] Error: Failed to download metadata for repo 'updates-testing': Yum repo downloading error: Downloading error: Unable to initialize zchunk file repodata/f41442ea50bd49897624bfb9be6b1e557192b9748c25bb18a34effe2878c89c2-filelists.xml.zck: Unable to set zchunk file descriptor for repodata/f41442ea50bd49897624bfb9be6b1e557192b9748c25bb18a34effe2878c89c2-filelists.xml.zck: Unable to find multipart download range *** Bug 1933264 has been marked as a duplicate of this bug. *** Ok I think there are two parts to this: 1. The specific mirror http://mirror.sjtu.edu.cn/fedora is somehow faulty and its not possible to download zchunk chunks (the metadata deltas) from it. It is possible to download full files though so `dnf clean metadata` should workaround this, it will clean the metadata cache and the full file will be downloaded. I think it was also already reported to the mirror: https://github.com/sjtug/mirror-requests/issues/167 but looks like not really fixed. I have filed another issue on zchunk (https://github.com/zchunk/zchunk/issues/40) to see if they can figure out what is the specific problem and then we can report it to the mirror again. 2. When the first attempt to download from http://mirror.sjtu.edu.cn/fedora fails dnf should try the next mirror and in fact it does. In the provided dnf.librepo.log it says it then tried to download http://dl.fedoraproject.org/pub/fedora/linux/updates/testing/33/Everything/x86_64/repodata/7f298b9e7ec89614fbd4f8619fd6ace0dcc69045a67754c0d3b8868474731b04-filelists.xml.zck but this also failed. I think I managed to partially reproduce this and I believe the second failed download happened because the mirrors were out of sync. This trips up dnf because it gets the file names from the first mirror which has old metadata, it fails to donwload them (because of the zchunk issue) and then it goes to the next mirror but they are not there anymore (it already has newer metedata) so it also fails to download those. I was checking these two mirrors the last couple of days and there seem to be several hours long periods when they are out of sync. I think this could easily be the issue if mirrorlist is used, but from the log we can see this happened with metalink and metalink should prevent this so I am not sure what is going on. When this happens again to someone could they check the mirrors from the metalink https://mirrors.fedoraproject.org/metalink?repo=updates-testing-f33&arch=x86_64 and http://mirror.sjtu.edu.cn/fedora/linux/updates/testing/33/Everything/x86_64/repodata to see if they have the same files [links for fedora 33]? If there will be different files that would fully explain this. *** Bug 1940721 has been marked as a duplicate of this bug. *** *** Bug 1957854 has been marked as a duplicate of this bug. *** According to https://github.com/zchunk/zchunk/issues/40 this has been resolved. *** Bug 1911488 has been marked as a duplicate of this bug. *** |