Module parameters from rc.conf in Arch

I have an oddball little tip this time, something that will be either a godsend or something you can conveniently forget. If you’re an Arch user and you find yourself needing to pass parameters to a module, you can do that from within the rc.conf file, instead of relying on /etc/modprobe.d/modules.conf.

For example, forcing an 800×600, 16bpp framebuffer resolution at 60Mhz vertical sync rate with the tridentfb module will require a command like this.

modprobe tridentfb mode=800x600-16@60

Ordinarily I would stuff something like that in /etc/modprobe.d/modules.conf, but I realized the other day that this line from rc.conf will do the same thing.

MODULES=("tridentfb mode=800x600-16@60")

Encapsulating it in quotes allows Arch to handle the entire segment — module and parameters — without a hiccup. You can add other modules as you normally would or blacklist them with the exclamation mark prefix too, and they’ll work just fine.

Like I said, this is something slightly esoteric and might never be of use to you. (It might also be that this is common knowledge and that I’m repeating something everybody already knows. It wouldn’t be the first time. … 😳 πŸ™„ )

On the other hand, if you can pass parameters to a module like this, it means you can rely on rc.conf instead of farming out to other configuration files. And of course, one of the beauties of Arch is the fact that 90 percent of the configuration takes place in that one file. Might as well keep it there. πŸ˜‰

5 thoughts on “Module parameters from rc.conf in Arch

  1. Bryan

    I’ve never heard that this works. From what I’ve seen, most Archers suggest stuffing that into modprobe.d/{modulename}.conf, but it makes perfect sense that this should work. Good tip! Thanks πŸ™‚

    Reply
  2. Adrian

    This is a good principle imho as rc.conf is Arch’s “control panel”, but much more sane.

    Reply
  3. Devin

    For some reason I doubt this is intended behavior… given the quality of their wiki, Arch has very few undocumented features. πŸ™‚ I still think this is a clever little hack though!

    It works because /etc/rc.sysinit executes
    /sbin/modprobe $mod
    for each entry in MODULES instead of /sbin/modprobe "$mod"
    so bash performs word splitting on the parameter expansion of $mod.

    The caveat that should be mentioned is that this will only apply to the “Loading Modules” step at boot time. If you later remove and re-load a module with modprobe, any parameters you set here won’t take. This is probably why the /etc/modprobe.d method is recommended… it’s more likely always to work the way you expect (i.e. “the right way”), and it’s guaranteed not to break if the devs change the above-mentioned rc.sysinit line.

    Cool idea though! If you like it, you could probably even modify the initscripts to autogenerate a custom modprobe.d file from these at bootup… submit a patch, who knows?

    Reply
    1. K.Mandla Post author

      That sounds like a good project for a talented Archer. I will probably surrender that idea to someone else though, because I don’t trust my infantile coding skills to work beyond the confines of my own home. 😳 πŸ™‚

      Reply
  4. Pingback: More goodies for ConnochaetOS « Motho ke motho ka botho

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s