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?

Improve this question
3
  • Hi Chris, are the /dev/sdd* devices by any chance listed in /etc/fstab ?
    – Marvin
    Commented Mar 15, 2019 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
    Commented Mar 15, 2019 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
    Commented Mar 15, 2019 at 12:49

1 Answer 1

Reset to default
0

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.

  1. Find out where the relevant .mount units are generated, and alter the generator. This will conventionally be systemd-fstab-generator or systemd-gpt-auto-generator. The fact that you cannot find the lines in /etc/fstab that drive the former indicates that it is more likely the latter, or a custom generator of some sort.
  2. Mask the relevant .mount units.

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

Improve this answer
1
  • I bring this (the end of rc.local) up, together with dns resolving issues, as reasons why linux isn't evolving, but actually getting to be more and more spaghetti-code, systemd has become an exploit prone black box for many. If a user or administrator wants to put something in rc.local and no longer can, it's not helpful to force them to first do courses systemd or whatever else you preach in order to achieve the same end-result in days, instead of minutes. Of course, idiots can do stupid things with everything that works well and is easy to work with, that's never a valid argument to end it.
    – Julius
    Commented Sep 18, 2019 at 13:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .