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.
This allows us to do three things:
* Fuzz the loader with `fwupdtool firmware-parse`
* Check the firmware *before* the hardware is put into bootloader mode
* Use FuChunk to build the 32 byte payload chunks
Systems with multiple host controllers will most likely have a different
NVM image for each controller but there is no guarantee that the device_id
within the NVM image varies from one controller to another.
To account for this, build a GUID that contains the last element of the
Thunderbolt controller's udev path.
Sample GUID strings from an XPS 9380 (which only contains one host controller):
```
Guid: 0f401ed2-b847-532a-adc8-3193fc737be6 <- TBT-00d408af-native
Guid: 420b0596-f5cb-5fd7-8416-c99d48ad8de9 <- TBT-00d408af-native-0000:05:00.0
```
This commit follows the presumption that the kernel will enumerate the controllers
in the same order every time.
This also lets us remove the call to dfu_device_wait_for_replug() which was
causing a deadlock due to unsafe main context usage. Splitting the code allows
us to use the device list to watch for replug, without adding even more Jabra-
specific plugin code to the DFU plugin.
Looking at this with a 40,000ft view, the Jabra runtime really doesn't have
much in common with DFU and the reason it was originally all lumped together
was that the daemon couldn't "change" plugins between detach and update.
It's unfortunate that we have to include a sleep() in the DFU code after the
DFU probe, but this is specified by Jabra themselves. Attempting to open the
device without waiting reboots the hub back into runtime firmware mode, so we
can't even retry the failing setup action.
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.
We can't use the IOTA mechanism in bootloader mode, and failing to create the
FuSynapromDevice object means we can't recover the hardware if the flash failed.
Some devices don't set the CAN_DOWNLOAD attribute in their runtime descriptor.
Rather than quirk these devices just assume that all DFU devices with a DFU
interface can download in DFU mode. The logic being, why would they expose a
runtime DFU interface if they can't download new firmware in DFU mode...
Devices like the DW1820A that are currently blacklisted because of broken DFU
support will remain blocked with this change.
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.
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.
