Description of problem: Software update seems to hang. Version-Release number of selected component (if applicable): [root@hoho6 ~]# uname -a Linux hoho6.chidig.com 3.7.6-201.fc18.x86_64 #1 SMP Mon Feb 4 15:54:08 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux How reproducible: I tried a couple of times. Steps to Reproduce: 1. Open Activities -> Software 2. Click on menu at top of screen to the left 'Software Updates' 3. Select 'Check for updates' 4. Application opens, checks for updates and says 590 updates (321.6MB) 5. I click on Install Updates button 6. 'Install Updates' button greys out 7. Not much else happens - no user feedback. 8. I clicked on Activities and selected 'System Monitor' 9. Resources - Not much in the way of network activity. 10. Processes - gpk-update-viewer is grabbing about 100% of one processor (out of 4). Actual results: Looks like it is hanging - even after waiting 50 minutes or more. Expected results: It should do its job without looking like a 'livelock'. Finish update Additional info: The first time I did it, I had the suspicion that the kernel replacement might be the problem, so I did a 'Quit', then did Activities -> Software - Search for Kernel. I then selected the latest kernel and replaced it with no problems (and no request to reboot afterwards (??)). While it was replacing the kernel, I noticed that there was glib, etc. with the new kernel number. Software Updates had not suggested that I also replace those components, so I ran Software Updates again, selecting those kernel related components that seemed in need of also replacing. After all of this replacement, I rebooted (shutdown -r now) with the CLI as the GUI no longer has a restart possibility. I then again went into Software and using the top screen menu asked for 'Check for Updates'. And it hung as before. Maybe I am not waiting long enough? 590 components seems a lot. Perhaps there is some activity within gpk-update-viewer that requires an exponential (in N ) amount of time?
Still hung. Maybe things will have happened by the morning..
Still hung this morning. Giving up on 'Software'->'Check for updates' I went to 'yum update' and it found lots of things to update, then it ended with a complaint: ---> Package texlive-texdirflatten-bin.noarch 2:svn12782.0-13.20130102_r28692.fc18 will be installed --> Finished Dependency Resolution Error: Package: ovirt-engine-cli-3.2.0.9-2.fc18.noarch (updates) Requires: ovirt-engine-sdk >= 3.2.0.3 Installed: ovirt-engine-sdk-3.2.0.2-1.fc18.noarch (installed) ovirt-engine-sdk = 3.2.0.2-1.fc18 You could try using --skip-broken to work around the problem ** Found 1 pre-existing rpmdb problem(s), 'yum check' output follows: 2000:jdk-1.7.0_05-fcs.x86_64 is a duplicate with 2000:jdk-1.7.0_03-fcs.x86_64 [root@hoho6 user1]# Maybe I will work with rewriting the rpmdb or whatever is needed to clear that problem.
I did a yum remove on the 2nd duplicate shown above Then again yum update, which ended in: ---> Package texlive-texdirflatten-bin.noarch 2:svn12782.0-13.20130102_r28692.fc18 will be installed --> Finished Dependency Resolution Error: Package: ovirt-engine-cli-3.2.0.9-2.fc18.noarch (updates) Requires: ovirt-engine-sdk >= 3.2.0.3 Installed: ovirt-engine-sdk-3.2.0.2-1.fc18.noarch (installed) ovirt-engine-sdk = 3.2.0.2-1.fc18 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest [root@hoho6 user1]# rpm -Va --nofiles --nodigest Again, running yum update gives: ---> Package texlive-texdirflatten-bin.noarch 2:svn12782.0-13.20130102_r28692.fc18 will be installed --> Finished Dependency Resolution Error: Package: ovirt-engine-cli-3.2.0.9-2.fc18.noarch (updates) Requires: ovirt-engine-sdk >= 3.2.0.3 Installed: ovirt-engine-sdk-3.2.0.2-1.fc18.noarch (installed) ovirt-engine-sdk = 3.2.0.2-1.fc18 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest [root@hoho6 user1]# Since I already did the rpm -Va.., I will try the skip broken: It seems like it is working: Upgrade 590 Packages Skipped (dependency problems) 1 Package Total size: 455 M Total download size: 322 M Is this ok [y/N]: y Downloading Packages: Setting up and reading Presto delta metadata updates/prestodelta | 1.2 MB 00:01 Processing delta metadata Download delta size: 35 M ... ...
Ok, using 'yum update --skip-broken' it completed successfully. It is not telling me to log out or reboot, but I think I will anyway, then try Software -> Check update just to be perverse.
I did reboot and did Software->Check for Updates. It needed one update - ovirt, but when I did it, there was an error. See attached png screendump.
Created attachment 696230 [details] Screendump of update failure.
Running 'yum update' gives: [root@hoho6 user1]# yum update Loaded plugins: langpacks, presto, refresh-packagekit Resolving Dependencies --> Running transaction check ---> Package ovirt-engine-cli.noarch 0:3.2.0.5-1.fc18 will be updated ---> Package ovirt-engine-cli.noarch 0:3.2.0.9-2.fc18 will be an update --> Processing Dependency: ovirt-engine-sdk >= 3.2.0.3 for package: ovirt-engine-cli-3.2.0.9-2.fc18.noarch --> Finished Dependency Resolution Error: Package: ovirt-engine-cli-3.2.0.9-2.fc18.noarch (updates) Requires: ovirt-engine-sdk >= 3.2.0.3 Installed: ovirt-engine-sdk-3.2.0.2-1.fc18.noarch (installed) ovirt-engine-sdk = 3.2.0.2-1.fc18 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest [root@hoho6 user1]# Hmm, maybe a dependent file has not yet been put into the system. Will wait a bit.
This is happening to me too with gnome-packagekit-3.6.1-2.fc18.x86_64. gpk-update-viewer runs, downloads a list of updates, then shows a list of packages with a little broom icon beside them, indicating that it is cleaning up. But it never completes. I have left it running for overnight but it did nothing. An strace of the running process shows: lstat("/usr/share/gnome-packagekit/icons/hicolor/22x22/status/pk-package-installed.png", {st_mode=S_IFREG|0644, st_size=695, ...}) = 0 open("/usr/share/gnome-packagekit/icons/hicolor/22x22/status/pk-package-installed.png", O_RDONLY|O_NOATIME) = -1 EPERM (Operation not permitted) open("/usr/share/gnome-packagekit/icons/hicolor/22x22/status/pk-package-installed.png", O_RDONLY) = 13 read(13, "\211PNG\r\n\32\n\0\0\0\rIHDR\0\0\0\26\0\0\0\26\10\6\0\0\0\304\264l"..., 4096) = 695 close(13) = 0 open("/usr/share/gnome-packagekit/icons/hicolor/22x22/status/pk-package-installed.png", O_RDONLY) = 13 fstat(13, {st_mode=S_IFREG|0644, st_size=695, ...}) = 0 read(13, "\211PNG\r\n\32\n\0\0\0\rIHDR\0\0\0\26\0\0\0\26\10\6\0\0\0\304\264l"..., 65536) = 695 read(13, "", 65536) = 0 close(13) = 0 It's just opening the file /usr/share/gnome-packagekit/icons/hicolor/22x22/status/pk-package-installed.png, reading a few bytes, closing it, then repeating. The process has no network sockets open. $ netstat -anp |grep 17390 unix 3 [ ] STREAM CONNECTED 9793009 17390/gpk-update-vi unix 3 [ ] STREAM CONNECTED 9793007 17390/gpk-update-vi unix 3 [ ] STREAM CONNECTED 9794260 17390/gpk-update-vi unix 3 [ ] STREAM CONNECTED 9794261 17390/gpk-update-vi
Same problem as comment 8 here. Repeatable. Command line yum update is working without problems. I noticed several delta repos not being available. On another machine gpk-update-view is looping with 100% CPU (after resolving dependencies) yum update working fine here, too. Noticed discrepancy between delta and two files to be updated and missing GPG key for rpmfusion requested to be downloaded.
Created attachment 710915 [details] Stack dump of stuck update process This gstack stack dump shows all running threads in gpk-update-viewer.
This gets weirder. While gpk-update-viewer was running but stuck, I ran yum with no parameters in a shell window. Immediately gpk-update-viewer put up an error message box saying "Timeout" or some such, but that it should do that exactly when I ran yum seems too coincidental. But stranger still, when I told gpk-update-viewer to install packages again, it did so without error. This might suggest some kind of locking problem - but when gpk-update-viewer was stuck, there were no signs of any locks on the rpm database: $ db_stat -Cl -h /var/lib/rpm =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock REGINFO information: Environment Region type 1 Region ID /var/lib/rpm/__db.001 Region name 0x7f28b098b000 Region address 0x7f28b098b0a0 Region allocation head 0x7f28b098b6a8 Region primary address 0 Region maximum allocation 0 Region allocated Region allocations: 95 allocations, 0 failures, 0 frees, 1 longest REGION_SHARED Region flags =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by lockers: Locker Mode Count Status ----------------- Object --------------- $
Duplicate of: bug #830365 ?
(In reply to comment #12) > Duplicate of: bug #830365 ? Comment 27 of bug #830365 seems to indicate that an upgrade to F18 fixes that bug. ---- yum works fine here in F18, but the Gnome utility that calls yum has problems. In Comment #2 the suspicion was that a diagnostic problem with yum is not handled well by Gnome and causes the hang.. ----- Today, I had lots of updates. In my screen upper right corner, when I clicked on my user name, the dialog box opens. Below the line 'Power Off' (!!) there was a notification saying that if I clicked on the note, it would install the updates and reboot the system (there was a kernel replacement). I clicked on the note. Immediately (!!) the system rebooted and came up with the network turned off - so it was not possible to update.. When the system rebooted, I turned the network back on (my live network connection is the 5th interface from the top - perhaps if it was the 1st, then gnome would find it). ----- I went back to 'yum update' and yum did the update just fine.
I'm also running into the same issue on F18. I did a strace of the process to see if I could figure out why it was using so much cpu and found it trying to access the same file over and over again. lstat("/usr/share/gnome-packagekit/icons/hicolor/22x22/status/pk-package-installed.png", {st_mode=S_IFREG|0644, st_size=695, ...}) = 0 open("/usr/share/gnome-packagekit/icons/hicolor/22x22/status/pk-package-installed.png", O_RDONLY|O_NOATIME) = -1 EPERM (Operation not permitted) open("/usr/share/gnome-packagekit/icons/hicolor/22x22/status/pk-package-installed.png", O_RDONLY) = 13 read(13, "\211PNG\r\n\32\n\0\0\0\rIHDR\0\0\0\26\0\0\0\26\10\6\0\0\0\304\264l"..., 4096) = 695 close(13) = 0 open("/usr/share/gnome-packagekit/icons/hicolor/22x22/status/pk-package-installed.png", O_RDONLY) = 13 fstat(13, {st_mode=S_IFREG|0644, st_size=695, ...}) = 0 read(13, "\211PNG\r\n\32\n\0\0\0\rIHDR\0\0\0\26\0\0\0\26\10\6\0\0\0\304\264l"..., 65536) = 695 read(13, "", 65536) = 0 close(13) = 0 recvfrom(6, 0x7d0d74, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=3, events=POLLIN}], 3, 0) = 0 (Timeout) recvfrom(6, 0x7d0d74, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=3, events=POLLIN}], 3, 0) = 0 (Timeout) recvfrom(6, 0x7d0d74, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=3, events=POLLIN}], 3, 0) = 0 (Timeout)
*** Bug 911915 has been marked as a duplicate of this bug. ***
*** Bug 922697 has been marked as a duplicate of this bug. ***
*** Bug 949342 has been marked as a duplicate of this bug. ***
Is there anyone willing to fix this problem? it's a shame this kind of bug survives for such a long time. Is this app dead?
Same problem. This bug seems to have been here for a very long time. Very annoying, very sloppy. The GUI interface to update software seems not to be able to handle even mildly complex updates. It starts, the progress window on the bottom says "Running" then it goes away. "top" says update-viewer is taking lots of cycles, but nothing is happenning. Doing just a few related updates at a time usually works. Going the this by hand with yum update, works.
@Mikey, comment 19 There might be two bugs here. I've found that if you use yum to apply all updates as of April 8, "Software Update" would no longer burn 100% CPU. I have found that when I try to add lots of packages, it behaves much as you describe EXCEPT no CPU cycles are consumed. I would guess that this is a second bug but I haven't had the time to generate a good bug report. Observation: when I try to add all the package groups that I want, and apply, gnome-packagekit looks like it is working but no progress happens (even over a period of half a day!). If I try to exit, it warns me that I will lose all the selections I've made (of course I exit anyway). If I try one package group at a time, it seems to work. It might just be that one package group in particular is the problem, and that haven't tried it yet, but I haven't the patience to try so many experiments. I'm pretty discouraged about gnome-packagekit. When I ask on #fedora, they laugh in my face for trying to use it.
(In reply to comment #20) > I'm pretty discouraged about gnome-packagekit. When I ask on #fedora, they > laugh in my face for trying to use it. Unfortunately it's the default tool, in particular for beginners who can't be expected to use the command line...
(In reply to comment #21) > (In reply to comment #20) > > > I'm pretty discouraged about gnome-packagekit. When I ask on #fedora, they > > laugh in my face for trying to use it. > > Unfortunately it's the default tool, in particular for beginners who can't > be expected to use the command line... Exactly so. It is a sad reflection on Fedora as a desktop operating system that something so fundamental as software updates, which absolutely have to work, are not only failing, but have been failing for months and nobody cares. Fedora 18 will be my last Fedora, I'm afraid. This bug, combined with nouveau's stability taking a nosedive, breaking suspend on my laptop (https://bugzilla.redhat.com/show_bug.cgi?id=922435) and a host of graphics crashes, have left me with a laptop that is less functional than it was a year ago when I ran Fedora 16 on it. Fedora 16 didn't require fall-back mode, I could shut the lid and it would suspend, and it could hibernate if battery was low,
The last time I used the GUI Update (which was prompted by the little notification at the bottom of my screen (oh, well - lets try it..) It looked like it was working fine, but then at the end it said there was a problem, and left me to kill it. Executing 'yum update' from a terminal window showed that the GUI tool (subject of this bugzilla) did absolutely nothing. All updates needed to be downloaded and (installed?) again. I'm wondering if the problem is Gnome! Perhaps the limits of complexity have been exceeded, and there is no one around at Gnome who can fix it. I have noticed that even the Print command has problems - does not respond to scaling and portrait/landscape - but that is another bugzilla subject.
Interestingly enough, I'm having the exact same issue under a fresh install of OpenSUSE 12.3. On this box, the / is mounted via NFS (and the box is booted via PXE), and I thought maybe it had something to do with that. But by reading the comments here, I guess this is not the case. So the issue definitely is on Gnome's side... even if actually I'm using XFCE but for some reason, this is gnome-packagekit that insists in taking care of updates via GUI. open("/usr/share/gnome-packagekit/icons/hicolor/22x22/status/pk-package-installed.png", O_RDONLY|O_LARGEFILE) = 12 fstat64(12, {st_mode=S_IFREG|0644, st_size=695, ...}) = 0 read(12, "\211PNG\r\n\32\n\0\0\0\rIHDR\0\0\0\26\0\0\0\26\10\6\0\0\0\304\264l"..., 65536) = 695 read(12, "", 65536) = 0 close(12) = 0 lstat64("/usr/share/gnome-packagekit/icons/hicolor/22x22/status/pk-package-installed.png", {st_mode=S_IFREG|0644, st_size=695, ...}) = 0 open("/usr/share/gnome-packagekit/icons/hicolor/22x22/status/pk-package-installed.png", O_RDONLY|O_LARGEFILE) = 12 fstat64(12, {st_mode=S_IFREG|0644, st_size=695, ...}) = 0 [...] The installed RPM is named gnome-packagegit-3.6.1-3.3.1.i586 Side note : renaming this stupid file doesn't help, gpk-update-viewer won't get out of this loop.
The problem is most probably somewhere in the GNOME or GTK3 library stack. Just in case some of the GNOME developers decides to look into the issue, I still have a manually triggered core dump from bug #922697 that I could provide. I have insufficient knowledge of the inner workings of GTK/GNOME to try and analyze it.
(In reply to comment #22) > Exactly so. It is a sad reflection on Fedora as a desktop operating system > that something so fundamental as software updates, which absolutely have to > work, are not only failing, but have been failing for months and nobody > cares. Could we be a little less dramatic please? This bus isn't happening for everyone, just a very few people. I don't know where the bug is yet. Can someone who can still reliably trigger the bug please get me the output of: gpk-update-viewer --verbose and then try to trigger the bug. I think it might also be fixed with this http://koji.fedoraproject.org/koji/buildinfo?buildID=417921 build. If someone can test this on F19 (or rebuild the RPM for f18) I'd appreciate it. Thanks.
Seeing Comment #25, I gave it the diagnostic command [user1@hoho6 stral-acct-2013]$ gpk-update-viewer --verbose 09:04:40 GnomePackageKit Verbose debugging enabled (on console 1) 09:04:40 GnomePackageKit using native mode: 700x1200 09:04:40 GnomePackageKit wrap_width is impossibly small -200 09:04:40 GnomePackageKit wrap_width is impossibly small -200 09:04:41 GnomePackageKit wrap_width is impossibly small -200 09:04:41 GnomePackageKit only showing newest updates 09:04:41 GnomePackageKit status wait 09:04:41 GnomePackageKit wrap_width is impossibly small -200 09:04:41 GnomePackageKit status wait 09:04:41 GnomePackageKit status setup 09:04:41 GnomePackageKit status query 09:04:41 GnomePackageKit status finished 09:04:41 GnomePackageKit status setup 09:04:41 GnomePackageKit status info 09:04:43 GnomePackageKit status download-updateinfo 09:04:44 GnomePackageKit status finished 09:04:44 GnomePackageKit network status is online 09:04:45 GnomePackageKit wrap_width is impossibly small -200 [user1@hoho6 stral-acct-2013]$ Much to my surprise, the Software Updates window came up and said that there were no updates now. It exited when I clicked the button. Very well behaved, although unsolicited. The 'no updates needed' was because I had just done an update using 'yum update' before reading your email. Perhaps there is something in the output above that will help (wrap width impossibly small -200 ?)
(In reply to comment #26) > (In reply to comment #22) > > Exactly so. It is a sad reflection on Fedora as a desktop operating system > > that something so fundamental as software updates, which absolutely have to > > work, are not only failing, but have been failing for months and nobody > > cares. > > Could we be a little less dramatic please? This bus isn't happening for > everyone, just a very few people. I don't know where the bug is yet. Can > someone who can still reliably trigger the bug please get me the output of: > > gpk-update-viewer --verbose > > and then try to trigger the bug. Unfortunately, the only computer on which I can currently reproduce the bug and which has updates waiting is an openSuse box. I rebooted my Fedora 18 laptop a few days ago to do an fsck and the updates problem has not re-occurred on it since then. This is the output of gpk-update-viewer --verbose when run on openSuse: 11:30:47 GnomePackageKit Verbose debugging enabled (on console 0) 11:30:47 GnomePackageKit using native mode: 700x921 *** 11:30:47 GnomePackageKit wrap_width is impossibly small -200 *** *** 11:30:47 GnomePackageKit wrap_width is impossibly small -200 *** *** 11:30:47 GnomePackageKit wrap_width is impossibly small -200 *** 11:30:47 GnomePackageKit only showing newest updates 11:30:47 GnomePackageKit status wait *** 11:30:47 GnomePackageKit wrap_width is impossibly small -200 *** 11:30:47 GnomePackageKit status wait 11:30:47 GnomePackageKit status setup 11:30:47 GnomePackageKit status query 11:30:48 GnomePackageKit status refresh-cache 11:30:48 GnomePackageKit status finished 11:30:48 GnomePackageKit status setup 11:30:48 GnomePackageKit status query 11:30:48 GnomePackageKit status refresh-cache 11:30:50 GnomePackageKit status finished 11:30:50 GnomePackageKit adding: 11:30:50 GnomePackageKit adding: id=openSUSE-2013-163;1;noarch;repo-update, text=polkit-default-privs: set logind inhibit policies to upstream defaults <span color="#a7aba7">openSUSE-2013-163-1</span> 11:30:50 GnomePackageKit adding: id=openSUSE-2013-196;1;noarch;repo-update, text=systemtap: Change how systemtap looks for tracepoint header files and added dependencies <span color="#a7aba7">openSUSE-2013-196-1</span> 11:30:50 GnomePackageKit adding: id=openSUSE-2013-197;1;noarch;repo-update, text=mono-core: Several fixes <span color="#a7aba7">openSUSE-2013-197-1</span> 11:30:50 GnomePackageKit adding: id=openSUSE-2013-199;1;noarch;repo-update, text=timezone: regular timezone updates to 2013a. <span color="#a7aba7">openSUSE-2013-199-1</span> [Lots more packages elided for brevity] 11:30:50 GnomePackageKit network status is online *** 11:30:50 GnomePackageKit wrap_width is impossibly small -168 *** 11:30:50 GnomePackageKit status wait 11:30:50 GnomePackageKit status wait *** 11:30:50 GnomePackageKit wrap_width is impossibly small -168 *** 11:30:50 GnomePackageKit status setup 11:30:50 GnomePackageKit status query 11:30:51 GnomePackageKit status finished 11:30:51 GnomePackageKit status setup 11:30:51 GnomePackageKit status query *** 11:30:51 GnomePackageKit wrap_width is impossibly small -146 *** 11:30:52 GnomePackageKit status finished 11:30:52 GnomePackageKit network status is online *** 11:30:52 GnomePackageKit wrap_width is impossibly small -90 *** 11:30:56 GnomePackageKit Doing the package updates 11:30:56 GnomePackageKit status wait 11:30:56 GnomePackageKit status setup 11:30:57 GnomePackageKit status dep-resolve 11:30:57 GnomePackageKit status update 11:30:57 GnomePackageKit status install 11:30:57 GnomePackageKit adding: id=libebl1;0.155-2.1.3;x86_64;openSUSE-12.3-1.7, text=A collection of utilities and DSOs to handle compiled objects <span color="#a7aba7">libebl1-0.155-2.1.3 (64-bit)</span> 11:30:57 GnomePackageKit adding: id=libpurple-lang;2.10.7-4.4.1;noarch;repo-update, text=Languages for package pidgin <span color="#a7aba7">libpurple-lang-2.10.7-4.4.1</span> 11:30:57 GnomePackageKit adding: id=libpurple-branding-openSUSE;12.2-4.4.1;noarch;repo-update, text=GLib-based Instant Messenger Library -- openSUSE Default Configuration <span color="#a7aba7">libpurple-branding-openSUSE-12.2-4.4.1</span> 11:30:57 GnomePackageKit adding: id=polkit-default-privs;12.3-6.15.1;noarch;repo-update, text=SUSE PolicyKit default permissions <span color="#a7aba7">polkit-default-privs-12.3-6.15.1</span> 11:30:57 GnomePackageKit adding: id=totem-lang;3.6.3-2.5.1;noarch;repo-update, text=Languages for package totem <span color="#a7aba7">totem-lang-3.6.3-2.5.1</span> [more package listings elided for brevity..] 11:30:58 GnomePackageKit status finished *** 11:30:58 GnomePackageKit wrap_width is impossibly small -68 *** 11:31:00 GnomePackageKit no packages with removing 11:31:00 GnomePackageKit no packages with updating 11:31:00 GnomePackageKit no packages with obsoleting 11:31:00 GnomePackageKit no packages with reinstalling 11:31:00 GnomePackageKit no packages with downgrading *** 11:31:01 GnomePackageKit wrap_width is impossibly small -146 *** *** 11:31:01 GnomePackageKit wrap_width is impossibly small -68 *** *** 11:31:04 GnomePackageKit wrap_width is impossibly small -146 *** *** 11:31:05 GnomePackageKit wrap_width is impossibly small -68 *** At this point the UI does not update any more, although the program is alive and will respond to the Quit button, which is also the only button enabled. From what I understand of the way this thing works, the UI is simply sitting in an idle loop waiting for PackageKit to send it notifications of progress by calling certain callback functions that it has passed, but PackageKit never sends any more notifications of progress, and gpk-update-viewer doesn't seem to have an upper limit on how long it will wait. If and when my Fedora laptop next demonstrates the bug I will re-run gpk-update-viewer with the --verbose switch and attach the output. I'm guessing that the "wrap_width" message is just noise, but I leave it in for completeness.
Created attachment 751189 [details] gpk-update-viewer --verbose log log of the gpk-update-viewer session, 3.6.1-2.fc18. In the critical situation, nothing is logged. The dependencies are correctly determined, the problem occurs after user clicks "install updates". I created a core file of gpk-update-viewer in the hope that it may be helpful: ftp://ftp.ts.fujitsu.com/outgoing/bz909761.core.1312.xz (27MB, please download quickly, it will be auto-deleted after a few days).
(In reply to Richard Hughes from comment #26) > I think it might also be fixed with this > http://koji.fedoraproject.org/koji/buildinfo?buildID=417921 build. If > someone can test this on F19 (or rebuild the RPM for f18) I'd appreciate it. > Thanks. The problem occurs only when many packages need updates, so this only makes sense when as few packages as possible are updated wrt the reference reproduction system before trying to reproduce. In order to do that, I downloaded the SRPM and compiled it on my (almost) pristine F18 system that I use for reproducing. Unfortunately this fails with the error "g-ir-scanner: error: no such option: -f". Apparently the gobject-introspection package is too old to compile PackageKit 0.8.8. Any idea how to work around this?
Created attachment 751229 [details] Output of gpk-update-viewer --verbose Requested output from gpk-update-viewer --verbose
Created attachment 751235 [details] strace of hung gpk-update-viewer --verbose command This is the last 1000 lines of a strace -f -p <gpk-update-viewer-pid> I ran while gpk-update-viewer was hung. I notice its constantly trying to open the same icon file which seems odd.
I also triggered a core dump while it was in this state which was picked up by abrt and is reported here: https://bugzilla.redhat.com/show_bug.cgi?id=964829
I installed a fresh F18 x86_64 from a live USB stick, and then ran the gpk-update-viewer command for the first update. No problem. So much for an easy reproduction. On another machine, with F18, I did the gpk-update-viewer command and got a hang. 100% CPU. But Russel has beaten me to the punch. I had told it to apply the changes and OKed the things added for dependencies. gpk-update-viewer then went off, never to finish. The command output isn't very interesting (as far as I can tell). I'll attach the log anyway. There sure are a lot of messages like this: ESC[0mESC[32m18:10:05 ESC[34mGnomePackageKitESC[0m ESC[34mwrap_width is impossibly small -200 strace spews a bunch of operations reading an icon. open("/usr/share/gnome-packagekit/icons/hicolor/22x22/status/pk-package-installed.png", O_RDONLY) = 13 In about 5 seconds, strace logged 21k lines. sort -u on the output gave 41 distinct lines. Almost all operations were to do with the one icon. There was a poll and two recvfroms too. The gpk-update-viewer process is running with my userid. Does it need a helper process with more privileges? There isn't one running.
Created attachment 751334 [details] log of gpk-update-viewer --verbose (see comment 34)
We may be talking about two different bugs here. For me software update has only hung when the "additional confirmation required" window opened. And it has invariably hung when that window opens (and I give it the go-ahead).
It appears to be the number of updates that is causing the update hang. When I had 76 or more updates to apply, the update hung. When I reduced the number of updates to batches of 20 or less each, the update was successful.
Bug 969852 might be a dup, occurs on a freshly installed F19 beta and attempting to update on reboot from installation.
Created attachment 756694 [details] Output from gpk-update-viewer --verbose This problem has now resurfaced on my Fedora laptop. The output of gpk-update-viewer is attached. A previous poster suggested that the problem lies with the number of updates. I have 138 updates now. Unfortunately, there is no way using the UI to deselect all packages, so that I can test installing just a handful.
I think Bug 951804 is also a dupe.
The issue resurfaced on my F18 machine. Please let me know if you want me to do any tests or to provide additional information. There are now 101 updates available.
See also: https://bugzilla.gnome.org/show_bug.cgi?id=695083
Created attachment 762577 [details] output of --verbose
Created attachment 762578 [details] outout of ltrace of gpk-update-viewer
It's happened 3 times today. When it happened this time I had 26 updates to install. The first time I tried I had more, so some where installed prior to hanging.
Every time I've tried to do an update today gpk-update-viewer has hung. I tried selecting only 6 of the 26 updates and it still hangs. It shouldn't take 15 minutes to install 6 updates. In every case that it has hung today the last 3 lines of the --verbose are: 11:46:10 GnomePackageKit status finished 11:46:10 GnomePackageKit we've said we don't want the dep dialog 11:46:10 GnomePackageKit wrap_width is impossibly small -98 Don't know if this means anything. An strace output shows it spinning accessing an image: [pid 14894] 11:56:22.830905 open("/usr/share/gnome-packagekit/icons/hicolor/22x22/status/pk-package-installed.png", O_RDONLY|O_LARGEFILE) = 13 [pid 14894] 11:56:22.831056 fstat64(13, {st_mode=S_IFREG|0644, st_size=695, ...}) = 0 [pid 14894] 11:56:22.831221 read(13, "\211PNG\r\n\32\n\0\0\0\rIHDR\0\0\0\26\0\0\0\26\10\6\0\0\0\304\264l"..., 65536) = 695 [pid 14894] 11:56:22.831356 read(13, "", 65536) = 0 [pid 14894] 11:56:22.831500 gettimeofday({1371581782, 831543}, NULL) = 0 It shouldn't be this hard to update.
(In reply to Danny Staple from comment #40) > I think Bug 951804 is also a dupe. This does appear to be a duplicate of 951804. Is it possible to get the fix backported to F18?
*** Bug 951804 has been marked as a duplicate of this bug. ***
Casey #47: I don't see any fix there to be backported. I feel that this should be a blocker for the release of Fedora 19. It's a pretty fundamental problem for users. My pure guess is that it cannot be duplicated with the Release Candidate since there are too few updates available for it.
(In reply to D. Hugh Redelmeier from comment #49) > Casey #47: I don't see any fix there to be backported. https://admin.fedoraproject.org/updates/FEDORA-2013-11160/gnome-packagekit-3.8.2-2.fc19 > I feel that this should be a blocker for the release of Fedora 19. It's a > pretty fundamental problem for users. It is already fixed in F19. See above and bug 969852 > My pure guess is that it cannot be duplicated with the Release Candidate > since there are too few updates available for it. Well it can't because it got fixed ;)
I think this is fixed with gnome-packagekit-3.8.2-2.fc19. When I apply that to fc19 beta, updating works with more than 400 updates available.
gnome-packagekit-3.6.2-2.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/gnome-packagekit-3.6.2-2.fc18
Package gnome-packagekit-3.6.2-2.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing gnome-packagekit-3.6.2-2.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-11864/gnome-packagekit-3.6.2-2.fc18 then log in and leave karma (feedback).
gnome-packagekit-3.6.2-2.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
I have similar issue. The "gpk-update-viewer" is using 96 % of CPU and does nothing. The problem has been fixed so far, by restarting the update process.
This comment was flagged a spam, view the edit history to see the original text if required.