This allows it to be refreshed anytime the daemon updates rather
than once a day by a systemd job.
As part of this change, remove the logging from `fwupdmgr` which
was only used for motd purposes.
Some hardware does not handle upgrading from version 1.2.2 to 1.2.4 and instead
needs to be upgraded from 1.2.2->1.2.3->1.2.4 so that on-device metadata can be
migrated correctly.
Add a new per-device flag `install-all-releases` which causes the daemon to not
skip directly to the newest release. This is designed to be set from a quirk
file.
This can obviously only be used for devices that can apply firmware "live" and
thus do not need a reboot or system shutdown to actually apply the firmware.
This also needs the cabinet archive to ship multiple versions of the firmware,
and for the metainfo.xml file to refer to multiple release objects.
In some CI infrastructures other devices show up and so the webcam
is not automatically picked.
```
Enabling fwupd-tests remote...
Successfully enabled remote
Update the device hash database...
Choose a device:
0. Cancel
1. 08d460be0f1f9f128413f816022a6439e0078018 (Integrated Webcam™)
2. bbbf1ce3d1cf15550c3760b354592040292415bb (Virtio network device)
Request canceled
FAIL: fwupd/fwupdmgr.test (Child process exited with code 2)
SUMMARY: total=1; passed=0; skipped=0; failed=1; user=0.0s; system=0.0s; maxrss=11736
FAIL: fwupd/fwupdmgr.test (Child process exited with code 2)
autopkgtest [22:09:32]: test ci: -----------------------]
ci FAIL non-zero exit status 2
autopkgtest [22:09:33]: test ci: - - - - - - - - - - results - - - - - - - - - -
autopkgtest [22:09:33]: @@@@@@@@@@@@@@@@@@@@ summary
ci FAIL non-zero exit status 2
```
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.
When developing code it's really convenient to only run the new plugin. This
means you don't have to wait for the other hardware to initialize and there
are no side-effects from other plugins when installing firmware.
You can specify multiple plugins as globs, for instance:
fwupdtool get-devices \
--plugin-whitelist wacom \
--plugin-whitelist "thunderbolt*"
In the future the Linux Foundation will be running the LVFS server.
To make this possible, include the Linux Foundation public keys by default as
we already trust them. Obviously the keys need to be available long before
vendors move, so nobody should get too worried at this point.
This means we can avoid loading a ton of non-fwupd files, and reduces our
running RSS from 5.4Mb to 2.8Mb. Old versions of appstream-glib caches a lot of
the localization string data which we just don't care about for firmware files.
The current CDN (~$100/month) is kindly sponsored by Amazon, but that won't
last forever. In the future we can switch to a 'dumb' provider like BunnyCDN
for 1/10th of the cost.
Use a CNAME we control to make switching CDN providers easy in the future.
If this happens:
1.2.3 -> 1.2.4 = failure
1.2.3 -> 1.2.5 = success
...we want to preserve both in the history database so they can both be shared
with the LVFS. Use the device ID and the new and old firmware versions when
modifying and deleting entries.
This fix is made slightly more tricky as we have to drop the PRIMARY KEY
attribute on the device_id, and due to a limitation in SQLite, it means copying
the old history into a new table.
The previous fix (db6ed9ede3) didn't
do a good enough job and autopkgtest was still failing on another
individual test.
This makes sure that stderr will never conflict with autopkgtest
in the future.
The autopkgtest test cases in Debian and Ubuntu are failing due to
output present in stderr.
fwupdmgr behavior however is that it's expected that this test should
show output on stderr for this item.
Rename FuPending to FuHistory to better represent what the object is now doing.
Also, while we're here, switch to using SQLite prepared statements to avoid a
possible invalid read on i386 hardware.
If a remote like LVFS outputs <location>foo.cab</location> without a prepended
hostname and path then we should use the metadata URI hostname and path instead.
This allows us to trivially mirror a firmware repository, although clients using
older versions of libfwupd will not work without this patch. We should encourage
people to use `FirmwareBaseURI` for a long time yet.
