Bug#783990: efivarfs is a separate fs and needs moutning

[Thorsten Glaser]

On Fri, 16 Jul 2021, The Wanderer wrote:
>On Fri, 16 Jul 2021, Ian Jackson wrote:
>>On Fri, 16 Jul 2021, The Wanderer wrote:
>>>On Fri, 16 Jul 2021, Ian Jackson wrote:
>>>> Thorsten Glaser writes ("Re: Bug#783990: efivarfs is a separate fs and needs moutning"):
>>>> > This is not as easy as it sounds:
>>>> >
>>>> > tglase at tglase-nb:~ $ sudo mount -t efivarfs efivarfs /sys/firmware/efi/efivars
>>>> > mount: /sys/firmware/efi/efivars: mount point does not exist.
>>>> > 32|tglase at tglase-nb:~ $ sudo mkdir -p /sys/firmware/efi/efivars
>>>> > mkdir: cannot create directory ‘/sys/firmware/efi’: Operation not permitted
>>>> >
>>>> > This is on amd64 without EFI (classical BIOS, no CSM).
>>>>
>>>> Oh.
>>>>
>>>> I guess this should be done if /sys/firmware/efi/efivars exists, then.
>>>>
>>>> Can you confirm that that directory doesn't exist for you ?

/sys/firmware/efi does not exist for me.

tglase at tglase-nb:~ $ mount
/dev/sda4    /                         ext4         (rw,relatime,errors=remount-ro,stripe=256)
/dev/sda1    /boot                     ext4         (rw,noatime,sync)
udev         /dev                      devtmpfs     (rw,nosuid,relatime,size=4014412k,nr_inodes=1003603,mode=755)
devpts       /dev/pts                  devpts       (rw,nosuid,noexec,relatime,gid=5,mode=600,ptmxmode=000)
tmpfs        /dev/shm                  tmpfs        (rw,nosuid,nodev,noexec,relatime,size=1614660k)
proc         /proc                     proc         (rw,nosuid,nodev,noexec,relatime)
binfmt_misc  /proc/sys/fs/binfmt_misc  binfmt_misc  (rw,nosuid,nodev,noexec,relatime)
tmpfs        /run                      tmpfs        (rw,nosuid,nodev,noexec,relatime,size=807336k,mode=755)
tmpfs        /run/lock                 tmpfs        (rw,nosuid,nodev,noexec,relatime,size=5120k)
sysfs        /sys                      sysfs        (rw,nosuid,nodev,noexec,relatime)
pstore       /sys/fs/pstore            pstore       (rw,relatime)
securityfs   /sys/kernel/security      securityfs   (rw,relatime)
tmpfs        /tmp                      tmpfs        (rw,nosuid,nodev,relatime,size=6458640k)
swap         /var/cache/apt            tmpfs        (rw,nosuid,noexec,relatime,mode=755)
tglase at tglase-nb:~ $ ls -l /sys/firmware/
total 0
drwxr-xr-x  5 root root 0 16. Jul 17:43 acpi
drwxr-xr-x  4 root root 0 16. Jul 17:43 dmi
drwxr-xr-x 18 root root 0 16. Jul 17:43 memmap

(My “mount” does
	mount | sed 's/ on \([^ ]*\) type / \1 /' | sort -bk2 | column -t
for better legible output.)

>>> A possible additional complicating factor: on my system (tracking
>>> current testing, which I suspect is likely to turn into stable fairly

Roughly 15 more days, AFAIHH.

>>> soon), with sysvinit as the active init system, this directory already
>>> exists and is already mounted.

Then test for existence of a file inside that first. I don’t have access
to an EFI system, can you share an “ls -l /sys/firmware/efi/efivars”,
and probably an “ls -l /sys/firmware/efi” and “mount” as well?

>> Perhaps the initramfs mounts it ?  I can't conveniently check.

Possibly. Me either.

> (It also finds that
> /usr/share/doc/linux-doc-5.10/html/_sources/filesystems/efivarfs.rst.txt
> suggests 'mount -t efivarfs none mountpoint' rather than 'mount -t
> efivarfs efivarfs mountpoint', but I suspect the end result will be the
> same regardless.)

That won’t make a difference other than the (decorative, for
pseudo filesystems) first column of mount output. I consider
it more useful to not just put “none” in there for most.

>> I suggest the following approach in mountkernfs:

1.	See if /sys/firmware/efi/efivars/somefile exists;
	if it does, it’s already mounted, and there’s
	nothing to do.

>>   - See if /sys/firmware/efi/efivars exists.
>>
>>   - If it does, and nothing is mounted on it yet, try to mount
>>     efivarfs with the runes earlier in this bug.

Is /sys/firmware/efi also a mountpoint, or is it a mere directory?
Does it always contain an efivars subdirectory? (Though, if it
doesn’t, we can’t create it anyway, I guess.)

>>   - If that mount fails, print an error message, but otherwise
>>     do not treat this as an error.

Agreed. Perhaps just display the error from the mount.

>> If you think this is a good plan I will send a patch.  Would each of
>> you be willing to do a test reboot with it ?

Sure¹, but let’s hold out a bit, we need some fixed file within
/sys/firmware/efi/efivars/ to test for… or see if it’s empty,
depending. I might have a look at the kernel source if needed.

① I just switched all my systems from sid to bullseye to avoid
  the latest TC decision, but I can just live-patch the file
  in question.

bye,
//mirabilos
-- 
15:41⎜<Lo-lan-do:#fusionforge> Somebody write a testsuite for helloworld :-)