To debug flashing failures it's sometimes requried to get a SPI dump of the
hardware to analysis.
Add a debug-only command that lets us dump the device from the engine.
During startup we do 1898 persistent allocations to load the quirk files, which
equates to ~90kb of RSS. Use libxmlb to create a mmap'able store we can query
with XPath queries at runtime.
Makes `fwupd-refresh.service` strictly opt-in.
Some distros are defaulting to all systemd services on and causing
more refreshes than desirable by default, especially when using
both `gnome-software` and `fwupd-refresh.service`
It turns out there is some bug in systemd v242 or less that runtime
directories can't be used. So only populate motd when we know that
we have a newer systemd
`fwupd-refresh.service` uses `DynamicUser=true` which causes systemd
to make `/var/cache/fwupd` a symlink to `/var/cache/private/fwupd`.
Individual units aren't allowed to access this directory, only the ones
with the directive. This means that `fwupd.service` stops working as
soon as a user tries to start `fwupd-refresh.service`.
The bug details are present in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941360
This allows us to easily build just libfwupd in a flatpak manifest without
installing dozens of deps to build things we're just going to delete anyway.
Mostly for consistency purpose. Details:
* It's confusing that internally the functions for `FwupdClient` use
`upgrade` in the name.
* The logical antonym of `downgrade` is `upgrade` not `update`
* People who don't use the tool frequently may try `get-upgrades`
Fixes Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921820
Introduce a new --log option to fwupdmgr that will log stdout to an argument.
If run under systemd, prefix that argument with $RUNTIME_DIRECTORY.
Add a new systemd unit and associated timer to regularly refresh metadata.
After the metadata refresh is complete, save the output to the motd location.
The timer and service are disabled by default and can be enabled by an admin.
In many plugins we've wanted to use ->prepare_firmware() to parse the firmware
ahead of ->detach() and ->write_firmware() but this has the limitation that it
can only return a single blob of data.
For many devices, multiple binary blobs are required from one parsed image,
for instance providing signatures, config and data blobs that have to be pushed
to the device in different way.
This also means we parse the firmware *before* we ask the user to detach.
Break the internal FuDevice API to support these firmware types as they become
more popular.
This also allows us to move the Intel HEX and SREC parsing out of the dfu plugin
as they are used by a few plugins now, and resolving symbols between plugins
isn't exactly awesome.
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 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 offline updates environment is special, and we have to be careful to delete
the trigger before doing anything that can fail to avoid boot loops.
For this reason, split it out to a simple self-contained binary that is easy to
understand.
If another offline update task is run at the same time, e.g. pk-offline-update
from PackageKit then we might corrupt the package database when the client
D-Bus request times out.
Copy the fixes from PackageKit so that the offline updates work together.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1685471
This currently just outputs the current list of devices with releases and makes
it possible to integrate firmware version reporting with other tools like mgmt.
This feature is turned on with the new fwupdtool option `--enable-json-state`
The intended use case is for ChromeOS to be able to save information about
devices on the system when `fwupdtool update` was run to display in the UX at
a later time.
The following warnings were displayed by Debian appstream metadata
validation.
```
metainfo-validation-issue
Validation of the metainfo file found a problem: Found empty 'url' tag.
metainfo-validation-issue
Validation of the metainfo file found a problem: Type 'console-application' component, but no information about binaries in $PATH was provided via a provides/binary tag.
metainfo-validation-issue
Validation of the metainfo file found a problem: Found empty 'url' tag.
```
This is intended for devices that it is not safe to immediately activate
the firmware. It may be called at a more convenient time instead.
Both fwupdmgr and fwupdtool support the feature.
- if called at runtime with fwupdmgr it uses the daemon
- during shutdown fwupdtool uses the pending.db to perform this feature.
For this we need to register as a console application (which fwupdtool is, I
suppose) and also supply a usable icon.
I've used the new GNOME icon theme guidelines so please add a drop shadow
before using: https://gitlab.gnome.org/GNOME/Initiatives/issues/2
Two new arguments added to fwupdtool: `--prepare` and `--cleanup`
They are used only with the `install-blob` command
This makes sure that devices can get rebooted in dell-dock even if using
fwupdtool to install a single blob.
Signed-off-by: Richard Hughes <richard@hughsie.com>
Now that there is actually support to load non-static information
(at least from fwupd perspective) it makes sense to support this
command in both tools.
This will perform updates with all currently present metadata.
It is "intended" for usage with local metadata repositories referring
to local files.
fwupdtool however does also support fetching a file from the web
and if the metadata refers to the file on the web it should also work
for that.
Plugins are allowed to 'opt-out' of this behaviour using _RULE_INHIBITS_IDLE.
This should be used where waking up the hardware to coldplug is expensive,
either from a power consumption point of view, or if other artifacts are going
to be seem -- for instance if the screen flickers when probing display devices.
This functionality is also inhibited when the actual upgrade is happening,
for obvious reasons.
Admins can turn off this auto-sleep behaviour by editing the daemon.conf file.
Fixes https://github.com/hughsie/fwupd/issues/417
This matches what a lot of other projects do, and means we can easily format
the release notes back into NEWS format, but also into HTML and Markdown.
This also means we can show the correct update description in gnome-software
when building a flatpak, rather than falling back to the generic project
description.
This allows us to match non-DeviceID GUIDs, and also GUIDs we don't know how to
generate.
To make this fully useful, search for device quirks when GUIDs are added.
/boot is a special cased directory when using ProtectSystem=full
Due to this, it's marked read only even if it's listed in ReadWritePaths.
Allow folks to use this for their ESP, but they need to create /boot/EFI
in advance of starting fwupd.
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.
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.
Requiring colord to be built before fwupd makes it hard to build packages.
The HID-based flashing protocol is stable and documented, so there's no need
to use an external library for this now.
