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...
We only had to pile everything into the src/fuzzing/firmware directory
because honggfuzz could not cope with more than one input path.
This way each plugin is self contained and easy to copy.
Also, install the fuzzing builder objects as this fixes the installed
tests when srcdir does not exist.
Based on a patch by Jan Tojnar <jtojnar@gmail.com>, many thanks.
This allows us to override the location we load data files from, which
allows us to do more kinds of installed tests in the future.
Also, move the global data/tests content into the place that it is used
as it was getting impossible to manage.
Note that g_assert() should not be used in unit tests, since it is a
no-op when compiling with G_DISABLE_ASSERT. Use g_assert() in production
code, and g_assert_true() in unit tests.
See https://github.com/fwupd/fwupd/issues/3790
It's actually quite hard to build a front-end for fwupd at the moment
as you're never sure when the progress bar is going to zip back to 0%
and start all over again. Some plugins go 0..100% for write, others
go 0..100% for erase, then again for write, then *again* for verify.
By creating a helper object we can easily split up the progress of the
specific task, e.g. write_firmware().
We can encode at the plugin level "the erase takes 50% of the time, the
write takes 40% and the read takes 10%". This means we can have a
progressbar which goes up just once at a consistent speed.
This allows the Redfish plugin to "just work" when there is no username
or password in the SMBIOS data. Using KCS we can create an admin account
from the host OS and then automatically enumerate devices.
More than one person has asked about 'why call fu_plugin_update() for a
reinstall or downgrade' and I didn't have a very good answer.
The plugin API is not officially stable, and we should fix things to be
less confusing. Use the same verbs as the FuDevice vfuncs instead.
We don't want to show the big warning about the missing ESRT on server
hardware that is managed by a BMC:
WARNING: UEFI capsule updates not available or enabled in firmware setup
See https://github.com/fwupd/fwupd/wiki/PluginFlag:capsules-unsupported for more information.
Only the backup BMC device (which we ignore anyway...) can be updated
by specifying the target ID, the others need an *empty* array so that
XCC can work out what devices need to be processed.
Some distributions like RHEL change the default to not autoconnect
ethernet devices. This breaks connecting to the SMBIOS-defined BMC
adapter which means all the reads fail after a 60s timemout.
Autoconnect the internal USB ethernet adapter so we can use Redfish
without user action.
