This produces startup failures on images that do not ship that exact
module, e.g. guest-images.
Just rely on the kernel driver to be auto-loaded when required.
Fixes https://github.com/fwupd/fwupd/issues/4550
This allows us to print better warning strings, and in the future
would allow us to profile each operation in a meaningful way.
Also, add context to some of the progress steps as required.
This allows creating the silo when starting the engine with custom
plugin keys such as WacomI2cFlashBaseAddr.
If we move the plugin initialization earlier then we don't get the
HwID matches, so we really do have to split this into a 4-stage startup,
e.g. ->load(), ->init(), ->startup() and ->coldplug().
Unbelievably, using a filename with spaces causes Lenovo XCC to return a message
with InternalError, 'The request failed due to an internal service error.
The service is still operational.'
As we're using a multipart update rather than a legacy HttpPushUriTargetsBusy
PATCHing, hardcoding should be quite safe.
This fixes the problem when the UEFI update depends on a specific BMC
version -- including the backup BMC device means we checking that both
the primary and the backup were above a specific version.
I don't think it's ever useful to show the backup BMC device, so just
don't include it as an enumerated device.
Fixes https://github.com/fwupd/fwupd/issues/4404
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.
tristate features will automatically disable if dependencies marked
as required are missing.
Packagers can manually override using `auto_features`.
Link: https://mesonbuild.com/Build-options.html#features
At the moment a lot of the failures are only visible when running the
daemon in verbose mode, and the inhibit functionalit provides us a way
to unset FWUPD_DEVICE_FLAG_UPDATABLE from multiple places, as well as
setting the update error for the user to see why.
This leads to reports of:
systemd-modules-load[1710]: Failed to insert 'ipmi_si': No such device
systemd-modules-load.service: Main process exited, code=exited, status=1/FAILURE
Instead of installing the conf file as locked down, set permissions when
using it.
This fixes a problem on snap first run:
```
cp: cannot open '/snap/fwupd/x1/etc/fwupd/redfish.conf' for reading: Permission denied
```
We were calling g_module_symbol() 2703 times, which is actually more
expensive than you'd think.
It also means the plugins are actually what we tell people they are:
A set of vfuncs that get run. The reality before that they were dlsym'd
functions that get called at pretty random times.
During my fwupd startup fu_plugin_has_custom_flag gets called 21 times
which causes all HWIDs to be enumerated with 346 calls to the quite
expensive fu_context_lookup_quirk_by_id() function.
Move the flag to a private hashset and enumerate the HWIDs only during
startup. There's nothing plugin specific about them anyway...
