2

This used to not be a problem, but now it is. I haven't changed anything significant so probably an update broke it.

When I run VeraCrypt it complains that it couldn't set up loop device and suggests running modprobe fuse. Running it doesn't work. However, running modprobe fuse and modprobe loop fixes it, until the next restart.

Shouldn't these modules be loaded automatically at boot? Why not? How do I make them?

ctrl-alt-delor
  • 27,473
  • 9
  • 58
  • 102
Bagalaw
  • 835
  • 2
  • 9
  • 24

2 Answers2

0

fuse and loop can be auto-loaded on demand.

Searching shows that grsecurity kernels may block this. So there is some disagreement about how good an idea this is :-), but I believe it is used on most distributions.

If there is a temporary bug with auto-loading, it is still okay to load fuse and loop at boot time. It would not create a conflict with the auto-loading mechanism. Any module options should get set according to the options lines in /etc/modprobe.d/, no matter who calls modprobe.

E.g. to make sure loop gets loaded

echo 'loop' | sudo tee -a /etc/modules-load.d/modules.conf

How does the auto-loading work? To start with, userspace creates /dev/fuse statically at boot, regardless of whether the module is loaded. The mechanism on my current system is a little baroque - see /lib/systemd/system/kmod-static-nodes.service. So, you have a device node you can try to open. When you do, the kernel calls out to load the module first.

On my system, the list of device nodes which are created statically so you can trigger loading of the appropriate kernel module is

$ cat /run/tmpfiles.d/kmod.conf
c! /dev/fuse 0600 - - - 10:229
c! /dev/btrfs-control 0600 - - - 10:234
c! /dev/loop-control 0600 - - - 10:237
d /dev/net 0755 - - -
c! /dev/net/tun 0600 - - - 10:200
c! /dev/ppp 0600 - - - 108:0
c! /dev/uinput 0600 - - - 10:223
c! /dev/uhid 0600 - - - 10:239
d /dev/vfio 0755 - - -
c! /dev/vfio/vfio 0600 - - - 10:196
c! /dev/vhci 0600 - - - 10:137
c! /dev/vhost-net 0600 - - - 10:238
c! /dev/vhost-vsock 0600 - - - 10:241
d /dev/snd 0755 - - -
c! /dev/snd/timer 0600 - - - 116:33
d /dev/snd 0755 - - -
c! /dev/snd/seq 0600 - - - 116:1
c! /dev/cuse 0600 - - - 10:203

(The d lines are directories).

sourcejedi
  • 48,311
  • 17
  • 143
  • 296
  • "`fuse` and `loop` can be auto-loaded on demand." but they're not on my system. – Bagalaw Jan 24 '19 at 18:43
  • @Bagalaw right, not a complete answer at all. Just the general answer to the "should" question, plus the only reason I know of for answering "no" to the should question. Possibly seeing the mechanism will help think of steps to investigate. – sourcejedi Jan 24 '19 at 18:47
  • There are definitely security concerns about Fuse, which is why grsecurity blocks it. This is due to the the underlying premise of Fuse, not, as far as I know, due to some temporary bug. – Kusalananda Jan 24 '19 at 19:01
  • @Bagalaw regarding your comment on the deleted answer: understanding the mechanisms that load the kernel modules, I would not expect any conflicting options if you arrange for the modules to be loaded manually. I believe the module options should be set according to `options` lines in `/etc/modprobe.d`, regardless of who calls `modprobe`. – sourcejedi Jan 24 '19 at 19:01
  • @Kusalananda no read the link again. grsecurity is just blocking auto-loading. Previous auto-loading concerns have been unprivileged programs causing old network protocols to be loaded into the kernel when they create a socket of the relevant type. where the kernel code may not be very well-maintained. so in some senses you reduce "attack surface" a lot, by only loading modules when root deliberately loads them. – sourcejedi Jan 24 '19 at 19:05
0

You could run commands on startup with a systemd script. Create a file with the contents

modprobe fuse
modprobe loop

in ~/Documents/modprobe_startup.sh (or wherever you want to store it). Dont forget to make it executable with

chmod +x ~/Documents/modprobe_startup.sh

Now we create a simple systemd service file in /lib/systemd/system/modprobe_startup.service with the contents

[Unit]
Description=runs ~/Documents/modprobe_startup.sh

[Service]
Type=simple
ExecStart=/bin/bash /home/USERNAME/Documents/modprobe_startup.sh

[Install]
WantedBy=multi-user.target

Don't forget to replace USERNAME with your system's username.

Now to install,

sudo cp /lib/systemd/system/modprobe_startup.service /etc/systemd/system/modprobe_startup.service
sudo chmod 644 /etc/systemd/system/modprobe_startup.service
systemctl enable modprobe_startup.service

and reboot.

anti4r
  • 71
  • 1
  • 7