Although they can be useful for debugging the codepath leading to
a problem, they are also confusing when it comes to the end user
messages:
```
{error #0} linux.c:406 device_get(): readlink of /sys/block/nvme0n1/device/driver failed: No such file or directory
{error #1} linux.c:406 device_get(): readlink of /sys/block/nvme0n1/device/driver failed: No such file or directory
{error #2} linux.c:406 device_get(): readlink of /sys/block/nvme0n1/device/driver failed: No such file or directory
{error #3} linux.c:406 device_get(): readlink of /sys/block/nvme0n1/device/driver failed: No such file or directory:
Error writing to file descriptor: No space left on device
```
Whereas if they weren't shown, that last message would have been plenty.
fu_uefi_get_esp_path_for_os() generates the path to the OS directory
based on "ID" in /etc/os-release, and it may not work for some distros.
Take openSUSE as an example, the "ID" for openSUSE Leap is
"opensuse-leap" and that for openSUSE Tumbleweed is "opensuse-tumbleweed".
However, both of them use the same OS directory in the ESP, i.e.
"/EFI/opensuse".
This commit adds a new build option, efi_os_dir, to allow the packager to
specify the name of OS directory at build time instead of the runtime
detection.
Signed-off-by: Gary Lin <glin@suse.com>
systemd-automount will unmount the ESP when not in use for some
people. This causes automatic ESP detection to fail.
In this case the ESP will need to be added to the conf file and
then this commit will let it keep working.
/boot is a special cased directory when using ProtectSystem=full
Due to this, it's marked read only even if it's listed in ReadWritePaths.
Allow folks to use this for their ESP, but they need to create /boot/EFI
in advance of starting fwupd.
Additionally, if the user specified something invalid, do not autodetect the
ESP but return with a journal error. It seems wrong to ignore what the user
explicitly set and perhaps do something dangerous.
Alternative to https://github.com/hughsie/fwupd/pull/599
