Re: efivar(8) status/usability/functionality in 15

On Sat, Jun 20, 2026 at 03:54:11PM +0300, Anton Saietskii wrote:
> On Sat, Jun 20, 2026 at 3:03 PM Konstantin Belousov <[email protected]> wrote:
> >
> > On Sat, Jun 20, 2026 at 02:47:44PM +0300, Anton Saietskii wrote:
> > > Hi folks,
> > >
> > > After 15.1-R branched, I performed major upgrade and took the idea of
> > > setting up Secure Boot from my personal backlog. As a preparation
> > > step, wanted to see which EFI variables I have, but that failed:
> > > $ sudo efivar -l
> > > efivar: error listing variables: Function not implemented
> > >
> > > Tried to get variable that exists for sure but it also failed:
> > > $ sudo efivar -n e11207ca-d4ad-11ee-928b-589cfc102103-Boot0000 -p
> > > efivar: show variable: Function not implemented
> > >
> > > Of course, module is loaded:
> > > $ kldstat -v | grep efi
> > > 20    1 0xffffffff839a6000     46e9 efirt.ko (/boot/kernel/efirt.ko)
> > >                 177 efidev
> > >                 178 nexus/efirtc
> > >                 176 efirt
> > >
> > > And basically every command (except '-w' which I haven't verified
> > > because I can't read variables, and '-L' which lists some GUIDs) fails
> > > and efivar feels like a stub (at first glance it all was the same on
> > > 14). If I'm doing something wrong--I'd love to see some success
> > > stories.
> >
> > Are there any kernel messages when you load the efirt.ko module?
> Nothing interesting I'd say, but this regular non-verbose boot:
> $ grep efi /var/run/dmesg.boot
> VT(efifb): resolution 1920x1080
> [4] VT: Replacing driver "efifb" with new "drmfb".
> [4] efirtc0: <EFI Realtime Clock>
> [4] efirtc0: registered as a time-of-day clock, resolution 1.000000s
> 
> > Was the /dev/efi node created?
> Yes:
> $ ll /dev/*efi*
> crwx------  1 root wheel 0x17b Jun 19 17:39 /dev/efi
> $
> 
> Also, I believe it is working correctly as another tool, efibootmgr,
> works perfectly fine (I took EFI variable with boot entry from there).
> 
> "Not implemented" errors from efivar look weird, but I'm not
> proficient enough to determine if they are true, nor where they
> actually come from (exe, lib, kernel, or firmware itself). What if the
> list and read of variables are not actually implemented? (I don't
> believe this is my system configuration though, the only relevant
> thing would be WITHOUT_EFI source option but I wouldn't even get
> efivar binaries with it enabled.)

Look with ktrace to see which ioctl(2) fails.