Create and destroy /run/lock/power_override/fwupd.lock.
This file will hold the contents of getpid (), which will
stop the device from being suspended while the file exists.
The file will be created and written just before the
update is put into motion and be destroyed once the update
finishes, or upon restart in case of catastrophic failure.
Change-Id: If8dd17b0358862a842c9589e11ed0de12d852797
This speeds up fu-self-test, but more importantly fixes a intermittent
'ninja check' failure when a host USB device disconnects at exactly the
wrong time.
The FuUsbBackend code is unusual in that the setup() code sets up a
context (with a thread) which takes up to 2 seconds to timeout.
We don't want to show the big warning about the missing ESRT on server
hardware that is managed by a BMC:
WARNING: UEFI capsule updates not available or enabled in firmware setup
See https://github.com/fwupd/fwupd/wiki/PluginFlag:capsules-unsupported for more information.
Applying updates to my new P1G3:
* schedule the update in fwupd
* boot into the BootNext
* apply the capsule with RT->UpdateCapsule
* reboot with RT->ResetSystem
Except the firmware updater EFI binary then wasn't running. The ESRT
last_attempt_status comes back as Success on the reboot.
Disabling the UX capsule made the update apply correctly each and every
time. Until we can work out what models are affected, use a per-vendor
quirk to avoid delaying the release.
This CL moves the battery information retrieval into a new function,
called "fu_plugin_powerd_callback()", which returns the information in a
struct.
This information is then used in fu_plugin_update_prepare() for battery
checks. There is also a g_timeout_add() function being created in
fu_plugin_startup() in order to enable the plugin to repeatedly send a method
call to powerd.
fu_plugin_update_prepare is removed as its functionality is now handled
by src/fu-engine.c
We have the property notification in place now so that the update state
is saved correctly to the database on error.
This helps with debugging as we don't need to explain (to ourselves?!)
why the device is marked as failed even though nothing has run.
If we swap from runtime -> bootloader -> runtime we need to copy the
update state in each step even if we're just switching the swapping the
runtime device.
This regressed, as we optimized away the call to fu_device_list_replace.
1. Let the user know what commit it's reformatting in stdout
2. Add a debug mode to show the command that was launched
3. Fix output of errors
4. Allow the user to specify starting commit in an argument
In hindsight connect() was a poor choice of name as this is hardcoded
as the GObject parent method for signal attachment. It's not actually
required when using the sync API in Python as it's called when required.
The LVFS is now adding an artificial NUL to the metainfo data to work
around a possible buffer over-read on old fwupd versions. This breaks
new code that reads the XML buffer using xb_builder_source_load_bytes
as GLib then tries to parse the final NUL byte.
As `xmllint` actually ignores the trailing NUL, we should as well.
Shim has had a hard time with loading updates from arguments in the
most recent release and this isn't the first time that happened.
Give distros and users an escape hatch that will allow using GRUB
instead.
We should be just checking if the thinklmi plugin inhibited the device,
and if we fix the bug where the last_attempt_status value was not being
read on startup then this test will then fail.
By default the daemon start if no configuration is present, but
the first time that an fd is accessed the following error shows up:
```
A maximum read size must be specified
```
This is because the maximum archive size wasn't initialized.
