Affected drives should have a prominent statement in the update description,
possibly even the first line so it shows up by default in the updates panel.
Microsoft description about the Status is:
The Status field of the BGRT describes whether the image is currently
displayed on the screen. This is not applicable to the firmware update
display capsule.
Many thanks to Steven Chang for identifying this issue.
Fixes: https://github.com/hughsie/fwupd/issues/935
Do not unset the quirks when closing the device, the _NO_DFU_RUNTIME quirk is
needed when re-opening the device during detach.
Fixes https://github.com/hughsie/fwupd/issues/927
On any devices that normally would require checking for AC also
check that at least one battery on the system has at least 30% to
perform an update.
Fixes: #925
Some SKUs of board 4 and later have silicon that will not work with anything
but EC19 or later. So once flashed up to EC19 prohibit downgrades below that
to keep from bricking devices.
This is probably fall out from a previous code re-shuffling.
The EC version is already set elsewhere, and in many cases `self->ec_version`
is `NULL` at this time.
Board 4 was manufactured with package version 89.16.01.00 and this
will prevent properly upgrading between releases. Reset this version
to 00.00.00.00 if detected on this board.
We can't actually access the UEFI ROM from userspace, but the PCR0 is a hash
built from the ROM itself. We could use this value to ensure the firmware has
been written correctly, and that the PCR0 matches the expected value specified
in the metadata.
Future metadata from the LVFS will set the protocol the firmware is expected to
use. As vendors love to re-use common terms like DFU for incompatible protocols,
namespace them with the controlling company ID with an approximate reverse DNS
namespace.
This also allows more than one plugin to define support for the same protocol,
for instance rts54hid+rts54hub and synapticsmst+dell-dock.
This solves issues with implementations that require 4k alignment
of pages in BIOS which is seen on certain architectures.
The UEFI spec prescribes that the "minimum" size is the size of
the EFI header but that this may be increased up to larger sizes
due to extended header entries.
This mirrors the update process over DP aux to run the ESM update
first.
The thought process is as follows:
The "version" displayed doesn't show ESM version, only standard
bank version.
So if the update fails for the ESM then because the update of the
standard happening first it would never be flashed.
`g_ascii_strtoull` returns 0 and sets `errno` to `-EINVAL` only when
the base is invalid. It's hardcoded to `16` so this is impossible.
Reading `-EINVAL` from `errno` is incorrect in these circumstances.
Fixes: https://github.com/hughsie/fwupd/issues/879
This makes startup quicker as we no longer have to probe every USB device, and
is now possible with the new GUIDs we added. Devices not using the
specification-provided values can (and already are) worked around with quirks.
