---Read Additional info first---
Description of problem:
In an attempt to use zif to install the F15 kde 4.7.1 updates I modified '/etc/zif/zif.conf' and set 'metadata_expire=1800'. I then ran 'zif clean' to clear cached data.
When I ran a 'zif update' I was granted with the following error
Loading repository [ ] (0%)
Checking [ ] <1%> primary.sqlite.bz2
Failed to load: failed to resolve in fedora-kde47: failed to load md_primary_sql file: checksum incorrect, wanted 8af34d43b8315976f92e2769167d01786458d408, got 61314e5f07e9cd6f72bb0aa0e635b27f12623709 for /var/cache/zif/x86_64/15/fedora-kde47/primary.sqlite.bz2
Version-Release number of selected component (if applicable):
Using - http://repos.fedorapeople.org/repos/kkofler/zif-backport/
Sep 21 10:03:46 Updated: zif-0.2.4-0.93.20110920git.fc15.x86_64
Sep 21 10:03:47 Updated: zif-tools-0.2.4-0.93.20110920git.fc15.x86_64
Sep 21 10:04:19 Updated: PackageKit-yum-0.6.17-1.fc15.libzif.so.3.x86_64
Sep 21 10:04:24 Updated: PackageKit-0.6.17-1.fc15.libzif.so.3.x86_64
Sep 21 10:04:25 Updated: PackageKit-glib-0.6.17-1.fc15.libzif.so.3.x86_64
Sep 21 10:04:26 Updated: PackageKit-gstreamer-plugin-0.6.17-1.fc15.libzif.so.3.x86_64
Sep 21 10:04:27 Updated: PackageKit-qt-0.6.17-1.fc15.libzif.so.3.x86_64
Even after running 'zif clean' again and trying another update it still produced the same checksum incorrect message. I even moved the 'fedora-kde47/primary.sqlite.bz2' out of the way and the next 'zif update' also failed.
Steps to Reproduce:
Package updates could not be performed.
Updating the packages kde 4.7.1 packages as yum could at the same moment.
6 hours later I attempted to run a 'zif update' and it correctly listed all of the kde 4.7.1 package updates.
I then installed
Sep 22 08:33:31 Updated: zif-0.2.4-0.99.20110921git.fc15.x86_64
Sep 22 08:33:31 Updated: zif-tools-0.2.4-0.99.20110921git.fc15.x86_64
and proceeded to upgrade to kde 4.7.1 without issue!
No further problems after update.
Not sure how helpful this is :p
If it happens again, can you please re-open this report and provide the "zif --verbose update foo" debug spew please. Thanks.
This is proving to be a difficult bug to catch.
I have had this bug re-appear twice more on two different systems.
Unfortunately both times when I re-ran zif with the verbose switch the transaction completed successfully without issue...
You can re-close this btw. If I manage to get lucky with the verbose switch on the first run on my next set of updates plus have this error show up and get a proper output I'll bother you then.
Here is the latest capture from a normal 'zif update'.
Downloading [= ] (2%) 33a1c1...60c00b-prestodelta.xml.gz [2Downloading [= ] (2%) repomd.xml [29.0 MB/sec] Downloading [= ] (2%) i386
Failed to load: failed to resolve in updates: failed to load md_primary_sql file: failed to download missing compressed file: failed to download �<
from any sources (and after retrying)
(In reply to comment #2)
> I have had this bug re-appear twice more on two different systems.
Are you behind a captive portal on those systems?
> Unfortunately both times when I re-ran zif with the verbose switch the
> transaction completed successfully without issue...
Hmm, i need the log :(
> Here is the latest capture from a normal 'zif update'.
> Failed to load: failed to resolve in updates: failed to load md_primary_sql
> file: failed to download missing compressed file: failed to download �<
This looks like HTML from a portal login page or something. It also looks like there's some memory corruption going on (�<) -- in which case can you grab me the output from "valgrind zif update -v" if you can reproduce this -- thanks.
Nope neither system is behind a captive portal and this occurred on two totally separate networks.
Although I do have IPv6 enabled via native connectivity and tunnel depending on location.
I will begin using "valgrind zif update -v" from now on when running updates in the hope of catching this critter.
Created attachment 525211 [details]
valgrind output of valgrind zif install -v libusb-debuginfo
valgrind zif install -v libusb-debuginfo
Yum was able to find and install libusb-debuginfo
Setting up Install Process
--> Running transaction check
---> Package libusb-debuginfo.x86_64 1:0.1.3-9.fc15 will be installed
--> Finished Dependency Resolution
Packages used to produce valgrind report
What does "zif repo-list" say?
Created attachment 525217 [details]
Output of 'zif repo-list'
Output of 'zif repo-list'
(In reply to comment #6)
> Yum was able to find and install libusb-debuginfo
Author: Richard Hughes <firstname.lastname@example.org>
Date: Wed Sep 28 12:02:51 2011 +0100
Enable -debuginfo repos when we try to install -debuginfo packages
The yum-plugin-auto-update-debug-info code enables debuginfo repos when we try
to install -debuginfo packages, so we should probably copy that behaviour.
There's a new option called auto_enable_debuginfo (default true) in zif.conf to
Resolves some of https://bugzilla.redhat.com/show_bug.cgi?id=740623
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.
(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached 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 to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.
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.
The process we are following is described here: