commit 684bc0381 ("trivial: fix various shellcheck warnings") adds call
to ${grub_probe} without any argument which causes grub2-probe to return
an error, and generating grub configuration fails.
Add --version argument to avoid the error, and redierct the output to
/dev/null so that it's not included in the grub configuration file.
The commit also adds superfluous single quotes causing another error:
/usr/sbin/grub2-probe: error: cannot find a GRUB drive for `${grub_probe} --target=device \${ESP}` | sed -e "s/^/\t/". Check your device.map.
Fix the quoting to work at least for single device.
Fixes: #5424
Fixes: 684bc0381 ("trivial: fix various shellcheck warnings")
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Recently we had an update that changed the system-defined Platform Key, and
we've certainly had updates in the past that changed the Boot#### variables.
Store some core ACPI and UEFI system integrity state from before and after the
update which can be used to mark (waivable) test failures on the LVFS.
Saving the quirks in the GResource section worked well, but it made the build
system very complicated and also meant the .data section was duplicated in
both `fwupd` and `fwupdtool` -- negating a lot of the hard-fought savings.
Simplify this feature so that we just `cat` all the quirk files together, then
gzip them into a single file. This means that at startup fwupd only needs to
check the mtime of one file, and weirdly it's actually faster to load a smaller
compressed file from disk that it is to load multiple uncompressed files.
We now have two plugins getting the ESP values, and we only allow hardcoding
the ESP in uefi_capsule.conf.
Make all this a lot simpler by moving the ESP+BDP code to `FuContext`, which
also means we can handle the override (via the config file) in the engine,
and the override (in the command line tools) using the same mechanism.
Also, automate the migration of the `OverrideESPMountPoint` -> `EspLocation`
when loading the engine.
Fixes https://github.com/fwupd/fwupd/issues/5042
Semantically it is the desire of the security attribute, not the bios
attribute, i.e. you could imagine that a specific attribute would have
to be *foo or bar or baz* for HSI-1 and *only foo* for HSI-2
Also make it easier to add possible BIOS attribute target values in
plugin code.
We tried to solve this by matching the org.fwupd.hsi AppStream ID, but
in some cases the resolution depends on what actually failed.
Add "the action the user is supposed to do" as flags so that the
front-end can translate this in the appropriate way, for instance,
using a different string for log events and HSI dialogs.
This allows us to print better warning strings, and in the future
would allow us to profile each operation in a meaningful way.
Also, add context to some of the progress steps as required.
