This is never set in the AppStream metadata, and means that every call to
fu_engine_ensure_device_supported() at startup does not generate 16x debugs.
For cab archives we know if the archive was unsigned as we show the flags in
the to_string() output.
On my system I get 16 lines of 'device overwriting same name value' for the ME
device. Once we set valid metadata about a device just remove the flag to stop
scanning for every call to fu_engine_ensure_device_supported()
This would also help, for example, to go back to the nonfree firmware when the
alternate firmware did not work as well as hoped. It would also allow flashing
the firmware using an SPI programmer if everything went very wrong indeed.
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
If we wait for the child of a composite device to reappear and *then* go on to
update the replugged parent in the same transaction then we still use the old
GUsbDevice as the add event is still pending when we quit the replug loop.
Just schedule an idle action to quit the loop to allow the child *and* parent
to be added on replug.
Fixes https://github.com/fwupd/fwupd/issues/2376
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.
At the moment there are commands to convert one file format to another, but not
to 'merge' or alter them. Some firmware files are containers which can store
multiple images, each with optional id, idx and addresses.
This would allow us to, for instance, create a DfuSe file with two different
raw files that are flashed to different addresses on the SPI flash. It would
also allow us to create very small complicated container formats for fuzzing.
This can be used by writing a `firmware.builder.xml` file like:
<?xml version="1.0" encoding="UTF-8"?>
<firmware gtype="FuBcm57xxFirmware">
<version>1.2.3</version>
<image>
<version>4.5.6</version>
<id>header</id>
<idx>456</idx>
<addr>0x456</addr>
<filename>header.bin</filename>
</image>
<image>
<version>7.8.9</version>
<id>payload</id>
<idx>789</idx>
<addr>0x789</addr>
<data>aGVsbG8=</data>
</image>
</firmware>
...and then using something like:
# fwupdtool firmware-convert firmware.builder.xml firmware.dfu builder dfu
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.
If the device parent is added using fu_device_add_parent_guid() or ParentGuid
from a quirk file then the child is not returned in fu_device_get_children() by
design as the physical ID will be likely different.
This means we cannot reliably 'depsolve' the order in FuDevice as we need the
full list of devices that might be parents. The existing algorithm had several
logical problems when dealing with more than a single parent and child.
The FuDeviceList object is the right place to do this as it knows about all
added devices on the system.
This means the addition of a logical device causes the root logical device
(and all it's children, and grandchildren) to be re-ordered. This allows
firmware on deeply nested composite devices like hubs to be installed in the
correct order.
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.
When using fwupdtool that runs a mainloop we can get into the state where the
inotify watch fires on the remote directory as we're iterating on the list of
remotes.
This corrupts the list and we start reading freed objects. Return a deep copy
so we can safely update each remote.
This changes allows for downloading firmware from a remote server
pointed from a local remote manifest.xml.gz file
Change-Id: Id00870f9c2817d48d6d301d2b6d229ba1ca6045a
