Add various fixes to enable us to build a selection of useful USB plugins.
Also, skip tests that don't make sense on WIN32 or that will not work.
With much help from Mario Limonciello <mario.limonciello@dell.com> -- Thanks!
Recently had a discussion on the expected behavior of calling
`#fwupdmgr update`/`fwupdtool update` with `--allow-reinstall`
in place.
It wasn't working which was confusing to the reporter, but I
feel that flag should only be usable with `install`. Upgrades
are for upgrades and downgrades are for downgrades. Reinstalls are
for reinstall.
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.
-o <arg> will redirect stdout to <arg>, -O <arg> what we want to be
using, it saves the file to <arg>.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
This brings consistency to all fwupd output and allows stuff like
this:
```
No upgrades for Thunderbolt controller in Dell dock, current is 43.00: 40.00=older
No upgrades for Package level of Dell dock, current is 01.00.08.01: 01.00.04.01=older
No upgrades for RTS5413 in Dell dock, current is 01.21: 01.21=same
No upgrades for RTS5487 in Dell dock, current is 01.47: 01.47=same
No upgrades for VMM5331 in Dell dock, current is 05.04.00: 05.03.10=older
No upgrades for WD19TB, current is 01.00.00.02: 01.00.00.00=older
○
└─XPS 13 9380 System Firmware:
│ Device ID: 6c24a747f97668873b761558e322398a91dbf394
│ Current version: 0.1.6.0
│ Minimum Version: 0.1.6.0
│ Vendor: Dell Inc.
│ Flags: internal|updatable|require-ac|supported|registered|needs-reboot
│
└─XPS 13 9380 System Update:
Version: 0.1.7.0
Remote ID: lvfs
Summary: Firmware for the Dell XPS 13 9380
License: proprietary
Size: 0x1563d67
Vendor: Dell Inc.
Flags: is-upgrade
Description: This stable release fixes the following issues:
Fixed the issue where the Dell Power Manager displays an error when a 130W Type-C adapter is connected to the system.
new functionality has also been added:
Added a new feature to automatically suspend BitLocker before upgrading the firmware. After the firmware upgrade is complete, BitLocker is automatically enabled.
```
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`
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.
For my future self, to debug the fwupd.shutdown activation failure, you can do:
mount /dev/sdc1 /mnt
/usr/libexec/fwupd/fwupdtool activate --verbose &> /mnt/log.txt
umount /dev/sdc1
...where /dev/sdc1 is an attached FAT32-formatted USB drive.
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.
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.
In some situations SELinux prevents fwupd from executing tpm2_pcrlist, but the
failure mode is that the process just hangs and never completes. This causes
systemd to time out the fwupd daemon startup and then errors to be shown in
GNOME Software.
To prevent this happening, add an optional timeout argument to
fu_common_spawn_sync() and cancel the subprocess if it takes longer than this
to complete.
See https://bugzilla.redhat.com/show_bug.cgi?id=1665701 for details.
Some distros such as ChromeOS run fwupdtool as a `fwupd` user and open
up permisssions as necessary. The root warning isn't useful for them
to show up in the logs every time the tool runs.
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>
The idea is that if the user should know something about the device update
"after" it's succesfully completed then the plugin can set `UpdateMessage`
for the device and a client can show it.
An example would be a device that doesn't reboot on its own and the user
needs to power cycle it manually.
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.
It's currently a hodge podge of commands that can install files not
always invoking a reboot or shutdown.
Move the actual code into `fu-util-common.c` and make sure that all
`install` and `update` functions call it now.
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.
The libxmlb library is much faster to query, and does not require the daemon
to parse the XML metadata at startup. It's a zero-copy mmap design that is more
modern and less clunky.
RSS has reduced from 3Mb (peak 3.61Mb) to 1Mb (peak 1.07Mb) and the startup
time has gone from 280ms to 250ms.
Commit 171ec0dd95 added this information for 'update' and 'downgrade'
operations in fwupdmgr but forgot to add for the 'install' and 'install-blob'
operations of fwupdtool
With composite CAB files it's difficult to see between devices when packed:
Homepage: http://support.dell.com/
Vendor: Dell Inc.
TrustFlags: none
Unknown Device
Guid: 558d18fa-5530-5fc8-9e4b-de3ee8a5eca7
Homepage: http://support.dell.com/
Vendor: Dell Inc.
TrustFlags: none
Unknown Device
Previously if missing secure boot binaries, or invalid ESP was created the
plugin would just not load.
Now instead populate UpdateError and remove the updateble flag, but still show
the device in fwupdmgr and fwupdtool.
Now we can update multiple devices (in multiple plugins) using one firmware
archive we need a way to cleanup after all the plugins have been run.
Fixes https://github.com/hughsie/fwupd/issues/561
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*"
This is designed to be run as root accessing the hardware directly rather than
using the daemon. This would allow a snap or flatpak package to write firmware
even when the host fwupd daemon is too old.
Also, move the SMBIOS parsing code here as this is not needed in fwupdmgr.
