Created attachment 756046 [details] pkmon.log Description of problem: After installation of system and reboot, a notification appears informing the user they should apply software updates. Upon clicking "Install Updates" nothing happens, there is no indication the update succeeded or failed, gpk-update-view appears to hang, consuming 100% CPU for 30+ minutes with no network or disk activity. Version-Release number of selected component (if applicable): gnome-packagekit-3.8.2-1.fc19.x86_64 How reproducible: Always on baremetal UEFI, and in VirtualBox VM BIOS. Steps to Reproduce: 1. Install Fedora-Live-Desktop-x86_64-19-Beta-1.iso 2. Reboot 3. su -c "pkmon" 4. Wait for software updates notification or manually launch Software Update. 5. Click Install Updates button. Actual results: Status bar says Running, then Resolving Dependencies, then vanishes. Software Update hangs, no error message, no success message, consumes 100% CPU according to top, computer gets hot, fans blowing loudly. The Software Update application Quit button is available, the Install Updates button is grayed out. There is no progress bar. Expected results: For the system to be updated. Additional info: e.g. this line in the pkmon file attached: /8_abcddcda package installing:kernel;3.9.4-300.fc19;x86_64;fedora:The Linux kernel This is bogus, the kernel package is not installed, it's nowhere to be found on the system, and there is no 3.9.4 kernel in /boot.
Since this is also a default update method, proposing as final release blocker. "The installed system must be able to download and install updates with yum and with the default graphical package manager in all release-blocking desktops"
Created attachment 756157 [details] gpk-update-viewer --verbose
This could be a duplicate of bug 909761.
Discussed at 2013-06-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-03/f19final-blocker-review-2.2013-06-03-16.00.log.txt . Although this clearly isn't affecting all cases (the test passed for me with Beta), this looks worrying enough to accept as a blocker for now. If it turns out to be some kind of corner case we could re-evaluate this decision later. Richard, does this look the same as 909761 to you? Chris, can you provide the debug output that Richard requested in that bug? Thanks!
Looks like I can reproduce this today on a fresh Beta install with default (en_US.UTF-8) locale, so indeed it appears to be related to the sheer weight of updates (359 in my set) or some specific package in the current update set. But definitely a big problem. I see identical systems to cmurf's description - progress bar disappears, gpk is sucking CPU time, nothing much appears to be happening, pkmon is just showing: Transactions: [none] daemon connected=1 network status=online but I ran it after the bug kicked in, I didn't think to run it before as cmurf did.
(In reply to Chris Murphy from comment #0) > /8_abcddcda package installing:kernel;3.9.4-300.fc19;x86_64;fedora:The > Linux kernel > This is bogus, the kernel package is not installed, it's nowhere to be found > on the system, and there is no 3.9.4 kernel in /boot. This is very odd. I'm wondering if yum is hanging when installing the kernel package. Is there anything to report if you do yum-complete-transaction?
None of the files listed as updated in pkmon.log (attached) have actually been updated. As far as I can tell, the update process never really starts, beyond dependency resolution. There's no yum process running at all, 'ps aux | grep yum' only lists the grep process itself. # yum-complete-transaction Loaded plugins: langpacks, refresh-packagekit No unfinished transactions left. Yet Software Update is running, doing nothing, Quit button is available and Install Updates button is grayed out.
Upon clicking Install Updates, Software Update's progress bar says it's resolving dependencies, at that time a 'ps aux | grep yum' finds one process: 'yumBackend.py update-packages only-trusted;<list of packages>' the status bar then vanishes entirely, and a followup 'ps aux' finds no yum related processes. From the first click on Install Updates to the vanishing of the progress bar is less than a minute. It seems to me some handoff isn't happening, whatever is supposed to happen after 'yumBackend.py update-packages' isn't happening.
Okay, I've fixed a few bugs in PK, but nothing that precisely matches this bug. I'd appreciate it if you could download the PackageKit packages from http://people.freedesktop.org/~hughsient/fedora/19/x86_64/ and then do something like "sudo rpm -Fvh PackageKit*.rpm" -- if this fixes this, or doesn't fix this I'd love to know. Thanks!
Still looks to be busted to me - I did a fresh Beta install, updated with the PK packages specified (note: "yum update PackageKit*" works and does what you'd hope it would, in recent yum versions), rebooted, and ran gpk-update-viewer, iot finds 368 updates, tried to do an update run, and it looks to be in the same situation: the progress bar has disappeared and pkmon shows nothing much going on.
(In reply to Richard Hughes from comment #9) Does not fix the problem for me. Same behavior remains. Unsure if it's related, but the Software Update UI is sorta wonky: before clicking the Install Updates button, some packages have a closed box icon next to them, others have no icon but do have size values. When I click on Install Updates, all packages now have one of two different icons, with some also having size values. The first 1/2 of listed packages have an open box icon with something yellow on the lower right side of the box. The last package with this icon is "policycoreutils-2.1.14-40.fc19" and the first package with just an open box icon is "libodfgen-0.0.2-1.fc19". That's been the case throughout my experience with this bug, over several days and various installs.
Same issue here. Fresh install of F19 beta. 300+ updates, and Software Update hangs with 100% usage of one CPU. Then I did 'sudo yum update' and it worked except for this alert: setroubleshoot: SELinux is preventing /usr/sbin/sendmail.sendmail from read access on the directory /home/apollo. For complete SELinux messages. run sealert -l 0e12d5b4-77f0-4e65-be9d-1f83cb474d8e And I also got warnings about /etc/group, /etc/gshadow, /etc/passwd and /etc/shadow, all of which I have a second copy of now. (Sorry if the yum errors are 'off topic'.)
Same issue here. Fresh install of F19 beta. 500+ updates. Same symptoms. UEFI BIOS. ASUS Z87-Pro motherboard with 1007 bios.
We should probably note this as a common bug for Beta users...
hughsie: any chance that PackageKit-0.8.9-4.fc19 fixes this? Or is this different from the offline update bug?
After quite a few hours working on this, I think I've found the bug: commit 4077ba3ea30354ef070d640a5af4b6a913e97f4b Author: Richard Hughes <richard> Date: Tue Jun 18 13:56:05 2013 +0100 Ignore package progress updates when the transaction is being simulated PackageKit backends do not have to issue INFO_FINISHED when simulating, and most don't bother. As we didn't special-case simulation, we set up the activity spinner on the Package(INFO_UPDATING) event and do not cancel the signal. This leaves every row in the update viewer with a spinning cursor, which due to the way the code was structured lead to an O(n*n) exposion of updates to the cell renderers for each update. For a dozen or so updates it was not noticable, and nobody noticed the slight increase of CPU usage. Now that TeX Live has officially jumped the shark and has many hundreds of sub-packages, it's quite plausible to have *thousands* of small packages to update. This means that the O(n*n) bug stops being a minor increase in CPU and starts to use the CPU at 100% for many hours before completing. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=969852 I'll do a F19 build with this patch now and roll an update for testing.
gnome-packagekit-3.8.2-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/gnome-packagekit-3.8.2-2.fc19
If I start with Fedora-Live-Desktop-x86_64-19-Beta-1.iso, and before reboot install gnome-packagekit-3.8.2-2.fc19 and PackageKit-0.8.9-5.fc19, the problem is fixed for me. Reboots to current kernel. Running 'yum update' reveals a handful of items still need updating: Installing: bijiben x86_64 3.8.2-1.fc19 fedora gnome-weather x86_64 3.8.2-1.fc19 fedora libreoffice-emailmerge x86_64 1:4.1.0.0-9.beta2.fc19 fedora Installing for dependencies: libreoffice-pyuno x86_64 1:4.1.0.0-9.beta2.fc19 fedora Not this bug, but there's a remaining anomaly under the progress bar, the size in MB is bogus: 462 updates selected (1.3 MB)
Package gnome-packagekit-3.8.2-2.fc19: * should fix your issue, * was pushed to the Fedora 19 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.8.2-2.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-11160/gnome-packagekit-3.8.2-2.fc19 then log in and leave karma (feedback).
Confirming the fix, and I didn't find any packages still remaining to be updated afterwards.
gnome-packagekit-3.8.2-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
No need for commonbugs any more.