Comment # 20 on bug 978593 from Michael Chang

(In reply to Alexander Graf from comment #19)
> (In reply to Michael Chang from comment #18)
> > (In reply to Alexander Graf from comment #16)
> > > (In reply to Michael Chang from comment #15)

> 
> 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.

There may be some misunderstanding here, the "efivars" seen already built-in in
kernel while "efivarsfs" is a kernel module and not available in install
system.

At least from my test

ls /sys/firmware/efi/efivars

outputs nothing but

ls /sys/firmware/efi/vars

outputs plenty of files.

In your patch it's testing /sys/firmware/efi/efivars ...

> 
> 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.

OK. I think you're right here. I just want to highlight that shim also provide
a similar "fallback" feature that will "restore" the boot entries if it was
placed under default boot path (eg /boot/efi/BOOTX64.efi) to restore the
missing boot entries after a firmware upgrade which may erase all entries. It
will only get installed there if that path is not occupied. I am not really
into this part of work (Gary did it) so wouldn't be able to say more about it
so basically JFYI. :)

Thanks.