# How to disable module autoloading?

## Ivan_D

Google just threw a list of useless forum topics.

I need to somehow disable autoloading of alsa modules during startup. I don't have neither alsasound nor alsasound.new scripts loading during boot time.

How?

----------

## Bones McCracker

Probably the most effective way would be to remove alsa support from your kernel.

You can also blacklist the modules (i.e. in modprobe.d).

----------

## Ivan_D

 *Quote:*   

> Probably the most effective way would be to remove alsa support from your kernel. 

  I need alsa. Just want to disable autoload.

 *Quote:*   

> You can also blacklist the modules (i.e. in modprobe.d).

  can u pls point me to a good manual?

----------

## Bones McCracker

 *Ivan_D wrote:*   

>  *Quote:*   Probably the most effective way would be to remove alsa support from your kernel.   I need alsa. Just want to disable autoload.
> 
>  *Quote:*   You can also blacklist the modules (i.e. in modprobe.d).  can u pls point me to a good manual?

 

type "man 5 modprobe.conf"

However, I believe blacklisting the modules will also prevent you from loading the modules manually later.  (It may be possible to blacklist the modules but then load them using aliases; I have never tried this.)

I'm not sure what you're trying to do, but have you tried simply disabling the alsasound init script?

 *Quote:*   

> rc-update -d alsasound

 

or, if you're using the new version

 *Quote:*   

> rc-update delete alsasound

 

If the alsasound service is still getting automatically loaded, you might then try excluding it from plugging.  That's done in /etc/conf.d/rc (or, if you have the new baselayout2/openrc version, it's done in /etc/rc.conf).

Then, when you want sound, you can just load the alsasound service manually:

```
/etc/init.d/alsasound start
```

An alternative that would be a bit more elegant: you might want to create a runlevel for operating without sound (e.g. "default"), and runlevel for operating with sound (e.g. "desktop").  Then, instead of starting alsasound in the boot or default runlevels, just start it in the "desktop" runlevel only.

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=4

To create a new runlevel (e.g. "desktop"), just:

```
cp -R /etc/runlevels/default /etc/runlevels/desktop
```

Then, get rid of the alsasound init script from whatever runlevels it's presently in:

```
rc-update -d alsasound
```

or, if you're using the new version:

```
rc-update delete alsasound
```

Then add the alsasound init script to your new desktop runlevel:

```
rc-update -a alsasound desktop
```

or, if your using the new version:

```
rc-update add alsasound desktop
```

Then, when you want sound, you just type:

```
softlevel desktop
```

or, you can modify your /etc/inittab file to assign the softlevel to actual numbered runlevel:

```
l0:0:wait:/sbin/rc shutdown 

l1:S1:wait:/sbin/rc single

l2:2:wait:/sbin/rc nonetwork

l3:3:wait:/sbin/rc default

l4:4:wait:/sbin/rc default

l5:5:wait:/sbin/rc desktop                   <-------- see here

l6:6:wait:/sbin/rc reboot

#z6:6:respawn:/sbin/sulogin
```

Once you've assigned it to a numbered runlevel, you can switch to the runlevel by simply typing:

```
init 5
```

Also, in your bootloader, you can create a menu option for the new runlevel (in case you want to boot directly into the "desktop" level), by simply duplicating your existing menu option and adding the digit 5 to the end of the bootline.

----------

## Ivan_D

 *Quote:*   

> type "man 5 modprobe.conf" 

  thank you, I'll look into it

 *Quote:*   

> I'm not sure what you're trying to do, but have you tried simply disabling the alsasound init script? 

  I wrote about it in the opening post: I don't have neither alsasound nor alsasound.new scripts loading during boot time. Modules get into the kernel not via an init script.

----------

## matze_na

I'm not 100% sure about this, but I believe the autoloading is udev's "fault", if you want to call it that way.

I had a somewhat related problem a few month ago: The alsa-module for my tv-card sometimes got loaded before the one for my soundcard, resulting in sound screw-ups in various programs.

At first I tried a dozen different configurations for /etc/modprobe.d/alsa.conf which should in theory load the modules in the order i specify there. But none of that really worked, and as far as I understand it, due to the fact that udev loaded the alsa-modules in whatever order it felt like before the alsasound init-script got invoked.

Not wanting to mess around with udev rules, I went ahead and compiled the driver for my soundcard directly into the kernel while leaving the one for the tv-card as a module, which fixed the problem, although it may not be a perfect solution.

Back to your problem: As I explained above, I'd make an educated guess that udev is to fault here.

So unless blacklisting the module does exactly what you want, you should have a look at udev rules  :Wink: 

----------

## gringo

probably a to bloated solution, but grsec ( and rsbac probably too) has an interface which lets you tell the kernel if it is possible to load kernel modules or not. 

Alsa scripts won´t do any difference i think, if udev finds the modules and is configured to load everything it will just go ahead and do so. So, maybe the best workaround is to just move the modules to a place where udev can´t find them ( /root f.ex.) and put them again in place once you need them to be loaded. Ugly, i know, but i don´t know of a better workaround right now. 

cheers

----------

## Bones McCracker

 *matze_na wrote:*   

> I'm not 100% sure about this, but I believe the autoloading is udev's "fault", if you want to call it that way.
> 
> I had a somewhat related problem a few month ago: The alsa-module for my tv-card sometimes got loaded before the one for my soundcard, resulting in sound screw-ups in various programs.
> 
> At first I tried a dozen different configurations for /etc/modprobe.d/alsa.conf which should in theory load the modules in the order i specify there. But none of that really worked, and as far as I understand it, due to the fact that udev loaded the alsa-modules in whatever order it felt like before the alsasound init-script got invoked.
> ...

 

Good point.  I forgot he said he doesn't have any alsa initscripts running.

If the actual alsa modules are getting loaded regardless of whether the alsa init script has run, then udev would be a good thing to look at.

Thanks.

----------

