Debian Stretch drop in boot-time script not using rc.local
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
I'm setting up a new installation of Debian Stretch. Because it's on custom NAS box, there's one small gripe I have - original software was booted from a USB memory module molded on to the motherboard. I'm booting Debian from something else, but it automatically recognizes and mounts all partitions from that USB memory. So I was thinking I will cook myself a small script to unmount those partitions and run it from rc.local, except now I found that rc.local is in fact a deprecated backwards compatibility feature for a backwards compatibility feature and should be avoided as such.
So how do I run this small script:
umount /dev/sdd1 /dev/sdd2 /dev/sdd3 /dev/sdd4 /dev/sdd5
At boot time? It's not a daemon so I think it makes no sense to dwell into systemd as suggested for daemon processes in that other question&discussion I found here.
Or maybe there's a way I can prevent Debian from mounting that usb memory to begin with?
debian boot rc.local
edited Apr 4 at 9:39
Rui F Ribeiro
42.1k1483142
asked Mar 15 at 11:09
ChrisChris
61
add a comment |
I'm setting up a new installation of Debian Stretch. Because it's on custom NAS box, there's one small gripe I have - original software was booted from a USB memory module molded on to the motherboard. I'm booting Debian from something else, but it automatically recognizes and mounts all partitions from that USB memory. So I was thinking I will cook myself a small script to unmount those partitions and run it from rc.local, except now I found that rc.local is in fact a deprecated backwards compatibility feature for a backwards compatibility feature and should be avoided as such.
So how do I run this small script:
umount /dev/sdd1 /dev/sdd2 /dev/sdd3 /dev/sdd4 /dev/sdd5
At boot time? It's not a daemon so I think it makes no sense to dwell into systemd as suggested for daemon processes in that other question&discussion I found here.
Or maybe there's a way I can prevent Debian from mounting that usb memory to begin with?
debian boot rc.local
edited Apr 4 at 9:39
Rui F Ribeiro
42.1k1483142
asked Mar 15 at 11:09
ChrisChris
61
Hi Chris, are the /dev/sdd* devices by any chance listed in /etc/fstab ?
– Marvin
Mar 15 at 11:16
AFAIK they're not, that was my first thought. This being a USB device, I think the system recognizes it as nothing more than a partitioned pendrive and treats accordingly. It's funny cause when You open the case and look at the motherboard, it's actually attached to standard usb2.0 pins, but also covered in some gluey mass to prevent it from being detached. Which is infinitely stupid as a way to prevent tampering with the OS knowing that BIOS is wide open and I can change my boot device to whatever I see fit.
– Chris
Mar 15 at 12:11
Gumming up USB connections is more often a way to prevent the connection or substitution of malicious USB devices than a way for preventing the alteration of an operating system.
– JdeBP
Mar 15 at 12:49
add a comment |
I'm setting up a new installation of Debian Stretch. Because it's on custom NAS box, there's one small gripe I have - original software was booted from a USB memory module molded on to the motherboard. I'm booting Debian from something else, but it automatically recognizes and mounts all partitions from that USB memory. So I was thinking I will cook myself a small script to unmount those partitions and run it from rc.local, except now I found that rc.local is in fact a deprecated backwards compatibility feature for a backwards compatibility feature and should be avoided as such.
So how do I run this small script:
umount /dev/sdd1 /dev/sdd2 /dev/sdd3 /dev/sdd4 /dev/sdd5
At boot time? It's not a daemon so I think it makes no sense to dwell into systemd as suggested for daemon processes in that other question&discussion I found here.
Or maybe there's a way I can prevent Debian from mounting that usb memory to begin with?
debian boot rc.local
edited Apr 4 at 9:39
Rui F Ribeiro
42.1k1483142
asked Mar 15 at 11:09
ChrisChris
61
I'm setting up a new installation of Debian Stretch. Because it's on custom NAS box, there's one small gripe I have - original software was booted from a USB memory module molded on to the motherboard. I'm booting Debian from something else, but it automatically recognizes and mounts all partitions from that USB memory. So I was thinking I will cook myself a small script to unmount those partitions and run it from rc.local, except now I found that rc.local is in fact a deprecated backwards compatibility feature for a backwards compatibility feature and should be avoided as such.
So how do I run this small script:
umount /dev/sdd1 /dev/sdd2 /dev/sdd3 /dev/sdd4 /dev/sdd5
At boot time? It's not a daemon so I think it makes no sense to dwell into systemd as suggested for daemon processes in that other question&discussion I found here.
Or maybe there's a way I can prevent Debian from mounting that usb memory to begin with?
debian boot rc.local
debian boot rc.local
edited Apr 4 at 9:39
Rui F Ribeiro
42.1k1483142
asked Mar 15 at 11:09
ChrisChris
61
edited Apr 4 at 9:39
Rui F Ribeiro
42.1k1483142
asked Mar 15 at 11:09
ChrisChris
61
edited Apr 4 at 9:39
Rui F Ribeiro
42.1k1483142
edited Apr 4 at 9:39
Rui F Ribeiro
42.1k1483142
edited Apr 4 at 9:39
Rui F Ribeiro
42.1k1483142
42.1k1483142
asked Mar 15 at 11:09
ChrisChris
61
asked Mar 15 at 11:09
ChrisChris
61
asked Mar 15 at 11:09
ChrisChris
61
61
Hi Chris, are the /dev/sdd* devices by any chance listed in /etc/fstab ?
– Marvin
Mar 15 at 11:16
AFAIK they're not, that was my first thought. This being a USB device, I think the system recognizes it as nothing more than a partitioned pendrive and treats accordingly. It's funny cause when You open the case and look at the motherboard, it's actually attached to standard usb2.0 pins, but also covered in some gluey mass to prevent it from being detached. Which is infinitely stupid as a way to prevent tampering with the OS knowing that BIOS is wide open and I can change my boot device to whatever I see fit.
– Chris
Mar 15 at 12:11
Gumming up USB connections is more often a way to prevent the connection or substitution of malicious USB devices than a way for preventing the alteration of an operating system.
– JdeBP
Mar 15 at 12:49
add a comment |
Hi Chris, are the /dev/sdd* devices by any chance listed in /etc/fstab ?
– Marvin
Mar 15 at 11:16
AFAIK they're not, that was my first thought. This being a USB device, I think the system recognizes it as nothing more than a partitioned pendrive and treats accordingly. It's funny cause when You open the case and look at the motherboard, it's actually attached to standard usb2.0 pins, but also covered in some gluey mass to prevent it from being detached. Which is infinitely stupid as a way to prevent tampering with the OS knowing that BIOS is wide open and I can change my boot device to whatever I see fit.
– Chris
Mar 15 at 12:11
Gumming up USB connections is more often a way to prevent the connection or substitution of malicious USB devices than a way for preventing the alteration of an operating system.
– JdeBP
Mar 15 at 12:49
Hi Chris, are the /dev/sdd* devices by any chance listed in /etc/fstab ?
– Marvin
Mar 15 at 11:16
Hi Chris, are the /dev/sdd* devices by any chance listed in /etc/fstab ?
– Marvin
Mar 15 at 11:16
AFAIK they're not, that was my first thought. This being a USB device, I think the system recognizes it as nothing more than a partitioned pendrive and treats accordingly. It's funny cause when You open the case and look at the motherboard, it's actually attached to standard usb2.0 pins, but also covered in some gluey mass to prevent it from being detached. Which is infinitely stupid as a way to prevent tampering with the OS knowing that BIOS is wide open and I can change my boot device to whatever I see fit.
– Chris
Mar 15 at 12:11
AFAIK they're not, that was my first thought. This being a USB device, I think the system recognizes it as nothing more than a partitioned pendrive and treats accordingly. It's funny cause when You open the case and look at the motherboard, it's actually attached to standard usb2.0 pins, but also covered in some gluey mass to prevent it from being detached. Which is infinitely stupid as a way to prevent tampering with the OS knowing that BIOS is wide open and I can change my boot device to whatever I see fit.
– Chris
Mar 15 at 12:11
Gumming up USB connections is more often a way to prevent the connection or substitution of malicious USB devices than a way for preventing the alteration of an operating system.
– JdeBP
Mar 15 at 12:49
Gumming up USB connections is more often a way to prevent the connection or substitution of malicious USB devices than a way for preventing the alteration of an operating system.
– JdeBP
Mar 15 at 12:49
add a comment |
2 Answers
2
active
oldest
votes
It's not a daemon so I think it makes no sense to dwell into systemd
And that's where you are wrong.
There are two routes to dealing with this, that both involve systemd.
- Find out where the relevant
.mountunits are generated, and alter the generator. This will conventionally besystemd-fstab-generatororsystemd-gpt-auto-generator. The fact that you cannot find the lines in/etc/fstabthat drive the former indicates that it is more likely the latter, or a custom generator of some sort. - Mask the relevant
.mountunits.
The relevant mount units can be discovered with systemctl --all.
Of course, if it transpires that there are no .mount units, then this must be happening as a result of some extra mechanism, perhaps a script that goes and explicitly mounts stuff, which you will simply have to work out how to disable.
Further reading
- https://unix.stackexchange.com/a/425540/5132
- Lennart Poettering et al. (2017).
systemd.mount. systemd manual pages. freedesktop.org. - Lennart Poettering et al. (2017).
systemd-fstab-generator. systemd manual pages. freedesktop.org. - Lennart Poettering et al. (2017).
systemd-gpt-auto-generator. systemd manual pages. freedesktop.org.
answered Mar 15 at 13:08
JdeBPJdeBP
38.1k478185
add a comment |
Avoid calling commands as root in your start RC script!
Try adding such lines in your /etc/fstab :
UUID=2289-0B91 /mnt fat32 defaults,noauto 0 0
noauto should prevent a partition from mounting on startup.
Find UUIDs of your partitions with lsblk -f
answered Mar 15 at 12:29
Possum GalloPossum Gallo
11
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%2f506480%2fdebian-stretch-drop-in-boot-time-script-not-using-rc-local%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
It's not a daemon so I think it makes no sense to dwell into systemd
And that's where you are wrong.
There are two routes to dealing with this, that both involve systemd.
- Find out where the relevant
.mountunits are generated, and alter the generator. This will conventionally besystemd-fstab-generatororsystemd-gpt-auto-generator. The fact that you cannot find the lines in/etc/fstabthat drive the former indicates that it is more likely the latter, or a custom generator of some sort. - Mask the relevant
.mountunits.
The relevant mount units can be discovered with systemctl --all.
Of course, if it transpires that there are no .mount units, then this must be happening as a result of some extra mechanism, perhaps a script that goes and explicitly mounts stuff, which you will simply have to work out how to disable.
Further reading
- https://unix.stackexchange.com/a/425540/5132
- Lennart Poettering et al. (2017).
systemd.mount. systemd manual pages. freedesktop.org. - Lennart Poettering et al. (2017).
systemd-fstab-generator. systemd manual pages. freedesktop.org. - Lennart Poettering et al. (2017).
systemd-gpt-auto-generator. systemd manual pages. freedesktop.org.
answered Mar 15 at 13:08
JdeBPJdeBP
38.1k478185
add a comment |
It's not a daemon so I think it makes no sense to dwell into systemd
And that's where you are wrong.
There are two routes to dealing with this, that both involve systemd.
- Find out where the relevant
.mountunits are generated, and alter the generator. This will conventionally besystemd-fstab-generatororsystemd-gpt-auto-generator. The fact that you cannot find the lines in/etc/fstabthat drive the former indicates that it is more likely the latter, or a custom generator of some sort. - Mask the relevant
.mountunits.
The relevant mount units can be discovered with systemctl --all.
Of course, if it transpires that there are no .mount units, then this must be happening as a result of some extra mechanism, perhaps a script that goes and explicitly mounts stuff, which you will simply have to work out how to disable.
Further reading
- https://unix.stackexchange.com/a/425540/5132
- Lennart Poettering et al. (2017).
systemd.mount. systemd manual pages. freedesktop.org. - Lennart Poettering et al. (2017).
systemd-fstab-generator. systemd manual pages. freedesktop.org. - Lennart Poettering et al. (2017).
systemd-gpt-auto-generator. systemd manual pages. freedesktop.org.
answered Mar 15 at 13:08
JdeBPJdeBP
38.1k478185
add a comment |
It's not a daemon so I think it makes no sense to dwell into systemd
And that's where you are wrong.
There are two routes to dealing with this, that both involve systemd.
- Find out where the relevant
.mountunits are generated, and alter the generator. This will conventionally besystemd-fstab-generatororsystemd-gpt-auto-generator. The fact that you cannot find the lines in/etc/fstabthat drive the former indicates that it is more likely the latter, or a custom generator of some sort. - Mask the relevant
.mountunits.
The relevant mount units can be discovered with systemctl --all.
Of course, if it transpires that there are no .mount units, then this must be happening as a result of some extra mechanism, perhaps a script that goes and explicitly mounts stuff, which you will simply have to work out how to disable.
Further reading
- https://unix.stackexchange.com/a/425540/5132
- Lennart Poettering et al. (2017).
systemd.mount. systemd manual pages. freedesktop.org. - Lennart Poettering et al. (2017).
systemd-fstab-generator. systemd manual pages. freedesktop.org. - Lennart Poettering et al. (2017).
systemd-gpt-auto-generator. systemd manual pages. freedesktop.org.
answered Mar 15 at 13:08
JdeBPJdeBP
38.1k478185
It's not a daemon so I think it makes no sense to dwell into systemd
And that's where you are wrong.
There are two routes to dealing with this, that both involve systemd.
- Find out where the relevant
.mountunits are generated, and alter the generator. This will conventionally besystemd-fstab-generatororsystemd-gpt-auto-generator. The fact that you cannot find the lines in/etc/fstabthat drive the former indicates that it is more likely the latter, or a custom generator of some sort. - Mask the relevant
.mountunits.
The relevant mount units can be discovered with systemctl --all.
Of course, if it transpires that there are no .mount units, then this must be happening as a result of some extra mechanism, perhaps a script that goes and explicitly mounts stuff, which you will simply have to work out how to disable.
Further reading
- https://unix.stackexchange.com/a/425540/5132
- Lennart Poettering et al. (2017).
systemd.mount. systemd manual pages. freedesktop.org. - Lennart Poettering et al. (2017).
systemd-fstab-generator. systemd manual pages. freedesktop.org. - Lennart Poettering et al. (2017).
systemd-gpt-auto-generator. systemd manual pages. freedesktop.org.
answered Mar 15 at 13:08
JdeBPJdeBP
38.1k478185
answered Mar 15 at 13:08
JdeBPJdeBP
38.1k478185
answered Mar 15 at 13:08
JdeBPJdeBP
38.1k478185
answered Mar 15 at 13:08
JdeBPJdeBP
38.1k478185
38.1k478185
add a comment |
add a comment |
Avoid calling commands as root in your start RC script!
Try adding such lines in your /etc/fstab :
UUID=2289-0B91 /mnt fat32 defaults,noauto 0 0
noauto should prevent a partition from mounting on startup.
Find UUIDs of your partitions with lsblk -f
answered Mar 15 at 12:29
Possum GalloPossum Gallo
11
add a comment |
Avoid calling commands as root in your start RC script!
Try adding such lines in your /etc/fstab :
UUID=2289-0B91 /mnt fat32 defaults,noauto 0 0
noauto should prevent a partition from mounting on startup.
Find UUIDs of your partitions with lsblk -f
answered Mar 15 at 12:29
Possum GalloPossum Gallo
11
add a comment |
Avoid calling commands as root in your start RC script!
Try adding such lines in your /etc/fstab :
UUID=2289-0B91 /mnt fat32 defaults,noauto 0 0
noauto should prevent a partition from mounting on startup.
Find UUIDs of your partitions with lsblk -f
answered Mar 15 at 12:29
Possum GalloPossum Gallo
11
Avoid calling commands as root in your start RC script!
Try adding such lines in your /etc/fstab :
UUID=2289-0B91 /mnt fat32 defaults,noauto 0 0
noauto should prevent a partition from mounting on startup.
Find UUIDs of your partitions with lsblk -f
answered Mar 15 at 12:29
Possum GalloPossum Gallo
11
edited Mar 15 at 12:58
answered Mar 15 at 12:29
Possum GalloPossum Gallo
11
answered Mar 15 at 12:29
Possum GalloPossum Gallo
11
answered Mar 15 at 12:29
Possum GalloPossum Gallo
11
11
add a comment |
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%2f506480%2fdebian-stretch-drop-in-boot-time-script-not-using-rc-local%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
Hi Chris, are the /dev/sdd* devices by any chance listed in /etc/fstab ?
– Marvin
Mar 15 at 11:16
AFAIK they're not, that was my first thought. This being a USB device, I think the system recognizes it as nothing more than a partitioned pendrive and treats accordingly. It's funny cause when You open the case and look at the motherboard, it's actually attached to standard usb2.0 pins, but also covered in some gluey mass to prevent it from being detached. Which is infinitely stupid as a way to prevent tampering with the OS knowing that BIOS is wide open and I can change my boot device to whatever I see fit.
– Chris
Mar 15 at 12:11
Gumming up USB connections is more often a way to prevent the connection or substitution of malicious USB devices than a way for preventing the alteration of an operating system.
– JdeBP
Mar 15 at 12:49