Bug 442742

The progress bars on the "Refreshing package cache (Refreshing software list)"
progress window are interesting.  The "part progress" bar always advances to
100% then wraps back to zero, and the "task progress" bar never moves - its
stuck at slightly less than 50%.  I don't know if "part progress" is actually
measuring anything, or just moving for the sake of appearing to be doing something.

If you do:

yum clean all
yum check-update

What is the output? Thanks.

# yum clean all
Loaded plugins: changelog, fastestmirror, refresh-packagekit
Cleaning up Everything
Cleaning up list of fastest mirrors
# yum check-update
Loaded plugins: changelog, fastestmirror, refresh-packagekit
Determining fastest mirrors
 * rawhide: mirror.aarnet.edu.au
rawhide                                                  | 2.4 kB     00:00    
primary.sqlite.bz2                                       | 6.1 MB     00:40     

I think I have seen this, too... but not all the time. Only after doing one
update and getting more updates during the same session perhaps?

Greetings, Gents -

Robin:

I've had similar problems with PackageKit for the past week. My systems seems to
"hang" mid-update in various stages of the process (e.g, today's was at
"checking sigs").  As a result, I needed to use yum via a terminal.

Hope the latest (PackageKit-0.1.12-7.20080425.fc9.i386.rpm) fixes this.

If you need me to dig up a log (if there are any - since the PackageKit doesn't
provide finer details of the pkgupdate process), please let me know...

Regards

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

It takes hours for the "downloading file lists (refreshing package cache)" run
to finish. I mean literally hours. Over three hours and possible even five or
six. I have a fast DSL line.

A quick calculation... It must be downloading over 200 gigs of data (possibly
even more)! (Downloading same files over and over again or something - the file
lists can't be that big, can they? :)).

I'm not sure what triggers the run. It seems to run a few times a day. Also the
system runs it (if I'm not logged in).

My box has a fresh install of F9 (i386). I have these packagekit related
packages installed at the moment:

PackageKit-libs-0.1.12-10.20080505.fc9.i386
gnome-packagekit-0.1.12-12.20080430.fc9.i386
yum-packagekit-0.1.12-10.20080505.fc9.i386
PackageKit-0.1.12-10.20080505.fc9.i386

The refresh run eats the system and network resources quite heavily (which
causes all kinds of troubles), so for me this is quite a serious problem. So
serious that I think I have to uninstall PackageKit if I can't figure out what
is the problem.

So this was just me saying "me too" I guess. I just wanted to point out that at
least on my system this indeed happens all the time and the problem is quite
serious.

Right, I'm guessing when it takes hours you're getting a really slow or corrupt
mirror. If you comment out the mmirrorlist and just use baserepo do the problems
go away?

PackageKit runs yum and yum doesn't have these problems...

I did a quick test: Deleted /var/cache/yum and ran:

# time yum provides /usr/bin/gcc

Results:

real    0m14.154s
user    0m5.013s
sys     0m0.499s

Yum needs the file list for that operation, so it took 14 seconds to download
the list. Sure we can't know which mirror was used this time but I've not seen
any issues with yum - only with PackageKit. And with PackageKit this happens
every time (or at least every day - I bet it runs it once a day so that's every
time).

I can do more testing whan I'm physically using the computer. I tested that yum
thing through ssh connection.

Perhaps PackageKit starts the file list download over and over again. (Has some
kind of loop going on. Weird though that if you leave it running it will
eventially finish - but that takes hours.)

Can you try with PackageKit 0.2.x (the newest PackageKit in updates) please.

I am using Update Applet 0.3.5 and the update is stooping at Running task. The Progress bar is completely empty. Fedora 10 beta.

From the menu you could only choose close since cancel is faded out. 

The "gpkK-update-viewer" status is sleeping.

Clifton, what does pkmon say when this happens?

Assigning based on maintainer response to comments.

Reporter, could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. 

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

PackageKit in Fedora 10 doesn't seem to have these problems. I don't know about Fedora 9, but based on the version numbers it's quite probable that this bug has been fixed for quite some time ago.

@jeremy, robert and clifton

Could you please respond to the request for follow up on this bug. Has this problem been resolved for you? 

I know it's been a long time since this report was originally created, however I would like to clear this if possible. Thank you for you help.

I have not seen this problem in quite a while.  I'm running F10.

I have Fedora 10 64bit and i have the same problem with PackegeKit 0.3.14.
Every time i use my notebook the PackegeKit start the Refreshing Cache File task, and often this task never finish and sometimes show a window with a failure message. When i need to update the system, i have to cancel this task (and usually even more in queue).

The next time i will see the failure message i will write that here..

@ Luca

If you do:

yum clean all
yum check-update

Do you still experience the problem.

if you see the problem again, please run 'pkcon' from the command line as it may provide more information.

TK009

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Thank you!
Now all seems to be ok!

Based on the comments I am going to close this bug report. Thanks reporters for helping get this resolved.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers