Currently the test runs for 100ms and looks to see that at least 8 times
the poll function callback hit.
This normally works well enough, but during self tests it depends upon
too much timing and leads to failures sometimes:
```
** (/<<PKGBUILDDIR>>/obj-s390x-linux-gnu/src/fu-self-test:50432): DEBUG: 15:37:55.189: poll cnt=0
*# DEBUG: poll cnt=1
** (/<<PKGBUILDDIR>>/obj-s390x-linux-gnu/src/fu-self-test:50432): DEBUG: 15:37:55.199: poll cnt=1
*** (/<<PKGBUILDDIR>>/obj-s390x-linux-gnu/src/fu-self-test:50432): DEBUG: 15:37:55.209: poll cnt=2
** (/<<PKGBUILDDIR>>/obj-s390x-linux-gnu/src/fu-self-test:50432): DEBUG: 15:37:55.227: poll cnt=3
*# DEBUG: poll cnt=4
** (/<<PKGBUILDDIR>>/obj-s390x-linux-gnu/src/fu-self-test:50432): DEBUG: 15:37:55.255: poll cnt=4
*# DEBUG: poll cnt=5
** (/<<PKGBUILDDIR>>/obj-s390x-linux-gnu/src/fu-self-test:50432): DEBUG: 15:37:55.267: poll cnt=5
Bail out! ERROR:../src/fu-self-test.c:3489:fu_device_poll_func: assertion failed (cnt >= 8): (6 >= 8)
--- stderr ---
**
ERROR:../src/fu-self-test.c:3489:fu_device_poll_func: assertion failed (cnt >= 8): (6 >= 8)
-------
```
Mark this as a slow test so that it doesn't cause CI failures.
Makes `fwupd-refresh.service` strictly opt-in.
Some distros are defaulting to all systemd services on and causing
more refreshes than desirable by default, especially when using
both `gnome-software` and `fwupd-refresh.service`
It appears to only happen on non-dell systems trying to look up system
ID through `sysinfo_get_dell_system_id`
Other than CI non-dell systems won't be running this code.
Detect and parse current coreboot version.
There's no need to depend on libflashrom for now.
An update mechanism isn't implemented as the kernel interface isn't
stable yet and will be implemented in a separate commit.
Tested on coreboot enabled machine.
Example output:
coreboot System Firmware
DeviceId: 81104bde9db7cb037936659ea727c739f47a5029
Guid: 230c8b18-8d9b-53ec-838b-6cfc0383493a <- main-system-firmware
Guid: de6fd40f-4ec9-5c0b-95e1-8fb13d1b030c <- LENOVO&ThinkPad T410&2537VG5
Guid: 978b0d18-bfe9-5279-9a9f-68dc247a705f <- LENOVO&ThinkPad T410&LENOVO&2537VG5
Summary: Open Source system boot firmware
Plugin: coreboot
Flags: internal|registered
Vendor: LENOVO
Version: 4.10.991
VersionFormat: triplet
Icon: computer
Created: 2019-10-14
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Allow a plugins to cherry-pick specific HWIDs and add them as InstanceIds.
By adding them as InstanceIds rather than adding them as GUIDs, the
original string can be found in the output generated by:
$ fupdmgr get-devices
Example output:
Guid: 230c8b18-8d9b-53ec-838b-6cfc0383493a <- main-system-firmware
Guid: de6fd40f-4ec9-5c0b-95e1-8fb13d1b030c <- LENOVO&ThinkPad T410&2537VG5
Guid: 978b0d18-bfe9-5279-9a9f-68dc247a705f <- LENOVO&ThinkPad T410&LENOVO&2537VG5
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
As the plugin is allowed to change print out the entire FuDevice before
performing each step when in verbose mode.
Note, these are only show during update if run with --verbose, not at startup.
If calling `ch_strerror` with some values returns `NULL` which makes
the `GError` not get populated.
```
0 0x00007f252d64d3bd in fu_colorhug_device_attach (device=0x560d7b5c4520 [FuColorhugDevice], error=0x7ffc57a51040) at ../plugins/colorhug/fu-colorhug-device.c:200
1 0x0000560d7a398279 in fu_device_attach (self=0x560d7b5c4520 [FuColorhugDevice], error=0x7ffc57a51040) at ../src/fu-device.c:1988
2 0x0000560d7a3a4b6c in fu_plugin_device_attach (self=0x560d7b57e160 [FuPlugin], device=0x560d7b5c4520 [FuColorhugDevice], error=0x7ffc57a51040) at ../src/fu-plugin.c:856
3 0x0000560d7a3a553f in fu_plugin_runner_device_generic
(self=0x560d7b57e160 [FuPlugin], device=0x560d7b5c4520 [FuColorhugDevice], symbol_name=0x560d7a3d4258 "fu_plugin_update_attach", device_func=0x560d7a3a4ac1 <fu_plugin_device_attach>, error=0x7ffc57a51040) at ../src/fu-plugin.c:1049
4 0x0000560d7a3a618d in fu_plugin_runner_update_attach (self=0x560d7b57e160 [FuPlugin], device=0x560d7b5c4520 [FuColorhugDevice], error=0x7ffc57a51040) at ../src/fu-plugin.c:1333
5 0x0000560d7a3bcc33 in fu_engine_update
(self=0x560d7b4b9830 [FuEngine], device_id=0x560d7b64f200 "d45c9d222f7eeb3987c6a7674478bc6aec127b3f", blob_fw2=0x560d7b62c0d0, flags=FWUPD_INSTALL_FLAG_NONE, error=0x7ffc57a51150)
at ../src/fu-engine.c:2001
(gdb) print error_local
$1 = (GError_autoptr) 0x0
```
Currently ICL shows up like this:
```
├─Unknown Device:
│ Device ID: d066959bf1b0da600f4fcaab5aa31cab3ff05eee
│ Summary: Unmatched performance for high-speed I/O
│ Current version: 71.00
│ Update Error: Missing non-active nvmem
│ Flags: internal|require-ac|registered
│ GUID: e72e778e-94f7-5ed2-b560-1c1262ee217c
```
Which isn't very useful to end users. Instead show the generic name
`Thunderbolt Controller` which matches the behavior change we've made
in UEFI FW and Touchpad FW items too.
```
├─Thunderbolt Controller:
│ Device ID: d066959bf1b0da600f4fcaab5aa31cab3ff05eee
│ Summary: Unmatched performance for high-speed I/O
│ Current version: 71.00
│ Update Error: Missing non-active nvmem
│ Flags: internal|require-ac|registered
│ GUID: e72e778e-94f7-5ed2-b560-1c1262ee217c
```
Also, quite the messages about missing vid/did as these won't exist
on ICL either.
It turns out there is some bug in systemd v242 or less that runtime
directories can't be used. So only populate motd when we know that
we have a newer systemd
I saw a mention that they're actually CX21986 and had some on hand.
They do enumerate:
```
├─Pixel USB-C earbuds:
│ Device ID: 672c087de09848d9e7ee32aa1dea2fbeb8b81e6b
│ Summary: CX21986 USB audio device
│ Current version: 71.133.20
│ Bootloader Version: 03.01.00.00
│ Vendor: Google (USB:0x18D1)
│ Install Duration: 3 seconds
│ Flags: updatable|registered
│ GUIDs: d76048a5-ca69-5cb8-ac86-d418d70c5f29
│ 98043a29-72c5-549b-ad23-de4e2db20a14
│ 93279fe8-d478-531b-9637-05d026be3c2e
│ 8b71f776-f6d0-549d-9547-42740b24bbbc
```
Don't show output for all devices - it doesn't work for most of them.
I also found that running verify on my Synaptics touchpad device puts it
into a pretty bad state until reboot. That's of course a problem on
it's own, but at least prompting for it will prevent it from easily
happening.
I was seeing on a CML laptop with a Nuvoton TPM the following which
is definitely wrong:
```
Checksum: SHA1(791183aa2c4993dfaf75e95c91bdad067ac2cce1)
Checksum: SHA256(8a0656fe0024cc3300cc4dc8af4fc336112a51013aeb74b21c138ed116bb8691)
Checksum: SHA1(000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000)
```
