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.
The current libxmlb dependency requires this and when run in subproject
mode will cause failures otherwise.
Also bump the snap to use meson 0.47.2 to fix snap build due to this
failure.
1) Remove the confusing --firmware-id and build this field dynamically based on GUID and Developer name
2) Make developer name mandatory
3) Rename device-unique-id to device-guid to more closely reflect how fwupdmgr shows it
4) Allow running on Windows
The libxmlb library is much faster to query, and does not require the daemon
to parse the XML metadata at startup. It's a zero-copy mmap design that is more
modern and less clunky.
RSS has reduced from 3Mb (peak 3.61Mb) to 1Mb (peak 1.07Mb) and the startup
time has gone from 280ms to 250ms.
Leading to this problem:
Building fwupd-wrappers
Failed to copy '/build/fwupd/parts/fwupd-wrappers/build/snapcraft-stable.yaml': it's a symlink pointing outside the snap.
Fix it to be valid when snapped and try again.
Build failed
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/lpbuildd/target/build_snap.py", line 229, in run
self.build()
File "/usr/lib/python2.7/dist-packages/lpbuildd/target/build_snap.py", line 218, in build
env=env)
File "/usr/lib/python2.7/dist-packages/lpbuildd/target/build_snap.py", line 75, in run_build_command
return self.backend.run(args, env=full_env, **kwargs)
File "/usr/lib/python2.7/dist-packages/lpbuildd/target/lxd.py", line 460, in run
subprocess.check_call(cmd, **kwargs)
File "/usr/lib/python2.7/subprocess.py", line 541, in check_call
raise CalledProcessError(retcode, cmd)
Scanning for processes to kill in build SNAPBUILD-351860
Workaround for https://bugs.launchpad.net/launchpad/+bug/1797366
It was previously a symlink to contrib/snap/snapcraft-stable.yaml
however infrastructure changes in launchpad have caused this to break
automatic snap builds.
This plugin requires infrastructure introduced in fwupd 1.1.3
and can not be backported to earlier versions of fwupd.
It works together with the Synaptics and Thunderbolt plugins to
coordinate the proper flashing procedure for devices in this dock.
At least for me it was a challenge to get the debugger properly
configured to allow debugging fwupd when built in tree.
This should allow very simple debugging.
This is meant to produce standalone installer binaries that can operate
on machines without current tools or internet access.
It works by wrapping around the container technologies snap and flatpak
and putting all the pieces together.
Newer versions of bolt provide a superior experience when using
Thunderbolt force power rather than directly using the kernel.
Pull bolt in when installing fwupd to take advantage of this.
This commit adds redfish.conf to configure the IP and username/password
in case those are not available in SMBIOS and the EFI variables.
Since we can configure the IP in the conf file, the environment
variable, FWUPD_REDFISH_URI, is removed.
Signed-off-by: Gary Lin <glin@suse.com>
(Hopefully without breaking the Ubuntu packaging!)
When building, also generate a fwupdate-$ARCH-signed-template package
which contains metadata needed by the Debian signing service. This
will end up being turned into a new source package including a signed
version of the fwupdate binary.
Update the existing debian packaging files for fwupdate to do this,
and also add the core of the template in the debian/signing-template
directory. Also add a couple of helper scripts to drive things, and
update our README.Debian.
Redfish is an open industry standard specification and schema that helps enable
simple and secure management of modern scalable platform hardware.
This has only ever been tested using an emulator and not on real hardware.
In Fedora the only user of libfwupdate is fwupd and the fwupdate command line
tool. It makes sense to absorb the libfwupdate library interface into the
uefi plugin in fwupd. Benefits I can see include:
* fwupd and fwupdate are very similar names; a lot of OEMs are confused
* fwupd already depends on efivar for other things
* We are maintaining an artificial library interface
* The CI and translation hooks are already in place for fwupd
* We don't need to check for features or versions in fwupd, we can just develop
the feature (e.g. BGRT) all in one place.
Since the snap is named fwupd, fwupdtool gets namespaced as
fwupd.fwupdtool so bash completion doesn't work properly.
Add a step to fixup bash completion paths
Per discussion in trying to get classic snap approved, snap security
audience would rather see all interfaces used by fwupd added into
snapd interfaces so proper confinement works.
This will require devmode for now until that has occurred.
Requiring colord to be built before fwupd makes it hard to build packages.
The HID-based flashing protocol is stable and documented, so there's no need
to use an external library for this now.
This is designed to be run as root accessing the hardware directly rather than
using the daemon. This would allow a snap or flatpak package to write firmware
even when the host fwupd daemon is too old.
Also, move the SMBIOS parsing code here as this is not needed in fwupdmgr.
This means we can avoid loading a ton of non-fwupd files, and reduces our
running RSS from 5.4Mb to 2.8Mb. Old versions of appstream-glib caches a lot of
the localization string data which we just don't care about for firmware files.
There are a lot of hacks here;
* Pulling newer libappstream-glib from Fedora
* Pulling a systemd backport
* Manually installing pillow and pygobject
* PKCS7 is turned off (gnutls is too old)
The synaptic mst test wants to open its test files as r/w, however as the
arch build runs as user nobody that won't work unless the test files are
also owned by user nobody. To make that happen, copy the source tree
rather then symlinking it
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
