This leads to madness, as some formats are supersets of the detected types,
e.g. 'intel-me' is detected as 'quad' and 'bcd' is detected as 'pair'.
Where the version format is defined in a specification or hardcoded in the
source use a hardcoded enum value, otherwise use a quirk override.
Additionally, warn if the version does not match the defined version format
Set `UpdateError` in this case, and prevent updates.
If the `VersionFormat` is not known, then the device will later have
problems installing firmware with errors like:
```
failed to get release version: version format unset and version 13000001 ambiguous
```
or
```
Firmware version formats were different, device was '(null)' and release is 'plain'
```
This generally should be corrected by quirking the device.
These are dangerous GUIDs that shouldn't generally be used by any device
for distribution of firmware updates. They'll potentially apply to
devices outside of the vendor they were created for.
Additionally if two USB devices with common interface classes are
on the system, they may lead to one device not being populated by
fwupd.
Fixes https://github.com/hughsie/fwupd/issues/1162
I'm getting a bit fed up with failed reports from arch users where they just
have a broken system. I don't think it's useful to upload to the LVFS or notify
the vendor about failures like this.
This allows several things, for instance:
* Adding or removing blacklisted plugins or devices
* Changing the idle timeout where allowed
...without a user needing to manually modify a configuration file.
This is arguably the more correct fix, regardless of the UEFI quirk use as each
release was reading and converting the exact same property from the component.
Fixes https://github.com/hughsie/fwupd/issues/1156
This allows us to print the daemon-specific properties like VersionFormat when
debugging. The caller can continue to operate on the subclassed FwupdDevice
without changes.
The timeout to wait for the modem after being uninhibited was until
now exclusively to cover the port probing time, because the device
would be already available and ready to be used as soon as the
inhibition was removed.
With the change to include carrier config selection as part of the
fwupd upgrade process, the time to wait for the modem after being
uninhibited should now cover a full reboot of the module, and so the
original timeout of 45s could be a bit tight under some circumstances
(e.g the MM device probing logic is quite slow when there is no SIM
card detected by the module).
We increase this timeout to a much safer value of 120s, which is
extremely long for most cases, but should also be enough to cover even
the worst case scenario.
When we install the MCFG carrier config files with QMI PDC, we were
not explicitly selecting one, and that would end up reporting the
"DF" (default) config is in use. Instead, we should explicitly select
the carrier configuration that we were using before the firmware
upgrade operation.
For example, if the device originally was running with the Vodafone
specific carrier configuration (e.g. T77W968.F1.0.0.3.7.VF.009) and we
trigger the upgrade to the next available firmware associated to
the Vodafone carrier (e.g. T77W968.F1.0.0.3.8.VF.009), we would want
the device to boot with the Vodafone carrier config selected, instead
of booting without any config selected (T77W968.F1.0.0.3.8.DF.009).
This also fixes several upgrade problems detected by fwupd, because it
may end up complaining that the target firmware that was selected to
be installed (e.g. VF variant) is not the one actually reported by the
device after the upgrade (e.g. DF variant).
The selection of which is the config to activate is based on mapping
the mcfg file name with the firmware version reported by the module
before the upgrade. E.g. if the VF variant is reported by the module
(T77W968.F1.0.0.3.7.VF.009), fwupd will look for a MCFG file named
with the "mcfg.VF." prefix.
If the user is trying to install version '20190104' on something with the
existing version '1.2.3' then something has gone wrong. Ensure the device
release version format matches the release version format and fail to apply the
update if this is not true.
In the common case setting the version with fu_device_set_version('1.2.3')
would set the version format to TRIPLET, and setting <release version='1.2.3'>
so no action is required. In cases where the version format could be ambiguous
then the format should be set both in a quirk and also in the metainfo file.
Some firmwares only update one part of the system, e.g. the EC or ME firmware.
Other updates include all the updates needed for the whole system, and vendors
have been doing different things with the component name due to this.
To fix, add an enumerated set of firmware 'categories' that can be set by the
uploader in the metainfo.xml file (or changed the LVFS) which automatically
set the name suffix.
Only append the translated version in the client when <categories> has
not been set, as the LVFS is still operating in compatibility mode and setting
the <name> with the prefix. Add the support to fwupd now so we can switch in
about 9 months time.
