Created attachment 1580398 [details] Excerpt of /var/log/dnf.librepo.log for problematic dnf call Description of problem: dnf upgrade produces error when using zchunk with rpmcache [https://github.com/UweMenges/rpmcache]. error: repodata/0ae4de5fae98011b4b635497808e2da2b9412de4fb5525180dd96fe958087289-updateinfo.xml.zck's zchunk header doesn't match (http://download.fedoraproject.org/pub/fedora/linux/updates/29/Modular/x86_64/repodata/0ae4de5fae98011b4b635497808e2da2b9412de4fb5525180dd96fe958087289-updateinfo.xml.zck). Steps to Reproduce: 1. Setup rpmcache and use it by setting proxy= in /etc/dnf/dnf.conf 2. Run dnf upgrade 3. Observe the error: Fedora Modular 29 - x86_64 4.0 MB/s | 4.2 kB 00:00 reviving: 'fedora-modular' can be revived - repomd matches. fedora-modular: using metadata from Thu Oct 25 00:22:05 2018. repo: downloading from remote: updates-modular error: repodata/0ae4de5fae98011b4b635497808e2da2b9412de4fb5525180dd96fe958087289-updateinfo.xml.zck's zchunk header doesn't match (http://download.fedoraproject.org/pub/fedora/linux/updates/29/Modular/x86_64/repodata/0ae4de5fae98011b4b635497808e2da2b9412de4fb5525180dd96fe958087289-updateinfo.xml.zck). Fedora Modular 29 - x86_64 - Updates 160 MB/s | 1.5 MB 00:00 Cannot download 'http://download.fedoraproject.org/pub/fedora/linux/updates/29/Modular/x86_64/': Yum repo downloading error: Downloading error(s): repodata/0ae4de5fae98011b4b635497808e2da2b9412de4fb5525180dd96fe958087289-updateinfo.xml.zck - Cannot download, all mirrors were already tried without success. Failed to synchronize cache for repo 'updates-modular' Error: Failed to synchronize cache for repo 'updates-modular' Actual results: Get download error. Expected results: Upgrade system. Additional info: Seems to be related to range requests. 2019-06-13T21:09:05Z DEBUG lr_zckheadercb: Too many ranges were attempted in one download 2019-06-13T21:09:05Z DEBUG check_transfer_statuses: Transfer finished: repodata/0ae4de5fae98011b4b635497808e2da2b9412de4fb5525180dd96fe958087289-updateinfo.xml.zck (Effective url: http://download.fedoraproject.org/pub/fedora/linux/updates/29/Modular/x86_64/repodata/0ae4de5fae98011b4b635497808e2da2b9412de4fb5525180dd96fe958087289-updateinfo.xml.zck) 2019-06-13T21:09:05Z DEBUG check_finished_transfer_status: Setting mirror's max_ranges to 0 2019-06-13T21:09:05Z DEBUG check_transfer_statuses: Error during transfer: repodata/0ae4de5fae98011b4b635497808e2da2b9412de4fb5525180dd96fe958087289-updateinfo.xml.zck's zchunk header doesn't match Log excerpt of /var/log/dnf.librepo.log for problematic dnf call attached. Yours, Uwe
Thanks for filing this under zchunk as I asked so it would get assigned directly to me. Since it's technically a librepo bug, I'm now changing the component. I've done a bit of poking around and it's definitely range related. I'll try and have a fix ready in the next few days.
Ok, I think I've got this fixed in https://github.com/rpm-software-management/librepo/pull/155. Could you please check the builds at https://koji.fedoraproject.org/koji/taskinfo?taskID=35546856 and verify that they fix the problem?
To clarify, the expected result is that you download the full zchunk metadata rather than just the changes, but everything should work as expected.
Created attachment 1580981 [details] log shows old (17:40) and new (17:44) behavior I installed your provided https://kojipkgs.fedoraproject.org//work/tasks/6859/35546859/librepo-1.10.2-3.fc29.x86_64.rpm and https://kojipkgs.fedoraproject.org//work/tasks/6859/35546859/python3-librepo-1.10.2-3.fc29.x86_64.rpm. It works for me now. I'm attaching an excerpt of /var/log/dnf.librepo.log with a "dnf upgrade" run before (17:40) and after (17:44) installing the updated rpms, so you can check if the result of your changes are as expected in the "no range support" case. Thanks!
(In reply to Uwe Menges from comment #4) > It works for me now. > > I'm attaching an excerpt of /var/log/dnf.librepo.log with a "dnf upgrade" > run before (17:40) and after (17:44) installing the updated rpms, so you can > check if the result of your changes are as expected in the "no range > support" case. > > Thanks! Excellent! That's exactly how I was hoping and expecting it would work.
We just need to wait for upstream librepo to merge the packages and then get a new build out in Fedora.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. 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 EOL if it remains open with a Fedora 'version' of '29'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
This has been fixed, but the bug was never closed