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.
If another offline update task is run at the same time, e.g. pk-offline-update
from PackageKit then we might corrupt the package database when the client
D-Bus request times out.
Copy the fixes from PackageKit so that the offline updates work together.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1685471
For my future self, to debug the fwupd.shutdown activation failure, you can do:
mount /dev/sdc1 /mnt
/usr/libexec/fwupd/fwupdtool activate --verbose &> /mnt/log.txt
umount /dev/sdc1
...where /dev/sdc1 is an attached FAT32-formatted USB drive.
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.
This was caught by LGTM.
This pointer might have type struct <unnamed> (size 28), but the
pointer arithmetic here is done with type UX_CAPSULE_HEADER * (size 16).
This allows us to one day implement 'reinstall', allows us to have a more useful
`get-releases` command and also means we can add other reasons for blocking the
release in the future.
In the future we'll want to use this flag to signify if the release is an
upgrade, downgrade, below the version-lowest, or if it is locked in some way.
This feature is turned on with the new fwupdtool option `--enable-json-state`
The intended use case is for ChromeOS to be able to save information about
devices on the system when `fwupdtool update` was run to display in the UX at
a later time.
The following warnings were displayed by Debian appstream metadata
validation.
```
metainfo-validation-issue
Validation of the metainfo file found a problem: Found empty 'url' tag.
metainfo-validation-issue
Validation of the metainfo file found a problem: Type 'console-application' component, but no information about binaries in $PATH was provided via a provides/binary tag.
metainfo-validation-issue
Validation of the metainfo file found a problem: Found empty 'url' tag.
```
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 will allow us to switch to the new firmware version during shutdown when
the filesystems have been remounted readonly.
Activating manually means we don't have to get the user to shutdown and then
do a fresh power-on, rather than the more usual restart.
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.
In some situations SELinux prevents fwupd from executing tpm2_pcrlist, but the
failure mode is that the process just hangs and never completes. This causes
systemd to time out the fwupd daemon startup and then errors to be shown in
GNOME Software.
To prevent this happening, add an optional timeout argument to
fu_common_spawn_sync() and cancel the subprocess if it takes longer than this
to complete.
See https://bugzilla.redhat.com/show_bug.cgi?id=1665701 for details.
Allows people to specifiy a white-space separated value for them
Void Linux runs them under qemu-user-static like so
qemu-aarch64-static -L ./usr/aarch64-linux-gnu
./usr/aarch64-linux-gnu/usr/bin/python3
