How do I make `modprobe fuse` and `modprobe loop`, persistent?
Clash Royale CLAN TAG#URR8PPP
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?
manjaro fuse loop-device
edited Feb 7 at 11:40
ctrl-alt-delor
11.3k42058
asked Jan 23 at 14:48
BagalawBagalaw
2091313
add a comment |
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?
manjaro fuse loop-device
edited Feb 7 at 11:40
ctrl-alt-delor
11.3k42058
asked Jan 23 at 14:48
BagalawBagalaw
2091313
@Christopher I don't even have/etc/modules/
– Bagalaw
Jan 24 at 16:42
@Christopher No, not really. It makes it even more confusing since it claims everything should be automatically loaded by udev (it isn't).
– Bagalaw
Jan 24 at 17:06
Is your question “How do I makemodprobe fuseandmodprobe loop, persistent.”?
– ctrl-alt-delor
Feb 7 at 11:40
add a comment |
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?
manjaro fuse loop-device
edited Feb 7 at 11:40
ctrl-alt-delor
11.3k42058
asked Jan 23 at 14:48
BagalawBagalaw
2091313
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?
manjaro fuse loop-device
manjaro fuse loop-device
edited Feb 7 at 11:40
ctrl-alt-delor
11.3k42058
asked Jan 23 at 14:48
BagalawBagalaw
2091313
edited Feb 7 at 11:40
ctrl-alt-delor
11.3k42058
asked Jan 23 at 14:48
BagalawBagalaw
2091313
edited Feb 7 at 11:40
ctrl-alt-delor
11.3k42058
edited Feb 7 at 11:40
ctrl-alt-delor
11.3k42058
edited Feb 7 at 11:40
ctrl-alt-delor
11.3k42058
11.3k42058
asked Jan 23 at 14:48
BagalawBagalaw
2091313
asked Jan 23 at 14:48
BagalawBagalaw
2091313
asked Jan 23 at 14:48
BagalawBagalaw
2091313
2091313
@Christopher I don't even have/etc/modules/
– Bagalaw
Jan 24 at 16:42
@Christopher No, not really. It makes it even more confusing since it claims everything should be automatically loaded by udev (it isn't).
– Bagalaw
Jan 24 at 17:06
Is your question “How do I makemodprobe fuseandmodprobe loop, persistent.”?
– ctrl-alt-delor
Feb 7 at 11:40
add a comment |
@Christopher I don't even have/etc/modules/
– Bagalaw
Jan 24 at 16:42
@Christopher No, not really. It makes it even more confusing since it claims everything should be automatically loaded by udev (it isn't).
– Bagalaw
Jan 24 at 17:06
Is your question “How do I makemodprobe fuseandmodprobe loop, persistent.”?
– ctrl-alt-delor
Feb 7 at 11:40
@Christopher I don't even have
/etc/modules/– Bagalaw
Jan 24 at 16:42
@Christopher I don't even have
/etc/modules/– Bagalaw
Jan 24 at 16:42
@Christopher No, not really. It makes it even more confusing since it claims everything should be automatically loaded by udev (it isn't).
– Bagalaw
Jan 24 at 17:06
@Christopher No, not really. It makes it even more confusing since it claims everything should be automatically loaded by udev (it isn't).
– Bagalaw
Jan 24 at 17:06
Is your question “How do I make
modprobe fuse and modprobe loop, persistent.”?– ctrl-alt-delor
Feb 7 at 11:40
Is your question “How do I make
modprobe fuse and modprobe loop, persistent.”?– ctrl-alt-delor
Feb 7 at 11:40
add a comment |
1 Answer
1
active
oldest
votes
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).
"fuseandloopcan be auto-loaded on demand." but they're not on my system.
– Bagalaw
Jan 24 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 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 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 tooptionslines in/etc/modprobe.d, regardless of who callsmodprobe.
– sourcejedi
Jan 24 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 at 19:05
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f496235%2fhow-do-i-make-modprobe-fuse-and-modprobe-loop-persistent%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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).
"fuseandloopcan be auto-loaded on demand." but they're not on my system.
– Bagalaw
Jan 24 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 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 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 tooptionslines in/etc/modprobe.d, regardless of who callsmodprobe.
– sourcejedi
Jan 24 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 at 19:05
add a comment |
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).
"fuseandloopcan be auto-loaded on demand." but they're not on my system.
– Bagalaw
Jan 24 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 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 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 tooptionslines in/etc/modprobe.d, regardless of who callsmodprobe.
– sourcejedi
Jan 24 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 at 19:05
add a comment |
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).
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).
edited Jan 24 at 19:08
community wiki
5 revs
sourcejedi
"fuseandloopcan be auto-loaded on demand." but they're not on my system.
– Bagalaw
Jan 24 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 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 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 tooptionslines in/etc/modprobe.d, regardless of who callsmodprobe.
– sourcejedi
Jan 24 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 at 19:05
add a comment |
"fuseandloopcan be auto-loaded on demand." but they're not on my system.
– Bagalaw
Jan 24 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 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 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 tooptionslines in/etc/modprobe.d, regardless of who callsmodprobe.
– sourcejedi
Jan 24 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 at 19:05
"
fuse and loop can be auto-loaded on demand." but they're not on my system.– Bagalaw
Jan 24 at 18:43
"
fuse and loop can be auto-loaded on demand." but they're not on my system.– Bagalaw
Jan 24 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 at 18:47
@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 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 at 19:01
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 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 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 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 at 19:05
@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 at 19:05
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f496235%2fhow-do-i-make-modprobe-fuse-and-modprobe-loop-persistent%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
@Christopher I don't even have
/etc/modules/– Bagalaw
Jan 24 at 16:42
@Christopher No, not really. It makes it even more confusing since it claims everything should be automatically loaded by udev (it isn't).
– Bagalaw
Jan 24 at 17:06
Is your question “How do I make
modprobe fuseandmodprobe loop, persistent.”?– ctrl-alt-delor
Feb 7 at 11:40