Current behavior for the prompt:
```
Y … Restart & Update
y … Restart & Update
N … Tool abort & Update complete after next Power cycle
n …Tool abort & Update complete after next Power cycle
0 … Pause -> (Push anykey) -> Restart & Update
* … Pause -> (Push anykey) -> Restart & Update
“”(Enter Only) … Restart & Update
```
If someone just keeps pressing enter without reading the system will reboot
which might lead to data loss.
Set the default scenario to abort reboot, so they can just see the message
to reboot instead.
The plugins are not opened for this function so of course they
won't set their build hashes.
Fixes errors like this:
`uefi should call fu_plugin_set_build_hash()`
This support was using the wrong commands to add a HWID and thus
never actually functioned. Furthermore it's purpose is to pull
the PID out of the bootloader to be able to properly identify
the device when in bootloader mode (as in recovery mode).
When in this state, generate the correct instance IDs for both
possible Wacom VID. We can't tell which Wacom VID we are in
bootloader mode.
This makes everything simpler, at the expense of not being able to create a
`BootFFFF` entry -- but if we get that far something has already gone very
wrong with the firmware...
Some derivative distributions re-use bootloader paths from their
upstream. When this happens the current logic to look for the `ID`
key in `/etc/os-release` doesn't work properly.
Adjust the logic to:
1) Use `ID`
2) Test the path exists. If so, use it.
3) If it doesn't use `ID_LIKE`.
4) Test if that path exists, if so use it.
5) If that path doesn't exist, return the key from `ID`
6) The plugin will make this path.
Recently had a discussion on the expected behavior of calling
`#fwupdmgr update`/`fwupdtool update` with `--allow-reinstall`
in place.
It wasn't working which was confusing to the reporter, but I
feel that flag should only be usable with `install`. Upgrades
are for upgrades and downgrades are for downgrades. Reinstalls are
for reinstall.
For composite devices you might want to restrict the child device in respect
to the parent, for instance requiring the parent to have greater than a specific
firmware version number.
The other useful thing to use this for is checking if the parent has a specific
GUID (of any version) which allows us to match against the common VID&PID
instance IDs. This would allow us to restrict a generic child device update to
a specific OEM vendor parent.
This is specified as <firmware depth="1" ...> to match the parent device and
<firmware depth="2" ...> to match the grandparent device.
