Created attachment 1756498 [details] Error messages shown by dnf Created attachment 1756498 [details] Error messages shown by dnf Description of problem: I tried to run `dnf update --enablerepo=updates-testing` and the automatically chosen mirror does not return metadata, causing dnf to quit instead of trying the next mirror. Running dnf again makes dnf try the very same mirror again. Had to wait for the server to start working normally before I could get updates. Version-Release number of selected component (if applicable): librepo-1.12.1-1.fc33.x86_64 curl-7.71.1-8.fc33.x86_64 dnf-4.5.2-1.fc33.noarch How reproducible: Difficult. Needs outside problems to reproduce the issue. Specifically, dnf needs to automatically select a mirror which currently does not return anything instead of metadata or an error. Steps to Reproduce: 1. 2. 3. Actual results: dnf fails to get updates with Errors during downloading metadata for repository 'updates-testing': - 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/66ec03ae66a8bfbcc1969a9d8764a52431fb9bc6753fdc6bc68ca64daacb1511-primary.xml.zck [Empty reply from server] - Zchunk error: Unable to find multipart download range Expected results: dnf notices that nothing is returned and tries next server. Additional info: Full output of 3 consecutive dnf runs and /var/log/dnf.librepo.log attached
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. ***