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.
It's currently failing with no changes caused by fwupd.
```
Step 10/16 : RUN pip3 install pillow pygobject
---> Running in 613ba74c32ce
Collecting pillow
Downloading 6b2971adc1/Pillow-6.0.0.tar.gz (29.5MB)
Complete output from command python setup.py egg_info:
running egg_info
creating pip-egg-info/Pillow.egg-info
writing dependency_links to pip-egg-info/Pillow.egg-info/dependency_links.txt
writing top-level names to pip-egg-info/Pillow.egg-info/top_level.txt
writing pip-egg-info/Pillow.egg-info/PKG-INFO
writing manifest file 'pip-egg-info/Pillow.egg-info/SOURCES.txt'
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/tmp/pip-build-6xakdwq1/pillow/setup.py", line 792, in <module>
zip_safe=not (debug_build() or PLATFORM_MINGW), )
File "/usr/lib/python3.4/site-packages/setuptools/__init__.py", line 129, in setup
return distutils.core.setup(**attrs)
File "/usr/lib64/python3.4/distutils/core.py", line 148, in setup
dist.run_commands()
File "/usr/lib64/python3.4/distutils/dist.py", line 955, in run_commands
self.run_command(cmd)
File "/usr/lib64/python3.4/distutils/dist.py", line 974, in run_command
cmd_obj.run()
File "/usr/lib/python3.4/site-packages/setuptools/command/egg_info.py", line 278, in run
self.find_sources()
File "/usr/lib/python3.4/site-packages/setuptools/command/egg_info.py", line 293, in find_sources
mm.run()
File "/usr/lib/python3.4/site-packages/setuptools/command/egg_info.py", line 524, in run
self.add_defaults()
File "/usr/lib/python3.4/site-packages/setuptools/command/egg_info.py", line 560, in add_defaults
sdist.add_defaults(self)
File "/usr/lib/python3.4/site-packages/setuptools/command/py36compat.py", line 36, in add_defaults
self._add_defaults_ext()
File "/usr/lib/python3.4/site-packages/setuptools/command/py36compat.py", line 119, in _add_defaults_ext
build_ext = self.get_finalized_command('build_ext')
File "/usr/lib64/python3.4/distutils/cmd.py", line 299, in get_finalized_command
cmd_obj.ensure_finalized()
File "/usr/lib64/python3.4/distutils/cmd.py", line 107, in ensure_finalized
self.finalize_options()
File "/tmp/pip-build-6xakdwq1/pillow/setup.py", line 268, in finalize_options
if sys.version_info.major >= 3 and not self.parallel:
File "/usr/lib64/python3.4/distutils/cmd.py", line 103, in __getattr__
raise AttributeError(attr)
AttributeError: parallel
----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-6xakdwq1/pillow/
You are using pip version 8.1.2, however version 19.0.3 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
The command '/bin/sh -c pip3 install pillow pygobject' returned a non-zero code: 1
```
If the history database is corrupt or the daemon crashed during the migration
the history object fails to load, which in turn fails the daemon startup.
Rather than leaving the user with a broken system (which also shows UI to that
effect in gnome-software) delete the existing file and start afresh. Nothing
in the history database is that important anyway.
