"Without it grub-install is broken so break the package as well if unavailable" is not quite true. We have quite a few uboot based system with efi payload that emulated EFI API and thus can be booted up directly by efi application/grub2-efi as well. These systems is not UEFI and thus doesn't have any efi nvram store for boot variables on that efibootmgr CANNOT run, and instead --no-nvram has to be used on those systems.
Forcing the efibootmgr dependency will break installation on those arm systems with efi payload for uboot as currently they run without efibootmgr at all (And don't really require it).
eifbootmgr can run on those systems. It just reports there is no nvram support. However, missing efibootmgr will cause grub2-install to fail completely.
OK, so the --no-nvram option is documented. However, "grub2-install: error: efibootmgr: not found." is not obviously linked to missing this option.
It might be nice to patch grub to provide saner diagnostics. However, fixing our packaging should come first and it is broken here: grub relies on efibootmgr to provide the user diagnostics about missing EFI nvram support and efibootmgr is not available because somebody included an ExclusiveArch line in its spec file. Removing the line and adding the dependency on efibootmgr makes it possible to use the current grub logic as-is.
I think Michal should make the submission to efibootmgr first, make sure it's accepted then make a follow up submission to grub2 to require it and we are all fine. I am embarrassed also stuck here as I can't take any action right now. (And the web UI did not offer me the permission to accept or decline this request).
"Without it grub-install is broken so break the package as well if unavailable" is not quite true. We have quite a few uboot based system with efi payload that emulated EFI API and thus can be booted up directly by efi application/grub2-efi as well. These systems is not UEFI and thus doesn't have any efi nvram store for boot variables on that efibootmgr CANNOT run, and instead --no-nvram has to be used on those systems.
Forcing the efibootmgr dependency will break installation on those arm systems with efi payload for uboot as currently they run without efibootmgr at all (And don't really require it).
eifbootmgr can run on those systems. It just reports there is no nvram support. However, missing efibootmgr will cause grub2-install to fail completely.
OK, so the --no-nvram option is documented. However, "grub2-install: error: efibootmgr: not found." is not obviously linked to missing this option.
It might be nice to patch grub to provide saner diagnostics. However, fixing our packaging should come first and it is broken here: grub relies on efibootmgr to provide the user diagnostics about missing EFI nvram support and efibootmgr is not available because somebody included an ExclusiveArch line in its spec file. Removing the line and adding the dependency on efibootmgr makes it possible to use the current grub logic as-is.
is there a reason to not build efibootmgr on all architectures? thats the main question here. it seems to build so why not enable it?
I think Michal should make the submission to efibootmgr first, make sure it's accepted then make a follow up submission to grub2 to require it and we are all fine. I am embarrassed also stuck here as I can't take any action right now. (And the web UI did not offer me the permission to accept or decline this request).