If the measurements are missing but it's a UEFI system, it's a good indication
that the user has secure boot turned off.
Notify the user on the UEFI device through a non-fatal `UpdateMessage`
To accomplish this, move fu-uefi-vars into the plugin library for other plugins to use
If we say that the version format should be the same for the `version_lowest`
and the `version_bootloader` then it does not always make sense to set it at
the same time.
Moving the `version_format` to a standalone first-class property also means it
can be typically be set in the custom device `_init()` function, which means we
don't need to worry about *changing* ther version format as set by the USB and
UDev superclass helpers.
This does 'bleed' the metadata contents into areas previously covered by quirks,
but in this case may be pragmatic and more up to date than a build-time
generated quirk file, which increases the user-friendliness of fwupdmgr.
Some vendors want to ship updates for ATA hardware, but there are currently no
lock-down restrictions in place for these kind of devices.
There is the OUI from the WWN block which is supposed to identify the vendor,
but this is not always set and so we have to be a little creative. We can match
90% of hardware using the vendor name prefix, and the last 10% can be detected
with a heuristic that was the result of comparing over 900 drive models.
I'm not including very old drive models, media converters, raid controllers,
or external 'portable' drives as I don't think it is useful. Also, if the drive
contains a Dell vendor block just hardcode this as Dell rather than trying to
be clever.
Also ask the user to contribute OUI values if this data is found with no quirk
data as this is the only real sane way to manage this data long term.
The list of OUIs can be found here: http://standards-oui.ieee.org/oui.txt
In 1de7cc we checked the version format when checking for update, but there are
many other places that are doing verfmt-insensitive comparisons. For instance,
the predicates in <requires> all fail if the device version format is plain.
his breaks updating some NVMe drives where the `ne` requirements are not
semantic versions.
To avoid trying to catch all the bugs in different places, and in case we have
a future verfmt that should be treated another way, refactor this out in to a
common function and deprecate the old function.
The UEFI ESRT table just gives us a table of GUIDs with some basic flags, and
isn't very useful to end users. This is acceptable for Dell as there is only
typically one ESRT entry, which is for the system firmware. On typical Lenovo
hardware there might be half-a-dozen different 'Device' entries which all look
very similar.
As it's not possible to get a channel-of-data from the ODMs to fwupd, use the
existing LVFS metadata to generate some better names for these devices.
Although this looks like a lot of repeated data, libxmlb helpfully dedupes the
strings for us, making the quirk store only slightly larger.
Also, I've deliberately made this a manual step as we're not going to have
internet access on distro builders, and I'd also like the fwupd tarball output
to be deterministic and repeatable.
Currently if there is an invalid boot entry for firmware update, the fwupd
EFI program will not call UpdateCapsule(), even if there is a valid entry.
For example, if the following entries exist the firmware update will fail:
HD(1,GPT,A672BBCA-325E-4D6F-91E1-DD57FAA85A9C)/\EFI\rhel\fw\fwupdate-6cialq.cap ... /*Valid entry*/
HD(1,GPT,E8176B29-6F73-43F2-AE8E-05E09DE20EE5)/\EFI\fedora\fw\fwupd-6dcbd5ed-e82d-4c44-bda1-7194199ad92a.cap ... /*InValid entry*/
Ensure capsule update is happening even if a valid capsule entry exists.
Signed-off-by: Bhaskar Upadhaya <bupadhaya@marvell.com>
Some logitech devices seem to reboot immediately and the failures then
look like a broken pipe, but are actually the device rebooting.
If the device really did fail to detach after the timeout is done we'll
see a message that the device failed to come back instead.
Deleting boot entries from EFI sometimes triggers problems on some firmware.
We don't actually need to do it from the EFI binary, and it's perfectly safe to
leave it in the boot list. It also means when doing multiple updates over
several months we're not creating, deleting, creating, deleting and can just
re-use the same BootXXXX number each time.
It also makes the EFI binary simpler, which is good.
At the moment fwupd creates a BootXXXX for fwupd.efi and marks it BootNext.
It *also* adds it to the end of BootOrder to work around various old firmware
bugs like https://github.com/rhboot/fwupdate/issues/55 which we can perhaps
drop sometime thie century.
Remove the rewriting of BootOrder from the EFI binary; we've accidentally not
been doing it for a long time and nothing broke, and I'd like to make the EFI
binary as small and simple as possible. The user can remove the entry from the
BIOS or using efibootmgr if required, but it's harmless to just leave it.
