Bug#783990: efivarfs is a separate fs and needs moutning
On 2021-07-16 at 13:02, The Wanderer wrote: > On 2021-07-16 at 12:55, Ian Jackson wrote: > >> I have now tested this. I found that a safety catch in >> mount-functions caused it to not work, and this additional patch is >> needed. >> >> mount-functions looks in /etc/filesystems and skips mounting things >> which the kernel doesn't seem to supoort. In general with so many >> filesystems being kernel modules this seems to be of questionable use. >> In this case it definitely broke things: I found that mounting the >> filesystem with mount(8) auto-loads the module. >> For your testing: >> >> AFAICT it isn't a particularly good idea to just copy the new >> mount-functions.sh into /lib but monkey-applying the patch with >> >> patch /lib/init/mount-functions.sh < >> 0001-initsripts-mount-functions-Do-not-check-efivarfs-in-.patch >> >> worked for me. With those patches (and the bodge in fstab commented >> it) it all works. > > I need to do some other things for a while, so I won't be rebooting > again immediately, but I'll probably test this sometime this afternoon. This has now been tested (twice, once from intentional shutdown and once from unexpected power loss). I did not make note of what boot-time message(s) there may or may not have been, but the mount is still in place and functioning without issues, and I don't see any new errors in e.g. dmesg. Barring reason to do otherwise, I plan to leave the patch applied until such time as something overwrites it (probably on a package upgrade). If I notice any issues, I will try to report back. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#783990: efivarfs is a separate fs and needs moutning
On 2021-07-16 at 13:36, Ian Jackson wrote:
> The Wanderer writes ("Re: Bug#783990: efivarfs is a separate fs and
> needs moutning"):
>
>> Wouldn't testing the existence of
>>
>> /lib/modules/`uname -r`/kernel/fs/efivarfs/efivarfs.ko
>>
>> be enough, and probably more reliable?
>
> I'm doubt very much it would be more reliable. What if the kernel
> reorganises its modules ?
That possibility hadn't even occurred to me, but now that you point it
out, I drop this suggestion.
>> (I'm assuming that the test which skips because "fstype not
>> available" comes before the one which skips because "already
>> mounted", and that's why I saw the warning even though it seems to
>> be up and working on my machine.)
>
> Yes, the tests are indeed in that order. I think you have it
> mounted now because of the apparmor fixup you found.
I was initially not sure that was going to be relevant after all,
because I was expecting AppArmor to be a thing that has to be constantly
running in order to be effective, and there's no such process visible
that I can see - but apparmor shows up in dmesg, et cetera, so I must
have been expecting wrong.
> The change to mountkernfs was ineffective on your system for the same
> reason it was ineffective on mine, but the apparmor workaround means
> you don't see the effects since apparmor has got it mounted by the
> time you log in.
Makes perfect sense.
>> I need to do some other things for a while, so I won't be
>> rebooting again immediately, but I'll probably test this sometime
>> this afternoon.
>>
>>
>> My current biggest concern about this is:
>>
>> --
>
> No objections then ? :-) (I think you may have missed a bit...)
Heh. That line was a leftover of when I was going to raise the question
of why the "fstype not available" test was even being reached, given the
"already mounted" test, before I realized that it must be simply a
matter of test order.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
Bug#783990: efivarfs is a separate fs and needs moutning
The Wanderer writes ("Re: Bug#783990: efivarfs is a separate fs and needs
moutning"):
> Wouldn't testing the existence of
>
> /lib/modules/`uname -r`/kernel/fs/efivarfs/efivarfs.ko
>
> be enough, and probably more reliable?
I'm doubt very much it would be more reliable. What if the kernel
reorganises its modules ?
Also, it would then have to be OR-ed with the check in
/proc/filesystems, since you might have the module built-in.
> (I'm assuming that the test which skips because "fstype not available"
> comes before the one which skips because "already mounted", and that's
> why I saw the warning even though it seems to be up and working on my
> machine.)
Yes, the tests are indeed in that order. I think you have it mounted
now because of the apparmor fixup you found. The change to
mountkernfs was ineffective on your system for the same reason it was
ineffective on mine, but the apparmor workaround means you don't see
the effects since apparmor has got it mounted by the time you log in.
> I need to do some other things for a while, so I won't be rebooting
> again immediately, but I'll probably test this sometime this afternoon.
>
>
> My current biggest concern about this is:
>
> --
No objections then ? :-) (I think you may have missed a bit...)
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Bug#783990: efivarfs is a separate fs and needs moutning
On 2021-07-16 at 12:55, Ian Jackson wrote: > I have now tested this. I found that a safety catch in > mount-functions caused it to not work, and this additional patch is > needed. > > mount-functions looks in /etc/filesystems and skips mounting things > which the kernel doesn't seem to supoort. In general with so many > filesystems being kernel modules this seems to be of questionable use. > In this case it definitely broke things: I found that mounting the > filesystem with mount(8) auto-loads the module. > > I'm using the existence of the mountpoint directory as a proxy for the > filesystem/module being available. IDK if that is exactly right, but > if it isn't the worst case is an error message about failing to mount > it. Wouldn't testing the existence of /lib/modules/`uname -r`/kernel/fs/efivarfs/efivarfs.ko be enough, and probably more reliable? (I'm assuming that the test which skips because "fstype not available" comes before the one which skips because "already mounted", and that's why I saw the warning even though it seems to be up and working on my machine.) > For your testing: > > AFAICT it isn't a particularly good idea to just copy the new > mount-functions.sh into /lib but monkey-applying the patch with > > patch /lib/init/mount-functions.sh < > 0001-initsripts-mount-functions-Do-not-check-efivarfs-in-.patch > > worked for me. With those patches (and the bodge in fstab commented > it) it all works. I need to do some other things for a while, so I won't be rebooting again immediately, but I'll probably test this sometime this afternoon. My current biggest concern about this is: -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#783990: efivarfs is a separate fs and needs moutning
I have now tested this. I found that a safety catch in
mount-functions caused it to not work, and this additional patch is
needed.
mount-functions looks in /etc/filesystems and skips mounting things
which the kernel doesn't seem to supoort. In general with so many
filesystems being kernel modules this seems to be of questionable use.
In this case it definitely broke things: I found that mounting the
filesystem with mount(8) auto-loads the module.
I'm using the existence of the mountpoint directory as a proxy for the
filesystem/module being available. IDK if that is exactly right, but
if it isn't the worst case is an error message about failing to mount
it.
For your testing:
AFAICT it isn't a particularly good idea to just copy the new
mount-functions.sh into /lib but monkey-applying the patch with
patch /lib/init/mount-functions.sh <
0001-initsripts-mount-functions-Do-not-check-efivarfs-in-.patch
worked for me. With those patches (and the bodge in fstab commented
it) it all works.
Impact on systems which don't need this efivars FS:
I'm pretty sure it will do the right thing on non-EFI systems
(nothing, silently). I'm also confident that even if it does fail,
the consequences are just a message.
I'm not sure if it will work on non-Linux systems, or indeed whether
it's needed. I think it most likely that they don't have a /sys laid
out like Linux so this won't do anything. Again I think the
reasonable worst-case scenario is a boot-time message and a bug still
unfixed.
Ian.
>From 5ac165a021fd361bad658ff50b59ae3e0c4c478d Mon Sep 17 00:00:00 2001
From: Ian Jackson
Date: Fri, 16 Jul 2021 17:41:25 +0100
Subject: [PATCH] initsripts: mount-functions: Do not check efivarfs in
/proc/filsystems
It is typically loaded on demand so this is not useful.
Signed-off-by: Ian Jackson
---
debian/src/initscripts/lib/init/mount-functions.sh | 5 +
1 file changed, 5 insertions(+)
diff --git a/debian/src/initscripts/lib/init/mount-functions.sh
b/debian/src/initscripts/lib/init/mount-functions.sh
index 73b45a79..709323af 100644
--- a/debian/src/initscripts/lib/init/mount-functions.sh
+++ b/debian/src/initscripts/lib/init/mount-functions.sh
@@ -206,6 +206,11 @@ domount () {
case "$KERNEL" in
*) FSTYPE=$PRIFSTYPE ;;
esac
+ elif [ "$PRIFSTYPE" = efivarfs ]; then
+ # accept efivarfs if its mountpoint exists; kernel will
auto-load the module
+ if test -d /sys/firmware/efi/efivars; then
+ FSTYPE=$PRIFSTYPE
+ fi
elif grep -E -qs "$PRIFSTYPE\$" /proc/filesystems; then
FSTYPE=$PRIFSTYPE
elif grep -E -qs "$ALTFSTYPE\$" /proc/filesystems; then
--
2.20.1
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Bug#783990: efivarfs is a separate fs and needs moutning
On 2021-07-16 at 12:06, Ian Jackson wrote: > Control: tags -1 + patch > Here you go, in diff format and also a file you can just run. I > haven't rebooted with it (yet), but I did manually unmount the > efivars subdir and verify that the new mountkernfs script remounts > it. I've just rebooted, with this in place as /etc/init.d/mountkernfs.sh. (I kept the original around as a renamed file in the same directory.) The boot-time messages - which, unexpectedly and a bit bizarrely, don't seem to be logged anywhere that I'm managing to find - include with the following four lines (transcribed from a photograph taken before launching X), at what appears to be the beginning of the boot process: >> INIT: version 2.96 booting >> Using makefile-style concurrent boot in runlevel S. >> Filesystem type 'efivarfs' is not supported. Skipping mount. ... (warning). >> Starting hotplug events dispatcher: systemd-udevd. Where the string "(warning)." is in orange, rather than the usual whitish gray. /sys/firmware/efi/efivars/ exists and is populated just as on the previous boot, so this didn't break anything, but it also doesn't seem as if it would have helped if that directory hadn't been mounted for other reasons. I notice that the line >>> Registered efivars operations appears in the output of 'dmesg', as well as being present (with similar context) in /var/log/messages* and /var/log/syslog* from at least the past several boots; if the context would be helpful in figuring out when/where/how/by-what this is being mounted, I can share the surrounding lines, or even potentially the entire output if that's considered potentially safe. I'm also willing to consider other steps to track down what's making this work for me, if people care to suggest them. (Unpacking and analyzing the initrd might well be useful, but is more than I'm interested in undertaking just at the moment, although I can probably do it at some point if necessary.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#783990: efivarfs is a separate fs and needs moutning
On 2021-07-16 at 11:54, Thorsten Glaser wrote: > On Fri, 16 Jul 2021, The Wanderer wrote: > >> On Fri, 16 Jul 2021, Ian Jackson wrote: >> >>> On Fri, 16 Jul 2021, The Wanderer wrote: 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. I didn't realize it had actually been scheduled; in my experience, any time someone asks when the release will happen, the only answer is "When it's ready.", and the gap between the ready date becoming known and the release happening tends to be so small there's no room for the question to be asked. 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? I think in principle relying on any specific file inside there would be potentially fragile, but in practice it might be possible to choose something that would be unlikely to go away in later kernels etc.. The attached file contains the requested output. It's not clear immediately whether the UUIDs are machine-specific or will be consistent across machines; efivarfs.rst.txt points me to /usr/share/doc/linux-doc-5.10/Documentation/ABI/stable/sysfs-firmware-efi-vars.gz - which mentions namespacing via vendor GUID, but also seems to say that the items whose names will contain those GUIDs are directories, so I'm not sure whether it's relevant here. >>> 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? On my system, it is not mentioned separately in the output of 'mount'. I think, but am not positive, that that's sufficient indication that it isn't a mountpoint. > Does it always contain an efivars subdirectory? I can't testify one way or the other, but I suspect from the little I've read about this that it does not. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw /sys/firmware/efi: total 0 -r--r--r-- 1 root root 4096 Jul 16 08:23 config_table drwxr-xr-x 2 root root0 Jul 15 18:29 efivars drwxr-xr-x 3 root root0 Jul 16 08:23 esrt -r--r--r-- 1 root root 4096 Jul 16 08:23 fw_platform_size -r--r--r-- 1 root root 4096 Jul 16 08:23 fw_vendor drwxr-xr-x 2 root root0 Jul 16 08:23 mok-variables -r--r--r-- 1 root root 4096 Jul 16 08:23 runtime drwxr-xr-x 19 root root0 Jul 16 08:23 runtime-map -r 1 root root 4096 Jul 16 08:23 systab /sys/firmware/efi/efivars: total 0 -rw-r--r-- 1 root root 14 Jul 15 18:29 AmdAcpiVar-79941ecd-ed36-49d0-8124-e4c31ac75cd4 -rw-r--r-- 1 root root 132 Jul 15 18:29 AMD_PBS_SETUP-a339d746-f678-49b3-9fc7-54ce0f9df226 -rw-r--r-- 1 root root 12 Jul 15 18:29 AMD_RAID-fe26a894-d199-47d4-8afa-070e3d54ba86 -rw-r--r-- 1 root root 1557 Jul 15 18:29 AmdSetup-3a997502-647a-4c82-998e-52ef9486a247 -rw-r--r-- 1 root root8 Jul 15 18:29 AmiHardwareSignatureSetupUpdateCountVar-81c76078-bfde-4368-9790-570914c01a65 -rw-r--r-- 1 root root 28 Jul 15 18:29 AMITCGPPIVAR-a8a2093b-fefa-43c1-8e62-ce526847265e -rw-r--r-- 1 root root 1024 Jul 15 18:29 AOD_SETUP-5ed15dc0-edef-4161-9151-6014c4cc630c -rw-r--r-- 1 root root8 Jul 15 18:29 ApSyncFlagNv-ad3f6761-f0a3-46c8-a4cb-19b70ffdb305 -rw-r--r-- 1 root root5 Jul 15 18:29 asusbkpsmmflag-3eb0ceb0-5890-4853-9a13-0942ec71 -rw-r--r-- 1 root root 20 Jul 15 18:29 AsusRomLayout-2e0585e9-2b5e-4f1e-bbeb-e632c5ef44b8 -rw-r--r-- 1 root root 56 Jul 15 18:29 AutoDetectData-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9 -rw-r--r-- 1 root root 186 Jul 15 18:29 BiosEventLog-4034591c-48ea-4cdc-864f-e7cb61cfd0f2 -rw-r--r-- 1 root root 92 Jul 15 18:29 BiosSettingMappingTable-b57086d5-c2e5-4654-9e3a-0b55830fbb32 -rw-r--r-- 1 root root 122 Jul 15 18:29 Boot-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r-- 1 root root 126 Jul 15 18:29 Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r-- 1 root root6 Jul 15 18:29 BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r-- 1 root root5 Jul 15 18:29 BootFromUSB-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9 -rw-r--r-- 1 root root8 Jul 15 18:29 BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r-- 1 root root8 Jul 15 18:29 BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r-- 1 root root6 Jul 15 18:29
Bug#783990: efivarfs is a separate fs and needs moutning
Control: tags -1 + patch
Thorsten Glaser writes ("Re: Bug#783990: efivarfs is a separate fs and needs
moutning"):
> /sys/firmware/efi does not exist for me.
Cool.
> >> 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.
It turns out that the domount function in mount-functions.sh already
uses a utility called `mountpoint` to check if something is already
mounted, so I think it's probably best just to go with that.
> 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.)
On my EFI system, /sys/firmware is just a directory in /sys. Likewise
/sys/firmware/efi. Ie, the mountpoints are just /sys and
/sys/firmware/efi/efivars (and of course various other things in /sys
like /sys/fs/pstore or whatever).
Indeed, I don't think we can create the efivars subdir.
> 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.
As I say, I don't think we need that. I tested my patched script and
on my system it is silently idempotent.
Also, I looked in mjy /sys/firmware/efivars and OMG. It's full of
crazy stuff with names coming from EFI0land and I don't think there
would be anything sensible to test in it.
> 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.
Here you go, in diff format and also a file you can just run. I
haven't rebooted with it (yet), but I did manually unmount the efivars
subdir and verify that the new mountkernfs script remounts it.
I notice that my added section is very similar to the pstore section
immediately above - and this happened without me copying it :-), which
gives me confidence.
Ian.
0001-mountkernfs-Mount-sys-firmware-efi-efivars-if-necess.patch
Description: Binary data
mountkernfs.sh
Description: Binary data
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Bug#783990: efivarfs is a separate fs and needs moutning
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@tglase-nb:~ $ sudo mount -t efivarfs efivarfs
>>>> > /sys/firmware/efi/efivars
>>>> > mount: /sys/firmware/efi/efivars: mount point does not exist.
>>>> > 32|tglase@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@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/pstorepstore (rw,relatime)
securityfs /sys/kernel/security securityfs (rw,relatime)
tmpfs/tmp tmpfs
(rw,nosuid,nodev,relatime,size=6458640k)
swap /var/cache/apttmpfs
(rw,nosuid,noexec,relatime,mode=755)
tglase@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⎜ Somebody write a testsuite for helloworld :-)
Bug#783990: efivarfs is a separate fs and needs moutning
(For some reason, I haven't gotten the copy of this reply that comes to
me via debian-init-diversity, even though it's clearly Cc'ed to the bug
which appears to send copies to that list. Is something in the chain -
probably BDO - detecting that I'm already in Cc and not sending the
second copy? That would be unfortunate, and a reason for me to return to
replying only to the bug number rather than to the full addressee
list...)
On 2021-07-16 at 11:00, Ian Jackson wrote:
>
> The Wanderer writes ("Re: Bug#783990: efivarfs is a separate fs and
> needs moutning"):
>>
>> I'm not sure what's making the difference (unless this is already
>> fixed for testing, and you're only discussing whether to backport
>> the fix to current stable, which I think doesn't sound like it is
>> the case),
>
> Perhaps the initramfs mounts it ? I can't conveniently check.
A quick grep through /usr and /etc/ for 'efivar' finds one thing that
looks potentially relevant: /etc/apparmor.d/abstractions/libvirt-lxc
includes a mount command for this directory.
(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.)
>> and I'm not sure where to look to try to find out - but whatever
>> fix is found for anyone experiencing this problem, it'll be
>> important to make sure it doesn't break people for whom this *is*
>> working.
>
> Certainly.
>
> I suggest the following approach in mountkernfs:
>
> - 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.
>
> - If that mount fails, print an error message, but otherwise
> do not treat this as an error.
>
> 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 ?
That looks like a reasonable approach to me. I'm not sure exactly what
steps would be necessary to be sure that the reboot was properly testing
the patch, but as long as there's no meaningful risk of putting my
system into an unbootable state (an unlikely-seeming result), I have no
problem with testing this when time permits.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
Bug#783990: efivarfs is a separate fs and needs moutning
The Wanderer writes ("Re: Bug#783990: efivarfs is a separate fs and needs
moutning"):
> I'm not sure what's making the difference (unless this is already fixed
> for testing, and you're only discussing whether to backport the fix to
> current stable, which I think doesn't sound like it is the case),
Perhaps the initramfs mounts it ? I can't conveniently check.
> and I'm not sure where to look to try to find out - but whatever fix
> is found for anyone experiencing this problem, it'll be important to
> make sure it doesn't break people for whom this *is* working.
Certainly.
I suggest the following approach in mountkernfs:
- 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.
- If that mount fails, print an error message, but otherwise
do not treat this as an error.
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 ?
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Bug#783990: efivarfs is a separate fs and needs moutning
On 2021-07-16 at 10:23, Ian Jackson wrote:
> Control: tags -1 patch
>
> Thorsten Glaser writes ("Re: Bug#783990: efivarfs is a separate fs and needs
> moutning"):
>> This is not as easy as it sounds:
>>
>> tglase@tglase-nb:~ $ sudo mount -t efivarfs efivarfs
>> /sys/firmware/efi/efivars
>> mount: /sys/firmware/efi/efivars: mount point does not exist.
>> 32|tglase@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 ?
A possible additional complicating factor: on my system (tracking
current testing, which I suspect is likely to turn into stable fairly
soon), with sysvinit as the active init system, this directory already
exists and is already mounted.
I'm not sure what's making the difference (unless this is already fixed
for testing, and you're only discussing whether to backport the fix to
current stable, which I think doesn't sound like it is the case), and
I'm not sure where to look to try to find out - but whatever fix is
found for anyone experiencing this problem, it'll be important to make
sure it doesn't break people for whom this *is* working.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
Bug#783990: efivarfs is a separate fs and needs moutning
Control: tags -1 patch
Thorsten Glaser writes ("Re: Bug#783990: efivarfs is a separate fs and needs
moutning"):
> This is not as easy as it sounds:
>
> tglase@tglase-nb:~ $ sudo mount -t efivarfs efivarfs /sys/firmware/efi/efivars
> mount: /sys/firmware/efi/efivars: mount point does not exist.
> 32|tglase@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 ?
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Bug#783990: efivarfs is a separate fs and needs moutning
On Fri, 16 Jul 2021, Ian Jackson wrote:
> but the suggestion by Greg Pearson is correct and IMO should be
> applied to mountkernfs.
This is not as easy as it sounds:
tglase@tglase-nb:~ $ sudo mount -t efivarfs efivarfs /sys/firmware/efi/efivars
mount: /sys/firmware/efi/efivars: mount point does not exist.
32|tglase@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).
Nōn-{x86,ARM} systems will likely have the same. Don’t break them.
Meow,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
*
Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter
*
Bug#783990: efivarfs is a separate fs and needs moutning
Control: tags -1 - moreinfo Control: tags -1 + confirmed patch Control: found -1 2.93-8 Control: found -1 2.96-7 I just encountered the lack of evivars when using fwupd to update my laptop firmware from lvfs. My workaround was to put this in /etc/fstab efivarfs/sys/firmware/efi/efivars efivarfs defaults but the suggestion by Greg Pearson is correct and IMO should be applied to mountkernfs. (I felt that Greg's descriptiohn was sufficientlty clear to be worth calling a "patch".) Dmitry wrote: > Hi. As I see on my system, /sys/firmware/efi is now part of /sys: > > $ ls /sys/firmware/efi/ > config_table ... > $ mount | grep efi > /dev/sda1 on /boot/efi type vfat ( But, the relevant directory is /sys/firmware/efi/efivars. not /sys/firmware/efi. The fact that efivars exists in /sys/firmware/efi doesn't tell us that the contents is available. Empirically on this buster system, I needed to manually arrange for the mounting of /sys/firmware/efi/efivars to get fwupd to work. Steve McIntyre confirmed to me on irc that this is a separate filesystem on bullseye too. I looked at the source for sid's sysvinit and its mountkernfs still lacks this. I think it would be worth considering this fix for a stable update, after bullseye is released. Thanks, Ian. -- Ian JacksonThese opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
