Some architectures won't have `fwupd-detect-cet` and this causes
build failures for those architectures
Fixes build failures on:
ppc64, risvc64, sparc64, powerpc, m68k, ia64, hppa, alpha, s390x,
mipsel, mips64el, armel
We don't have to do this since we started counting the composite devices out
and back in, and relying on the parent being set at a specific instance seems
fragile in real-world testing.
Per discussion of #2513, Ubuntu Core was going to use UEFI removable
path as default esp path, and it needs to change some parts around
getting the esp path and searching the shim app path. Also, a new option
"FallbacktoRemovablePath" is added into uefi.conf to be applied in this
case, and it will be false by default.
On failure, you get this:
no device found on drm_dp_aux5: Memory query failed: failed to write command
failed to get device after update: failed to wait for detach replug
This is not complete enough for LVFS-usage, but good enough to use with commands
such as fwupdtool. It's likely newer kbd and tp firmware will be required to
integrate with the fwupd in all required ways.
Otherwise we could be left with a device that sets the expected verfmt in the
plugin _init(), but would not be inherited from the subclass. It would have:
Version: 0.2
VersionFormat: triplet
...which makes no sense.
The PCI Vendor and Device ID locations located in firmware were mistakenly
swapped in the bcm5719-fw repository. As a result, the code here based on said
repository also has swapped IDs. This fixes the ids to reflect the
correct locations.
Signed-off-by: Evan Lojewski <github@meklort.com>
The logic here is that the attestation is more than just the PCR0 value, and
multiple device firmware (such as EC, ME, etc.) needs to be included to validate
the system.
By the same logic, updates for the system firmware do not tell the whole story,
and confuse HSI as a specification. Remove them.
The idea for a missing vendor-id would be that the LVFS sets the value
`NEVER_GOING_TO_MATCH` which is shown (along with the correct value) when the
user tries to **install** the firmware.
In 1.5.0 we correctly switched to filtering the devices by GUID and *then*
checking requirements before showing to the user.
In the missing vendor-id case the the poor ODM does not know why the device is
not showing up until they run the daemon in --verbose mode.
Relax the vendor-id checks when adding releases to devices, but of course leave
them in place for installing firmware. The ignore-vid-pid flag is not added
from `Install(a{sv})` and so this stays the same as before.
