Bug 1720381

Summary: Download error, updateinfo.xml.zck's zchunk header doesn't match
Product: [Fedora] Fedora Reporter: Uwe Menges <uwe.menges>
Component: librepoAssignee: Jonathan Dieter <jdieter>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 29CC: dmach, jdieter, mblaha, pkratoch, rpm-software-management, tmlcoch
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: 2019-11-01 08:09:01 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 Flags
Excerpt of /var/log/dnf.librepo.log for problematic dnf call
none
log shows old (17:40) and new (17:44) behavior none

Description Uwe Menges 2019-06-13 21:16:29 UTC 
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
Comment 1 Jonathan Dieter 2019-06-13 21:20:26 UTC 
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.
Comment 2 Jonathan Dieter 2019-06-14 22:34:27 UTC 
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?
Comment 3 Jonathan Dieter 2019-06-14 22:36:06 UTC 
To clarify, the expected result is that you download the full zchunk metadata rather than just the changes, but everything should work as expected.
Comment 4 Uwe Menges 2019-06-15 18:01:00 UTC 
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!
Comment 5 Jonathan Dieter 2019-06-15 18:38:11 UTC 
(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.
Comment 6 Jonathan Dieter 2019-06-15 18:38:50 UTC 
We just need to wait for upstream librepo to merge the packages and then get a new build out in Fedora.
Comment 7 Ben Cotton 2019-10-31 19:02:23 UTC 
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.
Comment 8 Jonathan Dieter 2019-11-01 08:09:01 UTC 
This has been fixed, but the bug was never closed