Summary: | madwifi & udev autoloading | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jacek Sieka <arnetheduck> |
Component: | [OLD] baselayout | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | uberlord |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Other | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Jacek Sieka
2006-01-28 14:37:35 UTC
So what exactly is this bug created for? You seem to understand why the initial boot stuff has changed, and the way to prevent the interface from being automatically created if you want to. The bug report is for madwifi and its current way of automatically creating the ath0 interface using wlanconfig and udev. This used to work with the old baselayouts, even when autoloading the module using modules.autoload.d. Right now I have to either reload the module manually every time I reboot my laptop, or create an additional rc-script myself to do it, and I believe this is something the casual user really shouldn't be bothered with. Just installing the madwifi package should "make it work", just as it did before the baselayout changes. So this bug report was really two things, 1) to notify that the new baselayout changes led to problems with other packages (perhaps not only madwifi?), and 2) that madwifi needs a new way of creating ath0, otherwise it won't work for people that autoload the module at startup (which makes an awful lot of sense for me for example, since the wifi card is internal to my laptop, and I use it practically every time I boot my computer). Sorry about the rant at the end of the report though, I do realise it's a bit out of place...I'll leave it at your discretion to reopen the bug or not, although I haven't found anything similar when searching the bugzilla. I hope I was more clear this time. rc-update add net.ath0 default OR use something like coldplug to load the module (and don't use modules.autoload.d) and trigger the chain of events again. The key issue is loading the module AFTER sysinit and you get the exactly the same behaviour you're used to. As coldplug can load the module for you after sysinit then it works :) Heh, yes, I do have net.ath0 in my default startup profile =) Here's the complete story: The madwifi module, when loaded into the kernel, creates a pseudo-interface named wifi0 which is not usable for anything. You then have to run a separate application to create ath0 from wifi0 setting the type of network interface you want (ad-hoc, managed, monitoring, etc etc...don't ask me why the madwifi developers chose to do it like this). The new madwifi packages take this into account and add a udev-rule (in /etc/udev/rules.d) that automatically run this application whenever wifi0 is created. Since the new baselayout blocks udev rules for network interfaces (and this still feels like a hack to me =), it means that ath0 never becomes available for net.ath0 to start since it's never created, and this rule is broken for autoloaded modules. As you say, I *could* install coldplug, but in that case, coldplug should become a dependecy of madwifi-tools (the package that installs the application needed to create ath0 from wifi0), because things *do not work* without it (and to be frank, I really don't want coldplug either, when there's already udev installed on my computer which already did everything I wanted and didn't make my boot any longer that it absolutely had to be), or at least the should be an ewarn advising me to do so when installing the package because now I hade to wade through a bunch of obscure startup scripts and closed bugzilla reports to find out why something that used to work suddenly stopped working. You can always do this in conf.d/net preup() { if [[ ${IFACE} == "ath0" ]] ; then if ! interface_exists "${IFACE}" ; then if ! interface_exists "wifi0" ; then eerror "Cannot create ath0 as wifi0 does not exist" return 1 else wlanconfig command to create ath0 fi fi fi } There's also a wlanconfig baselayout module on bug #120519 which does something similar. If you do re-open this bug, please re-assign to mobile@gentoo.org That's a very neat solution (much neater than whatever I came up with =). I sent a mail to the madwifi maintainer and he agreed with you that this is up to the individual user...thanks for the help, hopefully this will help the next fella with the same problem as well =) |