fwupd consuming very high cpu after startup/login

[Adam Colligan]

I believe this may be a regression (relapse of Bug #1591868 ). I upgraded to yakkety the other day without major incident and have all "updates" checked in the Software and Sources GUI. But after booting and logging in just now, I see fwupd consuming two full cores without letup.

In kern.log I see this line:

fwupd[6242]: Failed to coldplug: UEFI firmware updating not supported

ProblemType: Bug
DistroRelease: Ubuntu 16.10
Package: fwupd 0.7.2-0ubuntu1
ProcVersionSignature: Ubuntu 4.8.0-26.28-generic 4.8.0
Uname: Linux 4.8.0-26-generic x86_64
ApportVersion: 2.20.3-0ubuntu8
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Oct 26 19:49:20 2016
InstallationDate: Installed on 2016-07-03 (115 days ago)
InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
SourcePackage: fwupd
UpgradeStatus: Upgraded to yakkety on 2016-10-25 (1 days ago)

[Mario Limonciello (superm1)]

Hello,

Although it's possible it's a relapse/regression, the more likely situation is another corner case that causes similar symptoms.

The mention in kern.log about failing to coldplug UEFI isn't the cause of this, that's expected if your manufacturer doesn't support UEFI capsule updates.

A similar bug with Ubuntu 16.10 was just reported upstream here:
https://github.com/hughsie/fwupd/issues/70

It has not yet been debugged.

If you are technical enough, can you please follow the same steps mentioned in that bug?
https://github.com/hughsie/fwupd/issues/70#issuecomment-254816591

That combination of artifacts and steps should hopefully help to narrow down what's going on.

Also, please immediately back up the contents of /var/lib/app-info/yaml (and make sure you follow symlinks) as if it's caused by transient metadata in that directory it may clear up on it's own the next day and be hard to reproduce.

[Mario Limonciello (superm1)]

This was confirmed upstream to be caused by a problem in appstream-glib. 16.10 will need to either move to 0.6.4 or backport a handful of patches.

https://github.com/hughsie/fwupd/issues/70

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Graham Mitchell (graham-grahammitchell)]

I'm seeing the same behavior after a reboot. Two fwupd processes consuming 100% CPU each.

[Iain Lane (laney)]

Robert, do you reckon you could look at this?

If it's possible (e.g. with build-dep versions) and acceptable to the SRU team then I would be quite happy with moving to 0.6.8 in yakkety as there are loads of random fixes - it's quite a fast moving project. The problem is that there are new features too and not all the fixes come with LP bug reports of course. But see linked bug report on github - it's a fair point that providing QA on random release + patches is not that fun a task for an upstream to do.

[Robert Ancell (robert-ancell)]

The upstream comments suggest that this is likely fixed in 0.6.6 [1]. This seems like an obvious fix, but I don't know how to reproduce the existing problem.

This change is a general fix to handle invalid YAML files, with a likely cause being using a captive portal (so it returns an HTML page instead of a YAML file).

I'd prefer to try this patch first rather than do a full update to the latest.

[1] https://github.com/hughsie/appstream-glib/commit/538da2d8e078de3ec7f38b56e4ddadd1da401c4d

[Robert Ancell (robert-ancell)]

Can someone who can reproduce this bug try this and see if it works?

[Mathew Hodson (mhodson)]

Fixed in Zesty and later with package appstream-glib 0.6.6-1

---
appstream-glib (0.6.6-1) unstable; urgency=medium

  * New upstream version: 0.6.6
  * scan-metainfo.patch: Scan for data in /usr/share/metainfo
    when composing collection data
  * Update symbols file

 -- Matthias Klumpp <email address hidden> Thu, 22 Dec 2016 20:10:42 +0100