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.
This information was a predecessor to metadata provided by LVFS with
actual files associated. It's not useful to 99% of the machines it runs
on, and future VIA metadata should come directly with releases on LVFS.
The systemd shutdown script gets called after /snap/fwupd/* gets
unmounted meaning it can't be used to do the activation.
Explicitly check that the symlink for /snap/fwupd/current is mounted
when calling the script.
fu_uefi_get_esp_path_for_os() generates the path to the OS directory
based on "ID" in /etc/os-release, and it may not work for some distros.
Take openSUSE as an example, the "ID" for openSUSE Leap is
"opensuse-leap" and that for openSUSE Tumbleweed is "opensuse-tumbleweed".
However, both of them use the same OS directory in the ESP, i.e.
"/EFI/opensuse".
This commit adds a new build option, efi_os_dir, to allow the packager to
specify the name of OS directory at build time instead of the runtime
detection.
Signed-off-by: Gary Lin <glin@suse.com>
If we update fwupd 'live' rather than from an ostree or offline update then
kill the running instance unless a firmware update is ongoing.
When users update fwupd at runtime they often forget to restart the fwupd daemon
and say that the update didn't fix it when actually they using the the old code.
This is a vestigate of `fwupdtool` originally only being used for
`install-blob`. Now that it can do a local `update` command and
local `install` command, it's important to update the history
database from `fwupdtool` as well.
Older versions of Plymouth are more fragile and we can sometimes block the
offline process waiting for the splash to appear.
Use the new system-upgrade and reboot modes, falling back to older modes if
unavailable, showing text on stderr if Plymouth is either not installed or just
not working.
