[SOLVED] rc.modules looks to need a little attention.

GazL · 11-12-2014, 03:31 AM

Quote:

Originally Posted by rworkman

Note that loop was removed, as there's /etc/rc.d/rc.loop for that. I don't like it, but it's there.

Yes fair enough. I just can't bring myself to use rc.loop, so I load it from rc.modules (where it belongs). Call it a silly act of rebellion on my part if you want, but I removed rc.loop from my system.

qweasd · 11-12-2014, 09:46 AM

My friend told me, once he had to hack out something totally special because rc.modules did not run soon enough. I, on the other hand, routinely stick modprobes into rc.local, like snd-mixer-oss for conky. rc.loop does look funny

ReaperX7 · 11-12-2014, 11:53 PM

Quote:

Originally Posted by Didier Spaier

Feel free to provide one and maintain it.

And you can't?

gnashley · 11-13-2014, 12:38 AM

rc.loop is nice! Runs nice and early so it is useful in time -and the 'service' can be easily enabled/disabled just like other optional features of init process. I think more stuff which is hard-coded in rc.S/rc.M should be treated the same, in fact -like the silly icon-cache updates...

Didier Spaier · 11-13-2014, 01:38 AM

Quote:

Originally Posted by ReaperX7

And you can't?

Yes I Can™.

But fortunately I have also the freedom of setting my own priorities and the way I spend (or waste, as others may think) my time. At the moment and just in the software field that's mostly leading the Slint project, plus a few tiny activities for (more or less) fun, like adapting eudev for Slackware, or testing usage of syslinux 6.03 for Slackware and maintaining a very few SlackBuilds.

Next task will be to adapt the Slackware or Slint installers for autonomous usage by blind people through usage of brltty.

Then, in no particular order:

adapt Slackware or Slint installers so they can boot on recent Macs,
contribute some documentation to http://docs.slackware.com, like "How to install Slackware on USB sticks and hard disks" or "the lesser known features of the Slackware installer",
Learn the C programming language,
Design an easily searchable and browsable documentation database of all programs contained in Slackware, possibly extendable to third party programs easily accessible from trusted sources,
(in the background) answering questions in this forum, as well as in a few others and mailing lists.

So sorry, maintaining a (documented) list of the roughly 3183 kernel modules shipped in Slackware 14.1 is not in my agenda. I don't need that and I don't think that its usefulness for others is worth the time I would have to spend for that.

But you may of course think otherwise, and decide to do that for Slackware users yourself. Free software is all give and take, after all. In other words sometimes request from others, but also sometimes do it yourself for others.

ReaperX7 · 11-13-2014, 03:35 AM

Sorry but my research into init design frameworks and scripting also is time consuming. Plus there's family time, work, and everything else.

GazL · 11-13-2014, 04:38 AM

Quote:

Originally Posted by gnashley

rc.loop is nice! Runs nice and early so it is useful in time

Or one could simply move the invocation of rc.modules to earlier in rc.S, which is one of the changes I've made to my rc.S. If you like rc.loop then fair enough, each of us have their own preferences and viewpoint, but having a separate rc file invocation just to run a single modprobe command does seem a little wasteful to me.

BTW, I'd have been inclined to just leave it as a kernel built-in for what difference it makes to kernel size.

I agree with the rest of your points though about breaking up rc.S/M.

gnashley · 11-13-2014, 11:05 AM

Yeah, I know it's just a single module, but the loop device is needed very early during bootup, when at all.

pdi · 12-04-2014, 11:27 AM

1. Under what circumstances is the loop device used during boot? A grep -r loop /etc/rc.d/* finds no call.

2. If no modules.dep is found the --quick option creates one, in effect working like --all. Nevertheless, it is perhaps prudent to keep the check of [ -e "/lib/modules/$RELEASE/modules.dep" ].

GazL · 12-04-2014, 11:55 AM

1) I suppose it would be needed if someone has used the 'loop' mount option in fstab to achieve something or other, but whether or not to include a modprobe for loop is down to the user. that was just mine that I posted as an example.

2) Yep, that's just to stop it throwing out an ugly:
"depmod: ERROR: could not fstatat(/lib/modules/3.10.17, modules.dep): No such file or directory"

pdi · 12-05-2014, 04:38 AM

GazL, thanks for your prompt reply.

I was mystified by your error message because I got none, and then I switched from the 13.37 machine to the 14.1 and saw it. You're right, it's ugly. I wonder if using only one line like the one below would cause any immediate harm. (It would, if and when the code of depmod would not be so kind to play safe.)

Code:

depmod --quick > /dev/null 2>&1

On a more general note, if you do a sed '/#/d; /^$/d' /etc/rc.d/rc.modules you get 4 distinct blocks of code: depmod, modprobe, rc.netdevice, and cpufreq.

depmod we've discussed, and rc.netdevice is skipped in /sbin/netconfig.

If the modprobe block is commented out, the only module which doesn't autoload is lp, no great problem. Which brings me to my first question: rworkman wrote that there are very few non-autoloaded modules, and I wonder, is there a way to find them or is that empirical knowhow?

Lastly, on the cpufreq block, a question on method. rc.modules is there to load modules, and on this block we set sysfs values. rc.S runs sysctl immediately after rc.modules. I know of no mechanism for sysfs equivalent to sysctl, but could we perhaps have a dedicated file, say rc.sysfs, called from rc.S?

GazL · 12-05-2014, 05:37 AM

The problem with the >/dev/null 2>&1 approach is that it hides all errors/output, not just the ones you're expecting. I've seen Pat use: some-command 2>&1 | grep -v "expected error text" before to work around that (and it's something I've used myself where its the right approach), but in this case a test -f is just a more efficient approach.

There's no way to find all the non-autoloading modules to the best of my knowledge.

I used to use a rc.cpufreq to load the cpufreq module and set its scaling parameters in sysfs (I don't have it any more as I found cpufreq didn't have much effect on my box). I'm not sure that a more general rc.sysfs is the best idea, but others may disagree. Either way, I don't think that the cpufreq stuff belongs in rc.modules.

GazL · 11-21-2015, 07:31 AM

This still hasn't been addressed yet (as of "Almost a BETA"). Seems somewhat odd for such a simple fix to go this long? Was it forgotten, or was I wrong in my original analysis?

rworkman · 11-21-2015, 05:15 PM

This fell off my radar - sorry. Here's my proposal to Pat; whether he accepts it or not isn't my call. :-)

Code:

# There's an rc.modules.sample in here, stemming from this LQ thread:
  http://www.linuxquestions.org/questions/slackware-14/rc-modules-looks-to-need-a-little-attention-4175483641/
  I think it's a welcome change these days, for the most part, although
  some of my additional stuff might not be. Basically, I get really tired
  of having to delete rc.modules-$oldkernelversions during the -current
  cycle, because I have an rc.modules.local (which basically looks like
  the rc.modules.sample file) anyway. These days, there's pretty much no
  reason to have all of those modules listed, because they're going to be
  loaded automatically by udev anyway. For the few that won't, if we know
  about them, we can list them in that file. The other thing to address
  the old versioned rc.modules files is the rest of the file - basically,
  it shows sysadmins how to load specific modules for only specific kernels,
  which *could* be a valid use case if someone has multiple kernels and
  a modules is only needed by one of them. Perhaps a better way to do it
  would be a stock "rc.modules" file which handles only the depmod stuff
  and then sources rc.modules.local if it exists - we should ship a sample
  copy that would contain the commented non-autoloading modules plus the
  example of how to load a module for only a specific kernel. Thoughts?

Here's the rc.modules.sample:

Code:

#!/bin/sh

# Update module dependencies and load extra (not autoloaded) modules

# Determine the version of the running kernel:
RELEASE=$(uname -r)

if [ -e "/lib/modules/$RELEASE/modules.dep" ]; then
  echo "Updating module dependency list for $RELEASE:"
  /sbin/depmod --quick
else
  echo "Creating module dependency list for $RELEASE:"
  /sbin/depmod --all
fi


# Almost all necessary modules are automatically loaded when needed,
# but there are a few exceptions. Here's a (not all-inclusive) list,
# so uncomment any of the below entries or add others as needed:

#/sbin/modprobe tun            # Universal TUN/TAP device driver
#/sbin/modprobe sg             # Generic SCSI support for SATA DVD-RW


# It's also possible that you need a module loaded for only a specific
# kernel version. Something like this would accomplish it:
#
#if [ "$(uname -r)" = "3.0.0" ]; then
#  /sbin/modprobe somemodule
#fi
#

GazL · 11-21-2015, 06:23 PM

Cheers Robby. So, if I understand you correctly, rc.S would just call rc.modules which would run the fixed version of the depmod code and then source rc.modules.local to process any modprobe lines the local sysadm wants loaded.

That would allow for the rc.S code that calls the various rc.modules* files to be significantly simplified while giving a clear separation between distro maintained (rc.modules) and admin maintained (rc.modules.local) files.

I like it. Lets hope Pat does too.