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.
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>
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.
It's possible that someone has removed fwupdate package prior to the
fwupd transition meaning that they might have some artifacts left
behind from fwupdate packaging. Clean up these artifacts.
This commit can be reverted after both Debian bullseye and Ubuntu
focal have been released.
Add various fixes to enable us to build a selection of useful USB plugins.
Also, skip tests that don't make sense on WIN32 or that will not work.
With much help from Mario Limonciello <mario.limonciello@dell.com> -- Thanks!
This splits out all development files, including headers into their
own packages where relevant.
Notably absent is `fu-hash.h` which is used for determining taint.
Out of tree developed plugins should still taint the daemon.
This is inspired by a change in flashrom to read the version string for meson
dynamically.
No need for "post release version bump", this happens automatically from git
now by there being a dirty commit.
This script re-uses code from existing firmware-packager related items
to:
* Find the matching device on the system
* Append an ESRT header
* Build a CAB file
* Pass the CAB file into fwupd daemon
This also lets us remove the call to dfu_device_wait_for_replug() which was
causing a deadlock due to unsafe main context usage. Splitting the code allows
us to use the device list to watch for replug, without adding even more Jabra-
specific plugin code to the DFU plugin.
Looking at this with a 40,000ft view, the Jabra runtime really doesn't have
much in common with DFU and the reason it was originally all lumped together
was that the daemon couldn't "change" plugins between detach and update.
It's unfortunate that we have to include a sleep() in the DFU code after the
DFU probe, but this is specified by Jabra themselves. Attempting to open the
device without waiting reboots the hub back into runtime firmware mode, so we
can't even retry the failing setup action.
During startup we do 1898 persistent allocations to load the quirk files, which
equates to ~90kb of RSS. Use libxmlb to create a mmap'able store we can query
with XPath queries at runtime.
Makes `fwupd-refresh.service` strictly opt-in.
Some distros are defaulting to all systemd services on and causing
more refreshes than desirable by default, especially when using
both `gnome-software` and `fwupd-refresh.service`
Detect and parse current coreboot version.
There's no need to depend on libflashrom for now.
An update mechanism isn't implemented as the kernel interface isn't
stable yet and will be implemented in a separate commit.
Tested on coreboot enabled machine.
Example output:
coreboot System Firmware
DeviceId: 81104bde9db7cb037936659ea727c739f47a5029
Guid: 230c8b18-8d9b-53ec-838b-6cfc0383493a <- main-system-firmware
Guid: de6fd40f-4ec9-5c0b-95e1-8fb13d1b030c <- LENOVO&ThinkPad T410&2537VG5
Guid: 978b0d18-bfe9-5279-9a9f-68dc247a705f <- LENOVO&ThinkPad T410&LENOVO&2537VG5
Summary: Open Source system boot firmware
Plugin: coreboot
Flags: internal|registered
Vendor: LENOVO
Version: 4.10.991
VersionFormat: triplet
Icon: computer
Created: 2019-10-14
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
The new plugin is called `optionrom` as this is the only type of image that it
parses for verification only. FuUdevDevice is also the generic parent already.
`fwupd-refresh.service` uses `DynamicUser=true` which causes systemd
to make `/var/cache/fwupd` a symlink to `/var/cache/private/fwupd`.
Individual units aren't allowed to access this directory, only the ones
with the directive. This means that `fwupd.service` stops working as
soon as a user tries to start `fwupd-refresh.service`.
The bug details are present in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941360
The factory-shipped MinnowBoardMAX board has firmware that does not include
the ESRT table. Create a 'fake' UEFI device with the lowest possible version
so that it can be updated to any version firmware.
All the HwId GUIDs are used for the fake UEFI device, and so should be used in
the firmware metadata for releases that should recover the system.
- Moved version discovery routine to PKGBUILD
- Set PKGEXT to .pkg.tar to avoid the package being compressed
- Added --needed to pacman arguments when installing the dependencies to
avoid reinstalling packages
Signed-off-by: Filipe Laíns <lains@archlinux.org>
There are commits to the Thunderbolt kernel driver that make sure
that the upgrade process goes smoothly. If these commits aren't
present then it will look like a fwupd problem, when it's actually
a kernel problem.
When this issue was reported it appeared that commit
e4be8c9b6a
was missing from the locally tested kernel, but it's impossible
to determine that from userspace.
Prevent running the thunderbolt plugin on older kernels than that
set in `$sysconfdir/fwupd/thunderbolt.conf`.
By default that is set to 4.13.0, but if a distribution vendor has
backported all the necessary support it can be decreased to a lower
version for distro packages.
The test is run if a physical TPM is available or if the environment
variable "TPM_SERVER_RUNNING" is set. In the latter case, the user is
expected to start a TPM simulator on their own, like we do in the Arch
Linux CI script here.
Using the library instead of the command line tools provides a more
stable interface. This implementation only fetches PCR 0 for all
available hash algorithms since this is the only PCR that is actually
used in fwupd.
Since https://fwupd.github.io is now a thing, people can be directed there
rather than relying upon locally built documentation by default.
Also this will mean one less dependency to install for people who build
from source.
Lastly this finally means that I can do this set of actions without failure:
```
meson build
ninja -C build
ninja -C build install (PK prompts for password)
rm -rf build
```
Previously gtkdoc stuff was built as root due to the PK prompt and removing
it would lead to stuff like this:
```
rm: cannot remove 'build/docs/libfwupd/html/libfwupd-FwupdClient.html': Permission denied
```
For now this is happening on every master build, but in the future
after it's working reliably it should be restricted to only tagged
builds.
To accomplish this, swap a build from circlei and travisci that
will save docs to publish.
Fixes Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921820
Introduce a new --log option to fwupdmgr that will log stdout to an argument.
If run under systemd, prefix that argument with $RUNTIME_DIRECTORY.
Add a new systemd unit and associated timer to regularly refresh metadata.
After the metadata refresh is complete, save the output to the motd location.
The timer and service are disabled by default and can be enabled by an admin.
This adds a script which can check for ABI breaks between two Git
revisions:
$ ./contrib/ci/check-abi.sh
The CI is set up to run it automatically between the tip of the branch
being tested and the last release tag.
Based on the work by Mathieu Bridon <bochecha@daitauha.fr>, many thanks.
On Fedora 30 x86_64 I got:
docker run --privileged -t -v `pwd`:/build fwupd-fedora
...
Complete!
+ cp /root/rpmbuild/RPMS/noarch/fwupd-tests-1.2.10-0.1alpha.fc29.noarch.rpm /root/rpmbuild/RPMS/x86_64/fwupd-1.2.10-0.1alpha.fc29.x86_64.rpm /root/rpmbuild/RPMS/x86_64/fwupd-debuginfo-1.2.10-0.1alpha.fc29.x86_64.rpm /root/rpmbuild/RPMS/x86_64/fwupd-debugsource-1.2.10-0.1alpha.fc29.x86_64.rpm /root/rpmbuild/RPMS/x86_64/fwupd-devel-1.2.10-0.1alpha.fc29.x86_64.rpm dist
cp: target 'dist' is not a directory
This also means we now include a flashrom subproject as no distro currently has
a flashrom new enough to build the plugin.
Signed-off-by: Richard Hughes <richard@hughsie.com>
Signed-off-by: Artur Raglis <artur.raglis@3mdeb.com>
Signed-off-by: Maciej Pijanowski <maciej.pijanowski@3mdeb.com>
Allow setting a minimum fwupd version requirement using `--minimum`.
If running on a distro with apt, try to use this to detect an already
installed version and compare what was passed in to `--minimum`.
* If new enough version, use the built in version
* If too old of a version or not specified, require package removal.
The systemd shutdown script gets called after /snap/fwupd/* gets
unmounted meaning it can't be used to do the activation.
Explicitly check that the symlink for /snap/fwupd/current is mounted
when calling the script.
* Move all the data under a new top-level "packages" key
* Add an empty "trusted_certs" key - our binaries do not do any
further verification with an embedded key.
The offline updates environment is special, and we have to be careful to delete
the trigger before doing anything that can fail to avoid boot loops.
For this reason, split it out to a simple self-contained binary that is easy to
understand.
This currently just outputs the current list of devices with releases and makes
it possible to integrate firmware version reporting with other tools like mgmt.
If a device reports that qmi-pdc is supported (e.g. DW5821e that
supports both fastboot and qmi-pdc), we'll end up first running the
fastboot installation before doing the qmi-pdc installation procedure.
These changes also make sure that the MM device inhibition is kept for
as long as the whole process is ongoing. Only after the last method is
run, the inhibition will be removed.
In order to handle devices being exposed in the system while the MM
inhibition is in place, e.g. to be able to run qmi-pdc after fastboot,
a simple udev based watcher is included, which will take care of
creating the FuMmDevice that is not associated to any modem currently
exposed by MM, but that shares all the details of the original device.
This new logic assumes that the devices don't change their USB layout
during a firmware upgrade, which is not a very good assumption, but it
works for the case at hand. If this is not the case, we may need to
end up doing some custom AT port probing instead of relying on the
original one reported by MM being still valid (note that we don't rely
on the device name, as that may change if some other device is plugged
in the system while we're doing the update, we rely on the USB
interface number).
This is intended for devices that it is not safe to immediately activate
the firmware. It may be called at a more convenient time instead.
Both fwupdmgr and fwupdtool support the feature.
- if called at runtime with fwupdmgr it uses the daemon
- during shutdown fwupdtool uses the pending.db to perform this feature.
For this we need to register as a console application (which fwupdtool is, I
suppose) and also supply a usable icon.
I've used the new GNOME icon theme guidelines so please add a drop shadow
before using: https://gitlab.gnome.org/GNOME/Initiatives/issues/2
The snap build uses xmlb as a subproject. libxmlb actually does
need the uuid-dev dependency.
Resolves this failure:
```
Couldn't use fallback subproject in subprojects/libxmlb for the dependency xmlb
Reason: subprojects/libxmlb/meson.build:107: Native dependency 'uuid' not found
meson.build:158:0: ERROR: Native dependency 'xmlb' not found
```
fwupd installs by default firmware-packager (a python3 script) into
the CrOS image. CrOS does not support python3 interpreter and fails
passing the TestValidInterpreter. Removing this script from the default
installation fixes the issue.
TEST=emerge-sarien fwupd
BUG=chromium:857263,b/121131967
Change-Id: I855c7994fd15faa0ce3d520734537674d7538b4e
This also allows us to write mixed-endian structures and adds tests. As part of
this commit we've also changed the API of something that's not yet been in any
tarball release, so no pitchforks please.
This linker flag is used by Ubuntu by default for packages.
It however doesn't work when compiled with `-Wl,-z,defs` which is
the default behavior since 0e17e6d030.
Recommended-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
Similar to NVME, ATA drives distributed by Dell have special values
that should be used to designate fwupd GUIDs and only run correct
firmware.
When detecting Dell GUIDs remove the standard fwupd GUIDs. "Generic"
firmware targeted to those GUIDs will fail to install.
Some firmware has a different on-device checksum to the hash of the firmware
file itself. This may be because:
* The content is not a binary file, e.g. Intel HEX or SREC
* Only part of the firmware is flashed, e.g. ignoring the bootloader section
* The device checksum is calculated using another method entirely, e.g. PCR0
It's also made complicated as there may be more than one 'correct' device
checksum in some cases, but nothing that a union query can't solve.
We can't actually access the UEFI ROM from userspace, but the PCR0 is a hash
built from the ROM itself. We could use this value to ensure the firmware has
been written correctly, and that the PCR0 matches the expected value specified
in the metadata.
The client uses GObject introspection to use the libfwupd2 library.
The client offers a reduced set of commands, but may be useful in some
environments.
This speeds up matching for GUIDs by about 90%, taking the query from 3.17ms to
about 0.33ms on my Thinkpad. This is more important for slow ARM hardware,
where strcmp() is more expensive than on x64.
This matches what a lot of other projects do, and means we can easily format
the release notes back into NEWS format, but also into HTML and Markdown.
This also means we can show the correct update description in gnome-software
when building a flatpak, rather than falling back to the generic project
description.
