This allows a device subclass to call the parent method after doing an initial
action, or even deliberately not call the *generic* parent method at all.
It also simplifies the plugins; you no longer have to remember what the plugin
is deriving from and accidentally clobber the wrong superclass method.
Otherwise the following build error happens:
../fwupd-1.5.6/plugins/system76-launch/fu-system76-launch-device.c:117:9: error: ‘G_USB_DEVICE_CLAIM_INTERFACE_BIND_KERNEL_DRIVER’ undeclared (first use in this function)
117 | G_USB_DEVICE_CLAIM_INTERFACE_BIND_KERNEL_DRIVER,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../fwupd-1.5.6/plugins/system76-launch/fu-system76-launch-device.c:133:11: error: ‘G_USB_DEVICE_CLAIM_INTERFACE_BIND_KERNEL_DRIVER’ undeclared (first use in this function)
133 | G_USB_DEVICE_CLAIM_INTERFACE_BIND_KERNEL_DRIVER,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Two reasons:
* It seems a bit antisocial to hard-require all this data without fair warning
* The aarch64 pesign crashes when trying to sign the binary with SBAT metadata
fu_udev_device_ioctl() interprets the return value of ioctl() as the
error cause and generates a misleading error message (permission
denied).
Fix it to use errno for error checking and reporting.
We happily fallback with an unset -Defi_os_dir and it gets confusing explaining
why the EFI dir needs to be set on a non-supported system.
In practice they'll probably have the same eventual value on most supported
distributions.
Fixes https://github.com/fwupd/fwupd/issues/2873
The objcopy tool only has support for pei-x86_64 and pei-i386 targets, and
so trying to add a .sbat section for fwupdaa64.efi fails with this error:
objcopy: plugins/uefi-capsule/efi/fwupdaa64.efi: file format not recognized
To fix this issue, add the .sbat section to the ELF fwup.so shared object
and keep that section when generating the resulting fwupdaa64.efi binary.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
