Sometimes the plugin will want to influence the subclassed device, for instance
by reading a per-plugin config file. At the moment there's no way to do this,
as even _device_registered() is explicitly designed for devices *not* created
by the plugin itself.
Even if _device_registered() was changed to include the plugin creating the
object it would still happen well after the device has done _probe() and/or
_setup() and would probably be too late to do anything useful.
Sometimes it is desirable to create a build environment
outside of docker.
Move dependencies parser to a standalone python script
and call it from generate_docker.py
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
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>
If the device replugs, then we were doing `g_set_object(&device, device_tmp)`
which worked, but had the unfortunate effect of not unwinding properly as
`device` was a function parameter rather than a local variable.
The observed effect using `watch ((GObject*)$1)->ref_count` was the refcount was
double-decremented and thus we got a critical warning on the final valid unref.
Fix this by copying the function parameter to a local variable which we can
then change if the device replugs.
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.
In some hardware there are two identical USB hubs with different firmware.
One is upstream, and one is downstream, making up to 7 user-available ports.
Use the 'removable' bitfield to target the proper firmware to the correct
device, on the logic that the setting will be different on upstream (removable)
and downstream (non-removable, as on the same PCB) hubs.
This reverts commit 44f55e2ee6.
This behavior caused fwupdx64.efi to loop for a very long time until
either aborting, running out of memory or some other problems.
Fixes: #1756Fixes: #1751
