Future metadata from the LVFS will set the protocol the firmware is expected to
use. As vendors love to re-use common terms like DFU for incompatible protocols,
namespace them with the controlling company ID with an approximate reverse DNS
namespace.
This also allows more than one plugin to define support for the same protocol,
for instance rts54hid+rts54hub and synapticsmst+dell-dock.
Ensure the quirk object is set, and then add the GUIDs first so that the
version format can be set from a quirk file.
Additionally, only overwrite the fallback name if the name has not already been
set manually from a quirk.
Additionally, if the user specified something invalid, do not autodetect the
ESP but return with a journal error. It seems wrong to ignore what the user
explicitly set and perhaps do something dangerous.
Alternative to https://github.com/hughsie/fwupd/pull/599
Previously if missing secure boot binaries, or invalid ESP was created the
plugin would just not load.
Now instead populate UpdateError and remove the updateble flag, but still show
the device in fwupdmgr and fwupdtool.
Check across a list of common EFI system partition locations for a mounted
location before starting fwupd.
This also will cause the plugin to not initialize if the EFI system partition
is not mounted.
If the user is using some super-old kernel or broken system we want to return
early with an error rather than try to catch each way this can fail at runtime.
This pivots the data storage so that the group is used as the preconditon
and the key name is used as the parameter to change. This allows a more natural
data flow, where a new device needs one new group and a few few keys, rather
than multiple groups, each with one key.
This also allows us to remove the key globbing when matching the version format
which is often a source of confusion.
Whilst changing all the quirk files, change the key prefixes to be more familiar
to Windows users (e.g. Hwid -> Smbios, and FuUsbDevice -> DeviceInstanceId)
who have to use the same IDs in Windows Update.
This also allows us to pre-match the desired plugin, rather than calling the
probe() function on each plugin.
Using just the default GUID is fragile and might break if the GUIDs get added
in the 'wrong' order or if the GUID list is sorted.
Fixes https://github.com/hughsie/fwupd/issues/518
Several places in the UEFI plugin operate on the default GUID rather
than iterating a list of GUIDs. This is normally fine since UEFI
GUIDs are tied to the ESRT and normally one FuDevice shouldn't
have multiple GUIDs.
The alternate GUID was added to set parents accordingly but this
caused no CAB files to be able to install.
Fixes: cc664d7d (amt: Put the AMT device as a child under the system UEFI firmware)
This allows plugins to set and explicit build-time version. It also uses the
same AppStream component-ID scheme rather than the home-grown 'FooVersion' key.
Also, use the new runtime and compile-time versions in the report metadata.
Due to the key change we'll also need to update some LVFS rules.
In some cases firmware can only be installed with an up to date GUsb (e.g. with
some STM-DFU hardware) or with a new version of fwupdate (e.g. any UEFI
UpdateCapsule without a capsule header).
We should be able to match against other software versions like we can the
fwupd version, e.g.
<requires>
<id compare="ge" version="0.9.2">org.freedesktop.fwupd</id>
<id compare="ge" version="11">com.redhat.fwupdate</id>
</requires>
Also, rather than checking each requirement we know about on the component,
check each requirement on the component about things we know. This ensures we
don't allow firmware to be installs that requires for instance fwupdate 22 when
the runtime version is only being added in fwupdate 12 and up.
This means the following is now an error that will fail to allow the firmware
to be installed:
<requires>
<firmware>doesnotexist</firmware>
<some_future_tag>also_unknown</some_future_tag>
</requires>
Also add a lot of self tests to test the various new failure modes.
Fixes https://github.com/hughsie/fwupd/issues/463
