Comment # 21 on bug 978593 from
(In reply to Michael Chang from comment #20)
> (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 ...

Yes, but the person pulling a change to perl-bootloader is the same person that
would pull a change to the list of modules we include during the install phase.
So changing it to efi/vars doesn't allow us to proceed any faster.

The reason I chose efivars over efi/vars is that it's easier to identify that
there are no variables. The efivars directory is simply empty if you don't have
any efi variables available. The efi/vars directory always contains special
files to modify entries.


You are receiving this mail because: