If the user is trying to install version '20190104' on something with the
existing version '1.2.3' then something has gone wrong. Ensure the device
release version format matches the release version format and fail to apply the
update if this is not true.
In the common case setting the version with fu_device_set_version('1.2.3')
would set the version format to TRIPLET, and setting <release version='1.2.3'>
so no action is required. In cases where the version format could be ambiguous
then the format should be set both in a quirk and also in the metainfo file.
Some firmwares only update one part of the system, e.g. the EC or ME firmware.
Other updates include all the updates needed for the whole system, and vendors
have been doing different things with the component name due to this.
To fix, add an enumerated set of firmware 'categories' that can be set by the
uploader in the metainfo.xml file (or changed the LVFS) which automatically
set the name suffix.
Only append the translated version in the client when <categories> has
not been set, as the LVFS is still operating in compatibility mode and setting
the <name> with the prefix. Add the support to fwupd now so we can switch in
about 9 months time.
If the history database is corrupt or the daemon crashed during the migration
the history object fails to load, which in turn fails the daemon startup.
Rather than leaving the user with a broken system (which also shows UI to that
effect in gnome-software) delete the existing file and start afresh. Nothing
in the history database is that important anyway.
If we update fwupd 'live' rather than from an ostree or offline update then
kill the running instance unless a firmware update is ongoing.
When users update fwupd at runtime they often forget to restart the fwupd daemon
and say that the update didn't fix it when actually they using the the old code.
This is a vestigate of `fwupdtool` originally only being used for
`install-blob`. Now that it can do a local `update` command and
local `install` command, it's important to update the history
database from `fwupdtool` as well.
Older versions of Plymouth are more fragile and we can sometimes block the
offline process waiting for the splash to appear.
Use the new system-upgrade and reboot modes, falling back to older modes if
unavailable, showing text on stderr if Plymouth is either not installed or just
not working.
We've already done the permissions check in the scheduler, and allowing
downgrade allows the user to go back to a working version in the event of a
regression.
This stops us scheduling an update that has FWUPD_DEVICE_FLAG_REQUIRE_AC when
on battery power, as we don't show messages when in the offline updates mode.
Of course, we still check for AC when we reboot, but the common case is where
we reboot into the offline mode just after we schedule the update without
changing the hardware configuration.
Some devices (e.g. Wacom, DFU and SuperIO) require the device to be in
'bootloader' mode before the device checksums can be populated.
Rather than each plugin handle both the open()->detach()->detach()->close()
sequence handle this in the plugin loader. It's not super-easy to do the right
thing for the failure case, and having two new dedicated vfuncs makes it a lot
simpler.
