[arch-dev-public] blacklisting issue, perhaps initscripts or kernel 3.0 related

Tobias Powalowski tobias.powalowski at googlemail.com
Mon Aug 1 03:30:27 EDT 2011

Am 31.07.2011 20:49, schrieb Ionut Biru:
> On 07/31/2011 09:46 PM, Tobias Powalowski wrote:
>> Hi guys,
>> https://bugs.archlinux.org/task/25308
>> If I blacklist a module in modprobe.d directory and add it to MODULES=
>> array in rc.conf the module is not loaded anymore.
>> Is there a reason that this is not working anymore?
>> Thanks for your help
>> greetings
>> tpowa
> why would you want to have in blacklist a module that you want to load
> explicitly in MODULES?
To explain it a bit better:
Arch always had the possibility to load modules in a certain order by
using the MODULES= array in rc.conf.

Why would this be useful?
In the past people had more than one soundcard in the pc, the problem by
autoloading modules with udev, could change the order of this sounddevices.
This is not that much a problem anymore, modern systems mostly have only
one soundcard installed.

If you have 2 or more network cards in your pc this might also happen,
which is a more common scenario. Yes you can use udev for assigning the
network names, I preferred the blacklist way with loading it manually
from the MODULES= array.

If more devs say, we don't need the feature of blacklisting and loading
afterwards in MODULES= anymore i'm fine with that.
But we will loose the ability to explicitly load modules in a certain
order forever. UDEV is good in autoloading modules, but sometimes it
might fail and then you have no good way to change that behaviour.

Any other opinions on this?
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
tpowa at archlinux.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-dev-public/attachments/20110801/5ddb6bd5/attachment.asc>

More information about the arch-dev-public mailing list