Am 09.02.21 um 23:18 schrieb Mike Gilbert:
On Tue, Feb 9, 2021 at 11:47 AM Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote:
Am 09.02.21 um 17:13 schrieb Mike Gilbert:
On Tue, Feb 9, 2021 at 6:17 AM Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote:
Am 08.02.21 um 23:42 schrieb Mike Gilbert:
On Mon, Feb 8, 2021 at 2:31 PM Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote:
I think removing this symlink would prevent /sys/fs/fuse/connections
from being mounted and the fuse module from being loaded
unconditionally on boot
no
https://bugzilla.redhat.com/show_bug.cgi?id=1909805#c6
It almost works for me on Gentoo Linux.
To test, I first had to reconfigure my kernel to build FUSE as a
module (I normally have it built-in).
I then removed the sys-fs-fuse-connections.mount symlink from
sysinit.target.wants.
After rebooting with the new kernel, the FUSE module is not loaded and
/sys/fs/fuse/connections is not mounted.
Unfortunately, mounting FUSE-based file systems does not work until I
manually run "modprobe fuse".
It seems that my kernel does not auto-load the module, despite the
static /dev/fuse node. The kernel is probably missing a call to
__request_module().
Given that the kernel doesn't auto-load the module on demand, leaving
the sysinit.target.wants symlink in place seems like the safe thing to
do.
but for sure not on a stripped down machine running a iptables-nft
ruleset, a socket-activated sshd and nohting else
if it's me for server setups the "fuse" kernel-module could be in
"kernel-modules" which is not installed and needed for virtualized guests
the point is that all this setups where happy without fuse loaded from
2008 to 2021 and you can't even avoid it with F33 at all, no matter what
you delete or mask
a active masked unit - seriously? :-)
[root@rawhide ~]# systemctl status sys-module-fuse.device
sys-fs-fuse-connections.mount
● sys-module-fuse.device - /sys/module/fuse
Loaded: masked (Reason: Unit sys-module-fuse.device is masked.)
Active: active (plugged) since Mon 2021-02-08 19:33:18 CET; 1min
42s ago
Device: /sys/module/fuse
I think something else on your system is loading the fuse kernel
module, which activates sys-module-fuse.device, and tries to start
sys-fs-fuse-connections.mount. It appears systemd doesn't really
support masking device units, which are generated by udev events.
You should probably try to track down exactly what else is loading the
fuse module, and disable that.
this is a bare setup with *nothing* enabled at all
Off the top of my head, maybe fuse is getting loaded by an entry in
modules-load.d.
no
[root@rawhide ~]# ls /etc/modules-load.d/
total 0
Also, vmware tools might utilize FUSE in some way.
no
[root@rawhide ~]# system-errors.sh
Feb 10 00:59:22 rawhide systemd[1]: sys-module-fuse.device: Failed to
enqueue SYSTEMD_WANTS= job, ignoring: Unit sys-fs-fuse-connections.mount
is masked.
[root@rawhide ~]# systemctl status vmtoolsd.service
● vmtoolsd.service - VMware Tools
Loaded: loaded (/etc/systemd/system/vmtoolsd.service; disabled;
vendor preset: enabled)
Active: inactive (dead)
even that file from the vmtools package was deleted long before my
initial post of this thread
[root@rawhide ~]# cat /usr/lib/systemd/system/run-vmblock\x2dfuse.mount
cat: /usr/lib/systemd/system/run-vmblockx2dfuse.mount: No such file or
directory
If you're unable to figure out what is loading it, you might replace
/sbin/modprobe with a wrapper script to log all processes that call
it
there is nothing left but systemd which also don't go the normal way
otherwise this below would prevent loading the kernel module
modprobe won't load it in that case
[root@rawhide ~]# cat /etc/modprobe.d/blacklist-lounge-vm.conf | grep fuse
blacklist fuse
install fuse /usr/bin/true
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
