The logic was built on the presumption of Ubuntu core which doesn't
have /etc/os-release. Since other distributions do have /etc/os-release
adjust the logic to instead build the path explicitly.
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.
Some systems remove the BootXXXX entry we add (so we can run fwupdx64.efi) and
thus the firmware update does not run. Most commonly this failure is seen with
Lenovo systems that call the helpful option 'Boot Order Lock'.
Hopefully when we depend on the new kernel bios interface sysfs API in we can
check in ->prepare(), not after reboot, but until that we can mark the update
failure as transient as the user can actually fix the problem themselves.
Fixes https://github.com/fwupd/fwupd/issues/2801
