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
The guint16 was promoted to (signed) int for the multiplication, which meant
that the highest address possible was 0x7FFFFFFF not 0xFFFFFFFF. Which doesn't
really matter in reality, as all addresses are much smaller than that now.
This matches the optional other lines that show updates.
Current experience:
```
Welcome to Ubuntu Focal Fossa (development branch) (GNU/Linux 5.4.0-12-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
* Multipass 1.0 is out! Get Ubuntu VMs on demand on your Linux, Windows or
Mac. Supports cloud-init for fast, local, cloud devops simulation.
https://multipass.run/
1 device has a firmware upgrade available.
Run `fwupdmgr get-upgrades` for more information.
10 updates can be installed immediately.
0 of these updates are security updates.
To see these additional updates run: apt list --upgradable
Last login: Thu Jan 16 21:00:01 2020 from 127.0.0.1
```
Updated experience:
```
Welcome to Ubuntu Focal Fossa (development branch) (GNU/Linux 5.4.0-12-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
* Multipass 1.0 is out! Get Ubuntu VMs on demand on your Linux, Windows or
Mac. Supports cloud-init for fast, local, cloud devops simulation.
https://multipass.run/
1 device has a firmware upgrade available.
Run `fwupdmgr get-upgrades` for more information.
10 updates can be installed immediately.
0 of these updates are security updates.
To see these additional updates run: apt list --upgradable
Last login: Thu Feb 6 16:29:12 2020 from 127.0.0.1
```
gnu-efi 3.0.11 moves a few files around, e.g.
/usr/lib64/gnuefi/elf_x64_efi.lds -> /usr/lib64/gnuefi/x64/efi.lds
...and this causes the UEFI EFI helper to fail to link.
Add support for the 'new' paths and fall back to the old ones.
Fixes https://github.com/fwupd/fwupd/issues/1736
