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.
The FuDevice derives from FwupdDevice, and yet both objects have a (potentially
different) parent and set of children. This is super confusing, and just not
required.
Removing the duplication also removes a sizable memory leak when hotplugging
composite devices as the parent was ref'd by the child and the child was ref'd
by the parent in different objects... Fun to debug...
Before:
Information for the update status entry 0:
Information Version: 7
Firmware GUID: {ddc0ee61-e7f0-4e7d-acc5-c070a398838e}
Capsule Flags: 0x00000000x
Hardware Instance: 0
Update Status: attempted
Capsule File Path: /EFI/fedora/fw/fwupd-ddc0ee61-e7f0-4e7d-acc5-c070a398838e.cap
failed: Error opening file /sys/firmware/efi/efivars/fwupd-671d19d0-43c-
4852-98d9-1ce16f9967e4-0-0abba7dc-e516-4167-bbf5-4d9d1c739416: No such file
or directory
failed: Error opening file /sys/firmware/efi/efivars/fwupd-a9971959-9246-
4a5b-b2f2-ba6fdcb19349-0-0abba7dc-e516-4167-bbf5-4d9d1c739416: No such file
or directory
After:
Information for the update status entry 0:
Information Version: 7
Firmware GUID: {ddc0ee61-e7f0-4e7d-acc5-c070a398838e}
Capsule Flags: 0x00000000x
Hardware Instance: 0
Update Status: attempted
Capsule File Path: /EFI/fedora/fw/fwupd-ddc0ee61-e7f0-4e7d-acc5-c070a398838e.cap
Information for the update status entry 1:
Firmware GUID: {671d19d0-d43c-4852-98d9-1ce16f9967e4}
Update Status: No update info found
Information for the update status entry 2:
Firmware GUID: {a9971959-9246-4a5b-b2f2-ba6fdcb19349}
Update Status: No update info found
Fixes https://github.com/fwupd/fwupd/issues/2530
Although hotpluggging PCIe cards isn't common, it's how I'm testing this in the
device test enclosure. Add a tiny delay to wait for the kernel to populate the
net class on hotplug.
Upstream tpm2-tss is moving from ibmswtpm to swtpm as the default TPM
simulator. ibmswtpm still works fine and will be kept around for the
foreseeable future, but adapt to the upstream decision in case ibmswtpm should
ever get dropped from the official Arch Linux repositories (currently there are
no plans to do so).
Unconditionally delete FWUPDATE_VERBOSE and FWUPDATE_DEBUG_LOG when deploying
the update using fwupdtool or fwupd and leave it to fwupdate.
If you want to debug the efi binary you then have to use fwupdate and squirt
the .cap file rather than using all the other layers.
The same plugin name was being added to the device from the quirk file more than
once, and so we enumerated the device *again* and tried to add a duplicate
device -- the device list correctly refusing to do so.
Check the plugin name does not already exist before adding it, and add a self
test to catch this for the future.
The authentication happens earlier in `fu_main_install_with_helper`
so no need to make recursive calls from `fu_main_authorize_install_cb`
into `fu_main_authorize_install_queue`.
Just simplify the code in the non-polkit case.
