The baseclass is calling fu_device_build_instance_id_quirk() and when we
incorporate the device we were only copying the 'proper' instance IDs and not
the ones used for quirk matching -- which we need to match the devices that use
keys containing MODALIAS for the Plugin key to be set.
This does not serve much purpose now, but would be useful if we need to know
more about the installed PK from other plugins. If nothing else it makes the
`--verbose` output more helpful.
This allows the backend to identify the specific device for a specific phase.
For instance, there might be a pre-update runtime, a bootloader and a
post-update runtime and allowing tags to be saved to the backend object allows
us to identify each version of the same physical device.
This takes us one step closer to emulating a complete byte-perfect end-to-end
update without actual hardware installed.
Semantically it is the desire of the security attribute, not the bios
attribute, i.e. you could imagine that a specific attribute would have
to be *foo or bar or baz* for HSI-1 and *only foo* for HSI-2
Also make it easier to add possible BIOS attribute target values in
plugin code.
We want to allow all the device hotplug events to be processed before
marking the update as completed. Otherwise, we might have a situation
where we have a child device attached to a parent, where we want to
update the parent, then the child. e.g.
1. Add parent
2. Add child
3. Update parent
4. Attach parent
5. Wait for parent
...some time passes...
6. Parent re-appears
7. Update finishes, client indicates success
...child update is scheduled...
...which returns with failure as it does not exist...
8. Add child
The child should have been added *before* the update completed to avoid
the caller from needing an unspecified delay as a *workaround*.
This allows us to load sets of different host security attributes
for testing the various front end tools we have now. e.g.
sudo FWUPD_HOST_EMULATE=thinkpad-p1-iommu.json.gz fwupd
or, using a non-compressed absolute path:
sudo FWUPD_HOST_EMULATE=/tmp/test/thinkpad-p1-iommu.json fwupd
Data can be created with `./contrib/generate-emulation.py file.json`
and then can be manually modified if required. Running the script on
a file that already exists will just strip out any unneeded data, as
well as piping content into it using stdin.
As a precaution, the org.fwupd.hsi.HostEmulation attribute is added
so we do not ask the user to upload the HSI report. It also allows
the LVFS to ignore any HSI reports with this attribute for clients
that upload HSI reports regardless.
See https://github.com/fwupd/fwupd/discussions/4832
Only opt-in plugins that have been tested -- unconditionally enabling
this may cause regressions on devices like docks.
Fixes https://github.com/fwupd/fwupd/issues/4378
This allows us to make smarter policy decisions in the future on when
to show unavailable updates. It also means we can show translated
text in the frond-end clients.
Only problems the user can "fix" are enumerated. For example, opening
the laptop lid, or charging the device battery.
Allow the admin to override the inhibit(s) on devices using a similar
format to the other kvs. For instance, setting two different quirks and
clearing another could be done using:
Quirk = usb-blocked:Device defective,needs-reboot:Reboot system,not-authorized:
This also allows unsetting the quirk, which was impossible before as
`@value` was always non-NULL.
Some plugins were creating local versions (which were not attached to
the daemon progress in any way) as a workaround as they needed to do
actions that took a long time to complete.
Provide a device instance builder that allows plugins to easily
create multiple instance IDs based on parent attributes.
Also fix a lot of the instance ID orders, so that we add more generic
IDs first, and more specific IDs after.
