In this case, a plugin was doing:
g_autoptr(FuDevice) parent = fu_device_get_parent (device);
Which is not valid as it is `(transfer none)` but that shouldn't be enough to
get the daemon to crash. If the FuDevice refcount drops to zero just print
a critical warning with the pointer (no FuDevice details are available) and
remove the FuDeviceItem from the device list.
Using `G_DEBUG=fatal-criticals` it is very easy to backtrace at the right place
and find out which naughty plugin needs to go on the thinking spot.
Doing this unconditionally means we accidentally 'bleed' one device mode into
another in a non-obvious way. For instance, a device might have two operating
modes with different GUIDs. If firmware is supplied for both modes in the same
cabinet archive then we might accidentally match the 'wrong' firmware when
the daemon has observed a mode switch and added the counterpart GUIDs.
We only really need the counterpart GUIDs when switching between Jabra, 8bitdo
and DFU devices where the DFU bootloader VID:PID is not manually tagged with
`CounterpartGuid` in a quirk file. In the general case lets keep it simple to
avoid difficult to find bugs.
This fixes the confusing case where installing the CCGX firmware on a dock
would reboot the hub, leading to this output:
Installing on USB-I2C Bridge… ]
Installing on USB2.0 Hub…[************************************** ]
Installing on USB3.1 Hub…[************************************** ]
Installing on USB2.0 Hub…[************************************** ]
Installing on USB3.1 Hub…[************************************** ]
Installing on ThinkPad USB-C Dock Gen2 USB Audio…*************** ]
Installing on USB-I2C Bridge…*********************************** ]
Restarting device… [***************************************]
With the patch, this is now:
Installing on USB-I2C Bridge… ]
Restarting device… [***************************************]
Rather than return the first device with a matching counterpart GUID, and then
check to see if it was removed -- instead just return any item that matches and
has been removed.
This fixes updating the Logitech unifying receiver when more than one type of
device (e.g. RQR12 and RQR24) are connected.
The README says: "A test suite that can be used to interact with a fake device is installed when configured with `-Ddaemon=true` and `-Dtests=true`", so actually only install these tests when tests are enabled.
Switch to downloading the signature first, which we can then load to get the
suffixed build-specific URL of the actual metadata file. You need to have
libjcat 0.1.1 installed and fwupd built against the new version for this to
work.
Fixes https://github.com/fwupd/fwupd/issues/391
The cleanup action for the FuVliUsbhubPdDevice is correct, but was not
conditionalized in the composite cleanup, which meant we would reboot twice
for a normal USB hub update.
Move the parent reboot into the right place, although this does mean we might
reboot twice in the rare event of scheduing a FuVliUsbhubPdDevice *and*
FuVliUsbhubDevice update in the same transaction -- but resetting the device
state between updates is arguably correct anyway...
From [Lennart’s answer on systemd-devel][1]:
> fwupd.target should not list the various network management solutions,
> that is unnecessary, and ordering after network.target should be
> sufficient to achieve the same, in a generic fashion. i.e. network
> managers should order themselves before network.target, so that
> ordering yourself after that automatically orders you after all
> implementations at once...
So, remove the unneeded targets. As the service unit is not
installed/enabled, and instead called by a timer, the system will most
probably be online already.
[1]: https://lists.freedesktop.org/archives/systemd-devel/2020-March/044205.html
"Best practices for starting unit only if network is online"
We use the ParentGuid quirk key to logically 'tie-together' different discrete
devices into one logical device, for instance making the USB soundcard in a hub
the child of the USB controller on the same PCB.
Setting the discrete child is sometimes correct, for instance when rebooting
the hub, the audio device also goes away -- but it's also sometimes wrong.
If we set the child for a discrete device and the parent does *not* go away
then we get to a situation where the child reference may no longer be valid
if it comes back as a different object.
When we try to remove this no-longer-valid device with the removal timeout the
daemon segfaults. This is realy bad.
Continue to allow using fu_device_add_child() in plugins, where we know the
child lifecycle is is matched by the the parent. In the engine just set the
parent ID directly and let the client use this information to show the tree of
logical devices correctly. There's no benefit to setting up the children as
referenced objects anyway.
