I said

otherwise, I don't care.

so yes, you do. See above

now

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)

empty promises?

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.

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?

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...

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...

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.

Did you read this...?

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.

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.

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.

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).

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

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.

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.

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.

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

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:

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.

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.

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.

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.

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

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.)