Updating firware is sometimes scary, and for user-facing CLI tools we ought to
show some kind of reassurance than it went well.
Fixes some of https://github.com/fwupd/fwupd/issues/1409
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`
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.
Normally the flag 'supported' is used to indicate that devices can
update from a remote such as LVFS.
Running `#fwupdmgr get-updates` in this situation will show a message
for each device that is already up to date as well as messages for
devices that have updates available.
If no devices contain the supported flag, `# fwupdmgr get-updates`
will show no output, which is confusing to some people.
Show "No updatable devices" instead for those situations.
Unexpected behaviors can happen if:
* a snapped daemon is running with a packaged frontend
* a packaged daemon is running with a snapped frontend
This should make sure that if the snap is installed on top of a
packaged frontend that people don't try to mix and match as much.
The lines are almost impossible to read as they are not wrapped and not
delimited from the normal script output. Add a box around to make them stand out:
╔══════════════════════════════════════════════════════════════════════════════╗
║ The LVFS is a free service that operates as an independent legal entity and ║
║ has no connection with Fedora. Your distributor may not have verified any ║
║ of the firmware updates for compatibility with your system or connected ║
║ devices. All firmware is provided only by the original equipment ║
║ manufacturer. ║
║ ║
║ Enabling this functionality is done at your own risk, which means you have ║
║ to contact your original equipment manufacturer regarding any problems ║
║ caused by these updates. Only problems with the update process itself ║
║ should be filed at https://bugzilla.redhat.com/. ║
║ ║
╚══════════════════════════════════════════════════════════════════════════════╝
Agree and enable the remote? [Y|n]:
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.
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.
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.
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.
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.
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.
