(In reply to Michael Chang from comment #18) > (In reply to Alexander Graf from comment #16) > > (In reply to Michael Chang from comment #15) > > > > > > Why? Wouldn't the "normal" EFI systems covered by that check as well ? (ie > > > it will not append --no-nvram --removable) > > > > Exactly, so for the "normal" systems nothing changes over today's state. We > > still have a broken removable file because pbl installed it, so if we end up > > in the fallback case for whatever reason (nvram invalidated in between > > executions, wrong boot order configured manually, etc) we still boot the > > wrong one. > > Maybe as a temporary fix we should check for ARM patform in that pbl patch > (or even yast in the future), we should leave that default efi loader in x86 > hanldled by shim's fallback mode (ie shim-install). I think if what you say is true, the best solution would be to just include efivars.ko in the installer system. Then the rest should resolve itself automatically, because we will detect the correct type of system again. Also, whether we use shim or grub2-install is completely orthogonal over whether we want to install the bootloader as --removable or not. Shim vs grub2-install is a software concept, NVRAM available or not is a hardware problem - some systems simply don't have any storage for it. > It's even more hard to say as an analogy to mbr whether we should "update" > that file or not from our system. It maybe owned by other distro, much more > likely on x86.. It should really be an option for x86 but I think ARM is > fine with that. > > > > > In my case, I usually end up with the removable fallback because I use > > qemu's -bios option which treats all nvram variables as volatile, so after a > > reset they're gone. > > The vars are store in ESP, IIRC, as file name /NvVars to be restore during > OVMF booting. But that's a hack indeed. (And I don't know whether it's also > the case for ARM). Hm, if it's intended to work, it definitely did not work for me :).