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
In some composite dock hardware there are two USB devices exported to the host,
both with the same VID:PID values. We need to use the device type (e.g. VL812B3)
to differenciate the devices and install the correct fw on the correct device.
In theory, these should always match the reported PCRx values from the TPM.
If the reconstructed event log checksum does not match the TPM value then
something is either implemented wrongly, or something bad has happened.
This means we use half the amount of memory to store the event hashes, and also
means we can process the raw data in future patches without parsing back out
of ASCII format.
This is similar to commit 1ff1164630 ("trivial: debian/control*: Update
for fwupdate transition") but to provide a fwupdate transition in RHEL 8
where the fwupdate{,efi} packages are still present.
There is no need to do this for Fedora, since the fwupdate packages have
already been retired.
UEFI runtime service GetVariable with DataSize NULL, will fail and get
EFI_INVALID_PARAMETER returned. Set DataSize 0 and allocate the buffer for
getting attributes for the deleted variable.
Also, fix the real reason Boot#### was never found.
Fedora doesn't distribute docker anymore, instead
it uses podman for the containers.
It is possible to alias podman to docker, but
it's less hassle if it will work just out of the box.
The fix here is simple the podman is a fallback if
docker is not found.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
RPM doesn't allow '-' in the version number,
so this must be fixed if also when building from
an untagged git tree.
sanitize_for_ci() from get-version.py
fixes it only when build is CI environment.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Synaptics versions are encoded as BCD, the largest version that will
ever be represented in this field is '99'.
Using 3 digits in this field has caused multiple problems in upgrades from
LVFS.
1. Devices are being upgraded when not necessary.
IE `5.3.10 > 5.3.010`
2. Device upgrades are deemed failures as follows:
```
BootTime=1571436076,
CompileVersion(com.redhat.efivar)=37,
CompileVersion(com.redhat.fwupdate)=12,
CompileVersion(org.freedesktop.fwupd)=1.3.2,
CompileVersion(org.freedesktop.gusb)=0.3.0,
CpuArchitecture=x86_64,
DistroId=fedora,
DistroVariant=workstation,
DistroVersion=32,
FirmwareId=1915,
Flags=4194346,
Guid=f15aa55c-9cd5-5942-85ae-a6bf8740b96c,
MachineId=97aa89528b88d9631867a4e20c68a5208124ef592e19d05f0c5e7d22bd4d7afb,
Plugin=synapticsmst,
RuntimeVersion(com.dell.libsmbios)=2.4,
RuntimeVersion(com.redhat.fwupdate)=12,
RuntimeVersion(org.freedesktop.appstream-glib)=0.7.14,
RuntimeVersion(org.freedesktop.fwupd)=1.3.2,
RuntimeVersion(org.kernel)=5.4.0-0.rc2.git2.1.fc32.x86_64,
UpdateError=device version not updated on success, 05.03.10 != 5.03.010,
UpdateState=failed,
VersionNew=05.03.10,
VersionOld=5.03.010
```
Calling 'rmdir --parents /var/cache/fwupdate' will cause it to attempt
to rmdir /var/cache and /var. Those directories are very unlikely to be
empty, so it should always quietly fail. However, there's not benefit
in attempting those removals, so let's quit doing it.
The PEM data is larger than 2kB, which was a crazy-small max size for a
signature. Make this a more respectable 1Mb so that we can load PKCS-7
signatures with full certificate info included.
This wasn't being tested in the self tests as it only affects data read from
the remote file descriptor.
There's no reason to prevent NULL, and doing so means the caller has to check
before setting the value. Only one subclassed type was actually doing this...
This allows it to be refreshed anytime the daemon updates rather
than once a day by a systemd job.
As part of this change, remove the logging from `fwupdmgr` which
was only used for motd purposes.
As the motd timer may be activated to run on a system, ensure that
it hasn't actually stepped on the user running an update manually
or another client such as gnome-software refreshing metadtata.
Users can override this behavior with `--force`.
