Install or downgrade firmware on all devices to make the system match
a well known set. This allows two things:
* Factory recovery where a device in the field has been upgraded
* Ensuring a consistent set of tested firmware for a specific workload
A tag is assigned either during upload or added post-upload on the LVFS
which is included in the metadata. A single firmware can be marked with
multiple tags, and tags can be duplicated for different firmwares.
This functionality broke a number of releases ago as part of
implementing device inhibition and was just noticed now.
Instead of fixing it, the preference seems to be to remove the
functionality as it exists today as inhibitions can happen for
a number of reasons.
To still allow people to override these power warnings (such as during
development) add a new daemon configuration item that can be used.
Fixes: #3778
This allows us to do a few things:
* Remove the runtime dep on Python 3, which is tricky for ChromeOS
* Test composite devices more efficiently, only writing once per test
* Automatically upload signed reports for successful device tests.
We want to provide a lot more in JSON format in the future, and this
will reduce a lot of code duplication.
As various people are using this in the wild, the existing fwupdagent
binary just shims requests to fwupdmgr as required. We'll stop doing
this for 2.0.0 or something.
This can be used like this:
fwupdtool firmware-sign firmware.cab rhughes_signed.pem rhughes.key
Test signing certificates can be generated using the example script here:
https://github.com/hughsie/libjcat/blob/master/contrib/build-certs.py although
these certificates should not be used for enterprise use.
This makes a lot more sense; we can parse a firmware and export the same XML
we would use in a .builder.xml file. This allows us to two two things:
* Check we can round trip from XML -> binary -> XML
* Using a .builder.xml file we can check ->write() is endian safe
Only a small amount of the firmware on the LVFS will be available. The user
can use --ipfs on the command line for testing, or change the system-wide
default in /etc/fwupd/daemon.conf.
The IPFS daemon and command line client will need to be installed manually.
This is really useful when working out HwId quirk values for remote systems.
fwupdtool export-hwids target.hwids
vim target.hwids
fwupdtool hwids target.hwids
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.
Conceptually we were trying to stuff subtly different actions into one vfunc:
* Read firmware from the device to update the verification checksums
* Read a firmware blob from the device for debugging
For the first action we might want to mask out the sections of the flash with
serial numbers (so the verification hashes match the ones published on the LVFS)
and for the second we want just a raw ROM file from the hardware with no
pre-processing that we can compare against an external SPI dumper.
Split out ->dump_firmware to get the raw blob, and allow plugins to also
implement ->read_firmware() if they have to mask out specific offsets or remove
specific images from the FuFirmware container.
In the common case when masking is not required, fall back to using a 'binary'
FuFirmware automatically to make most plugins simpler.
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.
