On Sat, 12 Nov 2022 at 22:10, Ulrich Gemkow <ulrich.gemkow@xxxxxxxxxxxxxxxxxxxx> wrote: > > Hallo Ard, > > On Saturday 12 November 2022, you wrote: > > On Sat, 12 Nov 2022 at 17:55, Ulrich Gemkow > > <ulrich.gemkow@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > Hello Ard, > > > > > > On Saturday 12 November 2022, you wrote: > > > > On Sat, 12 Nov 2022 at 16:26, Ulrich Gemkow > > > > <ulrich.gemkow@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > > > Hello Ard, > > > > > > > > > > thanks for looking into this! > > > > > > > > > > On Saturday 12 November 2022, you wrote: > > > > > > On Sat, 12 Nov 2022 at 14:42, Ulrich Gemkow > > > > > > <ulrich.gemkow@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > calling efibootmgr for adding EFI boot entries with Linux 6.0.8 does > > > > > > > not work on our Lenovo T14 Gen 3 (intel). The error is "EFI variables > > > > > > > are not supported on this system". The directory /sys/firmware/efi/efivars/ > > > > > > > exists but is empty. > > > > > > > > > > > > > > This worked fine with the latest 5.19 kernel. The config was transferred > > > > > > > from 5.19 to 6.0 with "make oldconfig". All kernels are self-compiled > > > > > > > and without changes from the kernel.org downloads. > > > > > > > > > > > > > > I saw earlier messages about bugs in this area, the fixes applied > > > > > > > seem to be not complete. > > > > > > > > > > > > > > Please let me know when additional information would help to debug. > > > > > > > > > > > > > > > > > > > Hello Ulrich, > > > > > > > > > > > > Can you please share the complete kernel boot log when booting with > > > > > > efi=debug, and the .config used to build the kernel? Thanks. > > > > > > > > > > > > > > > > please find attached the two files. Please do not get confused about > > > > > the kernel uname, the used kernel is 6.0.8. I use my own automated > > > > > setup and build environment which requires a different naming. > > > > > > > > > > > > > Does it work if you enable CONFIG_EFI_STUB? > > > > > > > > > > Enabling CONFIG_EFI_STUB does not help, the problem remains. > > > > > > I digged around and found that mounting the efivarfs solves the > > > problem. This was not required with 5.19. Is this an expected > > > or wanted change of behavior? > > > > > > > That is surprising. It is entirely up to user space whether and when > > efivarfs gets mounted - the kernel just provides the facilities but > > does not decide if they get used. > > > > Which distro are you using? > > In principle this is Debian 11 but the whole base (init, kernel, ...) > is self-made. So the distro is maybe not really relevant. > > I understand the problem as follows: With 5.19 mounting the efivarfs was > not required to change EFI boot entries. In 6.0 it seems to be required > for efibootmgr to change boot entries. > > I created a standard Debian 11 install and efivarfs is mounted. So maybe > in current distros the efivarfs is normally mounted. > > So while the changed behavior is formally a regression it may not be relevant > because most users of todays distros may not notice the change because of > the always mounted efivarfs. I cannot judge whether this is relevant. > I figured out what is happening. 6.0 removes the ancient efivar sysfs interface for accessing EFI variables. This has been replaced by efivarfs ~10 years ago, but has only been removed recently. The old sysfs based interface exposes the EFI variables under /sys/firmware/efi/vars [not /efivars] and requires no explicit mount. efibootmgr will fall back to this legacy method if it cannot find the EFI variables under /sys/firmware/efi/efivars, which is the case for you because efivarfs is not mounted. So the answer is really to add efivarfs to the list of pseudo filesystems like proc and sysfs that get mounted automatically at boot.
