For instance, we can tell the user that UEFI UpdateCapsule is disabled in the
system firmware, or that efivarfs is not mounted. This is much better than
creating "dummy" devices which are really just hacks around the problem because
no better API existed. THe dummy devices cause as many problems as they solve.
Plugins have to set FWUPD_PLUGIN_FLAG_USER_WARNING if a warning should be shown
to the user, and only one warning will be shown of each failure type.
It is expected that GUI clients like gnome-software and gnome-firmware would use
this API to notify the user the localized message for why firmware updates are
not being shown.
Fixes https://github.com/fwupd/fwupd/issues/2456
The FWUPD_INSTALL_FLAG_FORCE flag has really unclear semantics, and ignoring a
file CRC, checksum or model ID should only be done when using fwupdtool actually
debugging a plugin or firmware parser.
Use the existing --force flag when we want a "gentle nudge" like reuploading
previously processed reports.
This allows a device to identify with different streams, for instance a Lenovo
laptop could have a coreboot firmware or a AMI firmware. The GUIDs would be the
same, but switching firmware would only be done rarely and very carefully.
Another example would be switching the Broadcom BCM57xx nework adaptors from the
vendor nonfree firmware with a signed PXE image, to the free software reverse
engineered driver with no PXE support (and thus no signed DXE) at all.
It is expected firmware would have additional metadata something like this:
...
<branch>sdcc</branch>
<description>
<p>
This is an alternate firmware built by the community using only free
software tools.
</p>
</description>
<requires>
<id compare="ge" version="1.5.0">org.freedesktop.fwupd</id>
<client>switch-branch</client>
</requires>
...
Additionally, alternate branch firmware will not be returned for clients not
setting the FWUPD_FEATURE_FLAG_SWITCH_BRANCH before the GetReleases request.
This change will allow it to use pkcon over remote-shells (ssh) or
to use it witout a running GUI desktop environment in the background.
Should fix https://github.com/fwupd/fwupd/issues/2429
Only use the history database to tell if activation should be run.
Instead query the connected devices to find the ones needing activation.
This should allow non-connected devices to not cause a failure (although
it might be a longer shutdown).
Also sort the devices, so that the order follows the defined order from
the daemon and they activate in the same order they install.
When one result is obsoleted by another, then do not show the old result by
default.
Additionally hide the HSI URLs as this was designed more for GUI clients like
gnome-firmware than CLI tools such as fwupdmgr.
If a system is configured without any downloadable remotes (e.g. with
a remote pointing to a local directory) the call of
fwupdmgr get-updates
fails by outputting "No remotes enabled." even though the call
"get-remotes" clearly shows the configured remote.
I found the following commit:
commit 991c95697e
Author: Mario Limonciello <mario.limonciello@dell.com>
Date: Wed Jun 17 15:23:13 2020 -0500
trivial: fu-util: correct an assertion when no remotes configured
introduced the problem. In the call chain:
fu_util_get_updates
-> fu_util_perhaps_refresh_remotes
-> fu_util_check_oldest_remote
the function fu_util_check_oldest_remote now returns FALSE if no
remote of kind FWUPD_REMOTE_KIND_DOWNLOAD is found.
The function fu_util_perhaps_refresh_remotes then returns FALSE
indicating failure even though without a downloadable remote the
concept of refreshing is not useful.
I think, we should return TRUE in this case, as no refresh is needed
and the operation can continue.
As the failure of fu_util_check_oldest_remote is ignored we also need
to pass NULL as error pointer here.
The use-case of this scenario without downloadable remote is by
distributing firmware updates through software updates where the
vendor directory with the capsule file is provided.
This takes care of downloading the correct files and allows remotes to be
refreshed from other CLI and GUI tools without copying large chunks of code.
This also allows us to download the metadata without writing two temp files
to the users cache directory. Although not security sensitive, it's probably
not a good idea if we can avoid it.
The logic here is that we can use one central session for all client actions.
Also, set the user agent for the *runtime* version of fwupd -- it's the runtime
version we use when checking capabilities, rather than the built-against
version. This would also explain why there are so many very obsolete versions
of fwupd being recorded on the LVFS...
At the moment we just blindly assume the capabilities of the front-end client
when installing firmware. We can somewhat work around by requiring a new enough
fwupd daemon version, but the client software may be older or just incomplete.
This would allow, for instance, the firmware to specify that it requries the
client to be able to show a detach image. This would not be set by a command
line tool using FwupdClient, but would be set by a GUI client that is capable
of downloading a URL and showing a PNG image.
Clients that do not register features are assumed to be dumb.
The HSI specification assigns a simple text ID to the current state of firmware
security. As new vulnerabilities are found, and as protection measures are
updated, new requirements will be added to the required firmware behaviours for
each HSI value.
The HSI specification is currently incomplete and in active development, and
so the --force flag is required in all command line tools. The current ID value
will probably change on a given platform so please do not start using the result
for any kind of compliance requirements.
This fixes the confusing case where installing the CCGX firmware on a dock
would reboot the hub, leading to this output:
Installing on USB-I2C Bridge… ]
Installing on USB2.0 Hub…[************************************** ]
Installing on USB3.1 Hub…[************************************** ]
Installing on USB2.0 Hub…[************************************** ]
Installing on USB3.1 Hub…[************************************** ]
Installing on ThinkPad USB-C Dock Gen2 USB Audio…*************** ]
Installing on USB-I2C Bridge…*********************************** ]
Restarting device… [***************************************]
With the patch, this is now:
Installing on USB-I2C Bridge… ]
Restarting device… [***************************************]
Switch to downloading the signature first, which we can then load to get the
suffixed build-specific URL of the actual metadata file. You need to have
libjcat 0.1.1 installed and fwupd built against the new version for this to
work.
Fixes https://github.com/fwupd/fwupd/issues/391
This fixes the common problem encountered when developing plugins:
./src/fwupdmgr get-devices
Unsupported daemon version 1.4.0, client version is 1.4.0-179-gcf8095d5
In 1de7cc we checked the version format when checking for update, but there are
many other places that are doing verfmt-insensitive comparisons. For instance,
the predicates in <requires> all fail if the device version format is plain.
his breaks updating some NVMe drives where the `ne` requirements are not
semantic versions.
To avoid trying to catch all the bugs in different places, and in case we have
a future verfmt that should be treated another way, refactor this out in to a
common function and deprecate the old function.
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.
As the motd timer may be activated to run on a system, ensure that
it hasn't actually stepped on the user running an update manually
or another client such as gnome-software refreshing metadtata.
Users can override this behavior with `--force`.
