The root of this problem is that we were trying to use pending.db as both a
pending report store and also a record of history, so you could see updates for
device foo 1.2.3->1.2.4 and then 1.2.4->1.2.5.
This sort-of half worked, but it meant in some cases we matched on the old
device version, sometimes on the new release version and sometimes matching on
either.
The problem was that in various places we were using the device ID as *the*
primary key, and so we had various functions like fu_history_get_device_by_id()
that expected to return just one device, not several.
The device ID also changes if the device is moved from USB plug to another, and
so it got even more complicated again trying to de-dupe the devices.
The sanest thing to do is to decide that pending.db only contains the latest
attempt to go from one version to another using device-id as the primary key.
This makes reporting work reliably now, although has the effect you can't
report a 1.2.3->1.2.4 and 1.2.4->1.2.5 at the same time. Note, if you tried to
do the latter before, the update-error (if set) would be wrong on the second
report...
For the 1.3.3 release make it all simpler and so the reporting works reliably.
Longer term we can design a better database schema that uses unique ID to
represent the *transaction* itself, that isn't tied to the device ID in any way.
This might mean extending the DBus API to cope with multiple devices being
returned with the same device-id set.
It's not usual to open the device from inside the device, otherwise there is a
possibility of a deadlock. For devices without the ->prepare() virtual function
the ->open() should either be a NOP or very fast indeed.
To debug flashing failures it's sometimes requried to get a SPI dump of the
hardware to analysis.
Add a debug-only command that lets us dump the device from the engine.
During startup we do 1898 persistent allocations to load the quirk files, which
equates to ~90kb of RSS. Use libxmlb to create a mmap'able store we can query
with XPath queries at runtime.
This makes the daemon less destructive at startup, especially if the ESP
is not mounted.
It's stored in 3 different places right now, so move it into one point of truth.
Now the ESP is detected when needed including all point of time safety checks and
dynamically mounted and unmounted if necessary.
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.
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.
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.
Fixes a regression in 3d00522dd3 that caused systemd stopping to
not work.
Previously the flow was to use `GetUnit` and `StopUnit` on the manager
interface. In that code this was switched over it should have been
using the unit interface + `Stop` or manager interface + `StopUnit`
not try to use the manager interface on the unit proxy with `StopUnit`.
All of these messages continually output are just noise for unsupported
devices:
```
18:11:52:0851 FuPlugin using generic udev_device_added() on optionrom
18:11:52:0851 FuEngine optionrom ignoring: no FWUPD_GUID property
```
