Bug 969852 - Software Update fails to update
Software Update fails to update
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: gnome-packagekit (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
AcceptedBlocker
:
Depends On:
Blocks: F19Blocker/F19FinalBlocker
  Show dependency treegraph
 
Reported: 2013-06-02 14:16 EDT by Chris Murphy
Modified: 2013-07-01 02:03 EDT (History)
5 users (show)

See Also:
Fixed In Version: gnome-packagekit-3.8.2-2.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-20 01:59:05 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
pkmon.log (155.55 KB, text/plain)
2013-06-02 14:16 EDT, Chris Murphy
no flags Details
gpk-update-viewer --verbose (159.95 KB, text/plain)
2013-06-02 23:27 EDT, Chris Murphy
no flags Details

  None (edit)
Description Chris Murphy 2013-06-02 14:16:40 EDT
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.
Comment 1 Chris Murphy 2013-06-02 14:18:49 EDT
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"
Comment 2 Chris Murphy 2013-06-02 23:27:29 EDT
Created attachment 756157 [details]
gpk-update-viewer --verbose
Comment 3 Chris Murphy 2013-06-02 23:28:10 EDT
This could be a duplicate of bug 909761.
Comment 4 Adam Williamson 2013-06-03 13:27:12 EDT
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!
Comment 5 Adam Williamson 2013-06-03 17:22:25 EDT
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.
Comment 6 Richard Hughes 2013-06-06 04:28:27 EDT
(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?
Comment 7 Chris Murphy 2013-06-06 08:21:47 EDT
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.
Comment 8 Chris Murphy 2013-06-06 08:50:57 EDT
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.
Comment 9 Richard Hughes 2013-06-06 11:59:36 EDT
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!
Comment 10 Adam Williamson 2013-06-06 15:14:07 EDT
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.
Comment 11 Chris Murphy 2013-06-06 15:54:43 EDT
(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.
Comment 12 apollo21b 2013-06-07 01:54:29 EDT
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'.)
Comment 13 Kurt Miller 2013-06-11 23:31:38 EDT
Same issue here. Fresh install of F19 beta. 500+ updates. Same symptoms. UEFI BIOS. ASUS Z87-Pro motherboard with 1007 bios.
Comment 14 Adam Williamson 2013-06-12 13:50:14 EDT
We should probably note this as a common bug for Beta users...
Comment 15 Adam Williamson 2013-06-14 17:57:30 EDT
hughsie: any chance that PackageKit-0.8.9-4.fc19 fixes this? Or is this different from the offline update bug?
Comment 16 Richard Hughes 2013-06-18 08:59:28 EDT
After quite a few hours working on this, I think I've found the bug:

commit 4077ba3ea30354ef070d640a5af4b6a913e97f4b
Author: Richard Hughes <richard@hughsie.com>
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.
Comment 17 Fedora Update System 2013-06-18 09:27:51 EDT
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
Comment 18 Chris Murphy 2013-06-18 15:12:16 EDT
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)
Comment 19 Fedora Update System 2013-06-18 15:40:57 EDT
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).
Comment 20 Adam Williamson 2013-06-18 18:11:22 EDT
Confirming the fix, and I didn't find any packages still remaining to be updated afterwards.
Comment 21 Fedora Update System 2013-06-20 01:59:05 EDT
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.
Comment 22 Adam Williamson 2013-07-01 02:03:07 EDT
No need for commonbugs any more.

Note You need to log in before you can comment on or make changes to this bug.