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.
We've already done the permissions check in the scheduler, and allowing
downgrade allows the user to go back to a working version in the event of a
regression.
This stops us scheduling an update that has FWUPD_DEVICE_FLAG_REQUIRE_AC when
on battery power, as we don't show messages when in the offline updates mode.
Of course, we still check for AC when we reboot, but the common case is where
we reboot into the offline mode just after we schedule the update without
changing the hardware configuration.
