Re: efivar(8) status/usability/functionality in 15
Anton Saietskii <[email protected]> Mon, 22 Jun 2026 15:14:08 +0300
| Newsgroups | gmane.os.freebsd.stable |
|---|---|
| Message-ID | <CAA2O=b-6BLCB8RE024B5iFpiS-5ROowdezUjR86iu=bQ6H5utw@mail.gmail.com> |
On Sat, Jun 20, 2026 at 4:02=E2=80=AFPM Konstantin Belousov <kostikbel@gmai= l.com> wrote: > > "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. Great suggestion! Discovered the following: <CUT> 10848 efivar CALL statfs(0x3d4d61408000,0x2274d6d1ba70) 10848 efivar NAMI "/sys/firmware/efi/efivars/" 10848 efivar RET statfs -1 errno 2 No such file or directory 10848 efivar CALL open(0x2274d93c0f40,0x120000<O_RDONLY|O_DIRECTORY|O_CLOEXEC>) 10848 efivar NAMI "/sys/firmware/efi/vars/" 10848 efivar RET open -1 errno 2 No such file or directory <CUT> Which is not the path expected. It worked in root session though. This raised a suspicion that maybe some different efivar is being called, which was actually true. sysutils/fwupd had devel/efivar in depends some time ago, but somehow 'pkg autoremove' didn't remove it. efivar(8) from base system works completely fine. Thanks for pointing me in the right direction. -- wbr, Anton