Backtrack:  
 
by lunarg on February 10th 2007, at 19:06

Was upgrading a bit on my laptop (amd64), and this included udev and baselayout.
After a reboot, my whole system did funny things. All was retraceable to one thing: the system was automatically loading modules as it pleases, which caused all kinds of problems...

I have a pretty custom configured system concerning hardware.
By default, I only use wireless, and thus don't load the local netif modules (Realtek 8139) and definitely not the IEEE1394 (Firewire) link, as I very rarely us this for networking (and when I do, it's mainly for high-speed p2p transfer - no I don't have gigabit network).
Secondly, I have both my onboard sound card, as well as my Audigy 2 PCCARD configured. Naturally, the Audigy has to be loaded first, accept when it's not present. This pretty much works automatically: if the Audigy is not present, the default soundcard (card 0) is always the ATI IXP; if the card is present, the ATI becomes card 1.

Now, because of the automatic module loading from udev, all network interfaces were starting up automatically. Gentoo described this neatly as:
device initiated service net.eth0, net.eth1, ... started
I didn't want that, and on top of things, eth0 was the IEEE1394 and eth1 the Realtek. How annoying.
Even worse: the modules for my sound cards were loaded before the alsasound could set the correct order. Since udev loads it in alphabetical order, the ATI got loaded prior to the Audigy, which didn't do at all, as this would mean some serious reconfiguring just about everything that uses sound. Moreover, the Audigy landed on the third place as card 2, as udev saw it fit to load the IXP Modem as card 1, something I never even configured, and am still wondering how the f**k it loaded those modem drivers in the first place.

Anyway, googling to disable automatic module loading was not an easy task, which is something I find very odd. Anyway, after a lot of grumbling on my part, I found the solution in /etc/conf.d/rc, in the form of two variables.

First, the whole device initiated services stuff, which wasn't bothering me all that much, but still, it's nice to have services not started each time you load a module.

Quote
# Do we allow services to be hotplugged? If not, set to RC_HOTPLUG="no"
# NOTE: This does not affect anything hotplug/udev related, just the
# starting/stopping of the init.d service triggered by hotplug.

RC_HOTPLUG="no"

By default, this is set to "yes", so I pretty quickly changed this to "no".

The real issue was this variable.

Quote
# Dynamic /dev managers can trigger coldplug events which cause services to
# start before we are ready for them. If this happens, we can defer these
# services to start in the boot runlevel. Set RC_COLDPLUG="no" if you don't
# want this.
# NOTE: This also affects module coldplugging in udev-096 and higher
# If you want module coldplugging but not coldplugging of services then you
# can set RC_COLDPLUG="yes" and RC_PLUG_SERVICES="!*"

RC_COLDPLUG="no"

Basically, the text above explains it does module and service autoloading/starting, which was the root of all evil: a quick "no" and a reboot later, I was once again free of trouble.

Naturally (well, not really naturally, but still) I had to reconfigure the VMWare modules, because for some reason udev kicked out those vmmon and vmnet device nodes. Sweet, no...?

 
 
« November 2024»
SunMonTueWedThuFriSat
     12
3456789
10111213141516
17181920212223
24252627282930
 
Links
 
Quote
« Most people tend to avoid true conflict. Ironically this breeds more conflict. »