The officially official Devuan Forum!

fog

Member

Registered: 2017-10-09

Posts: 28  

working method for module blacklisting?

Hello,
I am trying to blacklist few modules: parport_pc, parport, ppdev,lp (important: I am not using initrd in the case if someone asks about updating initramfs)
Unfortunately none of the methods listed work:
/etc/modprobe.d/blacklist.conf
where blacklist.conf is
blacklist parport

or
/etc/modprobe.d/parport.conf
blacklist parport

or adding
modprobe.blacklist=parport
kernel parameter to grub

or setting
skip=
parameter in
/etc/discover-modprobe.conf

the only thing that works is compiling kernel without listed above modules, but then I am getting FATAL errors at boot complaining about missing modules.

I am surprised that parport is so difficult to remove from devuan nowadays when parallel  port is really a dinosaur.

I would appreciate any suggestion.
thank you

Last edited by fog (2017-10-24 18:30:26)

cynwulf

Member

Registered: 2017-10-09

Posts: 234  

Re: working method for module blacklisting?

Disclaimer : it's a few years since I touched Linux...

grep your kernel config for those drivers.  If any are built in rather than compiled as a kernel module (.ko file) then blacklisting won't have any effect.

If some or all are built as a modules, as I recall, another module which isn't blacklisted can still cause a blacklisted module to be loaded - and of course a blacklisted module can still be inserted manually.  In the case of parport, etc, I'm not sure what other modules might cause them to load.

Last edited by cynwulf (2017-10-24 20:17:12)

fog

Member

Registered: 2017-10-09

Posts: 28  

Re: working method for module blacklisting?

Thank you  for helping.
In contrast to OBSD, linux can list modules:
lsmod and then show dependency:
lsmod | grep lp
modinfo -F depends lp

based on this I want disable parport and dependent modules: parport_pc, ppdev, lp

I build my own kernel, but of course checked this. All are modules.
Kernel without these works of course, however during boot it complains about missing modules. I want to get rid of modules and make system happy .

What is interesting is that other distros just let go of whatever I remove from kernel (aside vital parts of course). Devuan seems really attached to parallel port

cynwulf

Member

Registered: 2017-10-09

Posts: 234  

Re: working method for module blacklisting?

Thank you  for helping.
In contrast to OBSD, linux can list modules:
lsmod and then show dependency:
lsmod | grep lp
modinfo -F depends lp

I'm aware of all that - OpenBSD doesn't need to list lkms as there aren't any (historically the functionality was there but lkm support was removed years ago).  FreeBSD and DragonFly have similar tools for loading and listing lkms (kldload, kldstat, etc).

What is interesting is that other distros just let go of whatever I remove from kernel (aside vital parts of course). Devuan seems really attached to parallel port

The Linux kernel is the same, no matter the Linux distribution in use.

I assume the parallel port is completely disabled in the system BIOS / UEFI?  As with it disabled I would guess that the modules should not be loaded regardless?

Last edited by cynwulf (2017-10-25 07:53:58)

fog

Member

Registered: 2017-10-09

Posts: 28  

Re: working method for module blacklisting?

thank you,
this is laptop without parallel port.

while kernel sources are the same, there are really differences how distro handles custom kernel.

Devuan references to parport must be outside kernel. As I mentioned, devuan starts without compiled modules for parport but complains about missing parts, similar kernel in CRUX, Slackware, Funtoo does not.

By the way, I was just kidding about OBSD modules listing (in 90' it actually did list modules as far as I remember but memory not the same anymore)

cynwulf

Member

Registered: 2017-10-09

Posts: 234  

Re: working method for module blacklisting?

If the laptop is without a parallel port then some builtin is loading those lkms.

The difference is in the configuration (or the version) apart from that it's very much the same thing.  You could compare the configs of the kernels in question to see how they differ with regard to IEEE1284/parallel.  It may be a built in driver for a specific controller which is causing those modules to load.

Drivers/hardware is all handled by the kernel, it's how the kernel image has been configured and compiled.  Not knowing precisely how you've configured your custom kernel, it's not easy to say.  However...

If it's still relevant - it may not be, but worth a try - check the file "/etc/modules" or "/etc/modules.conf" to see if any lkms related to the ones in question are being specifically loaded.

(OpenBSD's first release was in 96.  Both OpenBSD and NetBSD hardly made use of lkms anyway (nothing like what Linux does) - I'm not sure if NetBSD still does, in a limited fashion or not at all.  They are - and always will be a security hole - hence why OpenBSD removed the module loader and associated code - being security focused.)

Last edited by cynwulf (2017-10-25 13:59:52)

fog

Member

Registered: 2017-10-09

Posts: 28  

Re: working method for module blacklisting?

If the laptop is without a parallel port then some builtin is loading those lkms.

The difference is in the configuration (or the version) apart from that it's very much the same thing.  You could compare the configs of the kernels in question to see how they differ with regard to IEEE1284/parallel.  It may be a built in driver for a specific controller which is causing those modules to load.

Drivers/hardware is all handled by the kernel, it's how the kernel image has been configured and compiled.  Not knowing precisely how you've configured your custom kernel, it's not easy to say.  However...

If it's still relevant - it may not be, but worth a try - check the file "/etc/modules" or "/etc/modules.conf" to see if any lkms related to the ones in question are being specifically loaded.

(OpenBSD's first release was in 96.  Both OpenBSD and NetBSD hardly made use of lkms anyway (nothing like what Linux does) - I'm not sure if NetBSD still does, in a limited fashion or not at all.  They are - and always will be a security hole - hence why OpenBSD removed the module loader and associated code - being security focused.)

ok,
I apologize for bringing up joke about OBSD and modules. This is really irrelevant to the topic.

I have no clue what Debian/Devuan maintainers did to keep parallel port so persistent. There are other modules that I can efficiently blacklist in devuan. 
Obviously you also have not a clue about this specific issue, so lets leave this at this and leave space for someone who can give me succinct  but working solution.

thank you

cynwulf

Member

Registered: 2017-10-09

Posts: 234  

Re: working method for module blacklisting?

ok,
I apologize for bringing up joke about OBSD and modules. This is really irrelevant to the topic.

No apology was necessary as no offence was taken... I merely responded with a few comments.

I have no clue what Debian/Devuan maintainers did to keep parallel port so persistent. There are other modules that I can efficiently blacklist in devuan.

As I said, they may have compiled in the modules which load the modules... or the OS may be explicitly loading those modules via some modprobe configuration.

Obviously you also have not a clue about this specific issue, so lets leave this at this and leave space for someone who can give me succinct  but working solution.

thank you

With that kind of attitude, good luck on finding someone to hold your hand and spoon feed you with a "solution"...  If you're going to build your own kernel, the problems that you come across are your problems and any input from other users, using their time to assist you is a bonus.

fog

Member

Registered: 2017-10-09

Posts: 28  

Re: working method for module blacklisting?

this is what is wrong with your help (I don't mean to offend)
in the first post I clearly stated that I do use custom kernel.

the only thing that works is compiling kernel without listed above modules, but then I am getting FATAL errors at boot complaining about missing modules.

If you red it carefully I assume you would not bother with help:

If you're going to build your own kernel, the problems that you come across are your problems and any input from other users, using their time to assist you is a bonus.

Aside from personal point of view regarding custom kernels (which are unnecessary), comparing system behaviour under default Devuan kernel or custom let me eliminate kernel as a possible culprit (I always keep original kernel as a backup). If fact if you would read my first post carefully (assuming help) you would know that I did eliminate any standard files that may have anything to do with modules loading.

I was asking then what nonstandard file is hidden in devuan that may force loading of specific modules because as I pointed before:

There are other modules that I can efficiently blacklist in devuan.

From your posts I did not learn anything valuable (again no offense).

OBSD history is available at wikipedia, while I unnecessary mentioned OBSD, I did not make any errors that should be corrected by citing internet source. However, this is my mistake.

I understand that you wanted to help but whole purpose of my thread  got almost certainly lost now.

Recently I had some issues with solaris. After submitting questions at solaris forum, I got plenty of help.. as yours. That is not much real info. Eventually one of solaris maintainers got involved at in short post pointed me to the solution.

so thank you again, I appreciate what you trying to do but this goes nowhere. Let's wait and hope that someone knows the answer. If no solution is suggested, I can live with parport module as it is.

golinux

Administrator

Registered: 2016-11-25

Posts: 3,318  

Re: working method for module blacklisting?

While there may be some truth in what you're saying, you might want to re-think your attitude towards cynwulf. Also here.  He is not someone to be trivialized.   He's been around for a long time and has earned my respect over the years.  I am delighted that he has found his way here . . .

---

Get answers - Help Devuan - Report a bug - Search packages

fog

Member

Registered: 2017-10-09

Posts: 28  

Re: working method for module blacklisting?

yes,
and all started with simple question about module blacklisting.
I really appreciate your help. I don't know what to say. I am not trying to be rude. I appreciate experience. Sorry?

Still I have no solution. Let's drop it. If Devuan can't leave without parport, then I will leave it be. This is not such a big deal.

golinux

Administrator

Registered: 2016-11-25

Posts: 3,318  

Re: working method for module blacklisting?

You might also ask on the DNG mail list.  Or on freenode #devuan

---

Get answers - Help Devuan - Report a bug - Search packages

ralph.ronnquist

Administrator

From: Battery Point, Tasmania, AUS

Registered: 2016-11-30

Posts: 1,253  

Re: working method for module blacklisting?

Someone on a not dissimilar platform had success with the problem in 2009:
https://ubuntuforums.org/showthread.php … 455&page=2
The key was to "also disable loading lp module in default configuration of cups in /etc/default/cups".

ralph.ronnquist

Administrator

From: Battery Point, Tasmania, AUS

Registered: 2016-11-30

Posts: 1,253  

Re: working method for module blacklisting?

Since I (and you?) don't have cups, disabling it for cups is not a solution.

I managed to get the (standard) ASCII 4.9.0-4-amd64 kernel to avoid loading parport and friends by having boot parameter

lp=none

together with blacklisting:

# echo blacklist parport > /etc/modprobe.d/blacklist-parport.conf
# echo blacklist parport_pc >> /etc/modprobe.d/blacklist-parport.conf
# update-initramfs -u

It needs both kernel parameter and blacklisting. Possibly lp=0 would work as well, but I couldn't bother testing it.

cynwulf

Member

Registered: 2017-10-09

Posts: 234  

Re: working method for module blacklisting?

this is what is wrong with your help (I don't mean to offend)
in the first post I clearly stated that I do use custom kernel.

I knew you'd built a custom kernel as you stated that you had not used an initrd.  I used Linux since around 2002 and used Slackware and Debian for years - I understood your post.  What I'm not familiar with is some of the newer tools and especially systemd - hence the disclaimer.  I volunteered help/advice because you were building a custom kernel - but no I'm not volunteering a hand holding session and all out solution.  If that were your requirement you should have specified from the start.  I usually equate those who build their own kernels as tinkerers and wanting to learn. i.e. I assume they'd be willing to engage and not wanting a quick fix to their self made problem.

If you're going to build your own kernel, the problems that you come across are your problems and any input from other users, using their time to assist you is a bonus.

Did you read this...?

Aside from personal point of view regarding custom kernels (which are unnecessary), comparing system behaviour under default Devuan kernel or custom let me eliminate kernel as a possible culprit (I always keep original kernel as a backup). If fact if you would read my first post carefully (assuming help) you would know that I did eliminate any standard files that may have anything to do with modules loading.

Whether the standard kernel exhibits the behaviour or not, this is still your custom kernel and your effort to prevent loading of lpt/IEEE1284 drivers.  I was attempting to give some advice on that.  I apologise if this forum and the WWW as a whole cannot provide only the perfect responses tailored for you specifically and in such a way as to not offend your delicate sensibilities.

I was asking then what nonstandard file is hidden in devuan that may force loading of specific modules because as I pointed before:

There are other modules that I can efficiently blacklist in devuan.

And I pointed you to modprobe configuration.  That is where kernel modules would be explicitly loaded.  Debian used to add quite a few there, other distributions do not as I recall.  Also a particular built in module can still cause a blacklisted module to load.  A different distribution's kernel could differ in this way.

From your posts I did not learn anything valuable (again no offense).

Well that's not surprising, as you clearly don't want to learn.  You made it clear in a certain post that a "succinct solution" was desired.

OBSD history is available at wikipedia, while I unnecessary mentioned OBSD, I did not make any errors that should be corrected by citing internet source. However, this is my mistake.

As I said, no offence was taken regarding the references to OpenBSD, it's you bringing it up again and again, you made some comments and I responded.  You seemed to take exception to being corrected and having your nose put out of joint.  Reading Wikipedia won't tell you much about OpenBSD, though as you've no real interest in it, I'm not sure why you'd be reading about it anyway).

I understand that you wanted to help but whole purpose of my thread  got almost certainly lost now.

Not really, but just make it clear next time and subtitle your thread "succinct solutions only please".

Recently I had some issues with solaris. After submitting questions at solaris forum, I got plenty of help.. as yours. That is not much real info. Eventually one of solaris maintainers got involved at in short post pointed me to the solution.

Seems anecdotal, but from what you've said, I'm not surprised.  If you go to any *nix forum with an attitude like you've displayed here, the result will be the same almost every time.  I am usually thankful for any help I receive even if it's a pointer in the right direction or someone just making the effort and using their time.

Last edited by cynwulf (2017-10-26 10:25:04)

cynwulf

Member

Registered: 2017-10-09

Posts: 234  

Re: working method for module blacklisting?

Someone on a not dissimilar platform had success with the problem in 2009:
https://ubuntuforums.org/showthread.php … 455&page=2
The key was to "also disable loading lp module in default configuration of cups in /etc/default/cups".

Amazing that searching the web yielded some results...

Possibly lp=0 would work as well, but I couldn't bother testing it.

According to the Linux man page bootparam(7) lp=0 is correct. lp=none would only disable the first parallel port, not the driver. (yes, in 99% of cases, you may have only one port, but lp=0 seems correct - may avoid the need to blacklist modules as well - worth trying anyway).

Anyway as my continued presence is clearly a barrier to the "solutions" flooding in, I'll bow out at this point...

Last edited by cynwulf (2017-10-26 10:18:10)

fog

Member

Registered: 2017-10-09

Posts: 28  

Re: working method for module blacklisting?

Since I (and you?) don't have cups, disabling it for cups is not a solution.

I managed to get the (standard) ASCII 4.9.0-4-amd64 kernel to avoid loading parport and friends by having boot parameter

lp=none

together with blacklisting:

# echo blacklist parport > /etc/modprobe.d/blacklist-parport.conf
# echo blacklist parport_pc >> /etc/modprobe.d/blacklist-parport.conf
# update-initramfs -u

It needs both kernel parameter and blacklisting. Possibly lp=0 would work as well, but I couldn't bother testing it.

Thank you, this is how I understand help.
Unfortunately it did not help.
If you look at the boot process [Info] loading lp, [Info] loading parport and [Info] loading parport_pc appear before kernel variables. Someone just went overboard to make sure that lp is loaded. At this point this is just funny.
I give up. No point to bother Devuan devs. This is too small thing to be concerned about.

@cynwulf
Man you are incorrigible.
I started using computers probably long before you were born and before phrase "personal cumputers" was used for the first time, that is in mid 70'. In high school we had obligatory (then called informatics)  programming held at the university (that was really advanced high school). I went through VAX, early Sun, NetWare, bunch of BSDs, linuxes, Be, Apple products, DOS and Windows systems plus some other stuff I don't even remember.

Personally, when I help then I keep my opinions to myself, so should you. That is for the best and this is what you should learn still. Your sarcasm is misplaced and coming (probably) from hurt pride (I assume because I did not appreciate your knowledge you graciously pour on me) but:
1) I don't care
2) sarcasm in this situation would make sense if you would provide working solution. You did not.
3) at this point your comments are just annoying irrelevant of how long you've been using computers
4) lesson for me: don't ask for help

I think that this topic should be closed because no solution can be found and too much misplaced ambitions hijack the topic of this thread.

Is there "topic closed" button somewhere?

Last edited by fog (2017-10-26 13:10:45)

cynwulf

Member

Registered: 2017-10-09

Posts: 234  

Re: working method for module blacklisting?

I started using computers probably long before you were born[etc]

I'm about to cease participation in this thread.  Getting the impression I've outstayed my welcome...

I generally don't get into dick waving, "I used computers long before you" style arguments, but bear in mind that you know nothing about me nor how long I've been using computers for.  Plus there are "youngsters" today, who know more about computing than most of us - and I have no trouble admitting that.  I've been around quite a while and I've seen plenty of users you who ask for a solution, then pull out "credentials" and the old "x years of experience" bullshit.  If you know vastly more about computing than I do, I don't have a problem with that.

And though you weren't keen my direct approach, I did not set out to offend and only used one piece of sarcasm.  Your snide comments regarding wikipedia scanning, didn't go unnoticed.  It's "the mote and beam" mate.

There is no hurt pride (or fragile ego) to protect here at least.  Have a nice day.

Last edited by cynwulf (2017-10-26 14:22:00)

fog

Member

Registered: 2017-10-09

Posts: 28  

Re: working method for module blacklisting?

because:

I used Linux since around 2002 and used Slackware and Debian for years .

I said

I started using computers probably long before you were born and before phrase "personal cumputers" was used for the first time, that is in mid 70'. In high school we had obligatory (then called informatics)  programming held at the university (that was really advanced high school). I went through VAX, early Sun, NetWare, bunch of BSDs, linuxes, Be, Apple products, DOS and Windows systems plus some other stuff I don't even remember.

otherwise, I don't care.

I generally don't get into dick waving,.

so yes, you do. See above

now

According to the Linux man page bootparam(7) lp=0 is correct. lp=none would only disable the first parallel port, not the driver. (yes, in 99% of cases, you may have only one port, but lp=0 seems correct - may avoid the need to blacklist modules as well - worth trying anyway).

passing lp=0 does not work as I explained above. As an expert you should know this reading one of my posts. If you correct someone, do it properly. To make it plain:
You should say
lp=0 does this but it will not work in this case because of this done (I bet you knew it already)

Anyway as my continued presence is clearly a barrier to the "solutions" flooding in, I'll bow out at this point...

empty promises?

golinux

Administrator

Registered: 2016-11-25

Posts: 3,318  

Re: working method for module blacklisting?

Enough is enough.

---

Get answers - Help Devuan - Report a bug - Search packages