You are not logged in.
As described here.
I think that deserves an Announcement.
Offline
For those using ArchCK, please wait until 2.6.15-archck3.2 before upgrading. It has the needed patch to operate with the new udev.
iphitus
Offline
moved.
Please everyone read that link provided by tomk, its very short and simple.
Offline
So, udev will not autoload modules anymore, unless we have MOD_AUTOLOAD="yes" ? Is this a "feature" brought by the new udev version, or is arch specific? Also, is there a typo in the post:
>>
MOD_AUTOLOAD="yes"
will activate autoloading modules during boot process
+ autoloading of modules after boot<<
but then,
>>Udev will not load the module for you if autoloading is activated!<<
On the one hand, I am happy to see this was properly announced (as I just realized my external hdd wouldn't show up when turned on).. on the other hand it annoys me that I have to go and replace my MODULES array with MOD_BLACKLIST...
--
Maksim Sipos
Offline
Ok, to all the nay-sayers out there. Yes, udev requires module autoloading activated. This is intentional. If it forces you to auto load on boot, then so be it. That is the way it is intended.
It is assumed that if you are loading you modules manually, then you can also load 'usb-storage' so your usb drives are recognized (for example).
No one needs to create a complicated blacklist. Loaded modules don't take up much space and if they're unused, they take up no cpu time. For me, personally, I only blacklist 'pcspkr', '8139cp', and 'intel-8x0m'.
Offline
Ok, to all the nay-sayers out there. Yes, udev requires module autoloading activated. This is intentional. If it forces you to auto load on boot, then so be it. That is the way it is intended.
From what you are saying, and from what I've gathered from dabbling in /lib/udev and the initscripts, is that you decided that only if MOD_AUTOLOAD is set to yes, udev will autoload the modules. This seems arbitrary to me. Technically I don't see the reason for this (especially because you _can_ control which modules are loaded at boot time, via the blacklist). So, effectively, I don't see how this brought a new feature, except for breaking MODULES.
Arguably one of the coolest and most unique features of Arch, is thereby made practically obsolete. And users who are still using MODULES are forced to mess around with the blacklists, wrong hardware detected, etc... This is even more difficult for people like me, because if something goes wrong with the boot-up of my laptop, I am unable to repair it, since it's one of those tiny laptops without CD or floppy drives. Maybe I should change to a distribution where I am not afraid of screwing up my bootup after every update?
And by the way, adding usb-storage to MODULES doesn't really solve the problem. What is the point of hotplugging then, anyways?
Normally, I am open to fixing up my computers after updates that bring something cool and new to Arch. But I am flabbergasted when we are made to do redundant work to maintain our systems. I see Arch Linux as a distribution for WORKstations, not a playground, and thus I believe Arch developers should have a more careful approach when dealing with init scripts, kernels and such.
--
Maksim Sipos
Offline
Maybe I should change to a distribution where I am not afraid of screwing up my bootup after every update?
By all means, feel free.
Offline
hmm i don't see a problem we are a distro that gives YOU full control about everything, if you don't want autoloading disable it, if you have problems with autoloading, there is the option load_modules=off for boot.
then module loading is completly disabled and you can repair your system real easily.
you can disable modules you don't want/need, what else do you need, it's a very advanced thing.
greetings
tpowa
Offline
First I have not updated to the new udev because I am still trying to figure out, how the new autoloding-stuff fits together.
My sezenario: · I want hotplugging: If the USB camera is plugged in, the correct module should be automaticly loaded.
I guess, MOD_AUTOLOAD should be enabled for this, right?
· Because my hardware changes rarly I never used autodetection like hwd (i do not really like such stuff).
-> Conclusion: I should disable MOD_AUTOLOAD?
· Instead MODULES was an elegant way to load the sparse modules at boot-time.
-> Enable MOD_AUTOLOAD again?
· I am using an custom compiled kernel.
So I need the "uevent patch"? Where can I get it and what purpose has it? (Puh, another patch to care for... )
So maybe someone can clearify my confusion a little.
Offline
[*] Because my hardware changes rarly I never used autodetection like hwd (i do not really like such stuff).
-> Conclusion: I should disable MOD_AUTOLOAD?
[*] Instead MODULES was an elegant way to load the sparse modules at boot-time.
-> Enable MOD_AUTOLOAD again?
[*] I am using an custom compiled kernel.
So I need the "uevent patch"? Where can I get it and what purpose has it? (Puh, another patch to care for...)
[/list]
The cool thing about MOD_AUTOLOAD with udev is, that it is not slower than adding all your modules to MODULES manually. So there is no advantage in that any more, try it, you will see
As for the uevent patch: You can get it from abs, afaik it backports some uevent changes from 2.6.16 to 2.6.15. If you omit the patch, your system will still work (first hand experience) but some udev related stuff will break.
Offline
I guess I should read archlinux news/announcements and pacman messages on what it`s upgrading next time.
I`ve upgraded udev and only then noticed this announcement, so I had to compile 2.6.15 kernel along with my ethernet drivers and upgrade ati drivers.
Not to mention how much stuff I had to dload with my sucky internet.
I know, stupid me, but this was just wrong.
Arch is nice distro (The Best actually). However I don`t see the point of these udev updates. It was working well before, I was able to customize it to fit my needs. It just bought unnecessary mess.
BTW, maybe pacman should ask twice before upgrading critical packages?
Offline
why you had to recompile kernel?
Offline
YOU NEED A KERNEL >= 2.6.15, else udev will not work!!!
And I was running 2.6.14.5 custom becouse my ati drivers would cause hangs on 2.6.15.
However I upgraded both kernel ant ati and it seems to run nicely so far.
Offline
I think I'm only supposed to be posting in this thread if I'm whining or moaning or groaning but it was a perfectly smooth transition and everything is working just as it was.
I am a gated community.
Offline
I think I'm only supposed to be posting in this thread if I'm whining or moaning or groaning but it was a perfectly smooth transition and everything is working just as it was.
Same here, just pacman -Syu and everything worked fine.
Offline
Maybe I'm just a little slow in the head, but I don't really understand what changed. What can't you do now that you were able to do before? I upgraded and changed nothing in my config files (aside from removing the OSS compatibility modules from <code>modprobe.conf</code>) and all seems to be working just fine. I was using the MOD_AUTOLOAD before, which I thought was related to <code>hwdetect</code>...am I just a confused rubbery canine?
Offline
elasticdog,
Originally, MOD_AUTOLOAD controlled whether or not hwdetect loaded modules automatically. With the new udev/initscripts, it actually controls whether or not udev loads modules automatically. I can't find any reference to hwdetect in the initscripts anymore.
Additionally, they made MODULES=(!moduleA) to be identical to MOD_BLACKLIST=(moduleA). This, I suppose, was a largely requested feature from the community.
Offline
Does commenting out the oss modules work too? That's what I did and it seems to work, but my sound card is mute. I umuted it and reset the volume levels with alsamixer, and ran alsctl state as root, but it's a no go, any ideas on my problem?
Edit: alsactl store, not state.
Offline
Penguin removed those lines and then had to put them back. I'm not sure what the reason is that tpowa said it had to be removed.
Dusty
Offline
well here the lines caused trouble and udev loads the compat modules if a sound device is detected.
i have not 1 alsa entry on my systems and everything works on them
Offline
Well I updated ok but net seems to work when it wants maybe clash between 8139 modules :cry:
MODLOAD = "yes" loads everything lol
Mr Green I like Landuke!
Offline
Well I updated ok but net seems to work when it wants maybe clash between 8139 modules :cry:
MODLOAD = "yes" loads everything lol
Add something like this to your modprobe.conf
"alias eth0 8139too"
But use your correct module. Worked for me.
Offline
elasticdog,
Originally, MOD_AUTOLOAD controlled whether or not hwdetect loaded modules automatically. With the new udev/initscripts, it actually controls whether or not udev loads modules automatically. I can't find any reference to hwdetect in the initscripts anymore.
Additionally, they made MODULES=(!moduleA) to be identical to MOD_BLACKLIST=(moduleA). This, I suppose, was a largely requested feature from the community.
Thanks for clearing that up Cerebral. Does that mean we can safely remove <code>hwdetect</code> from our systems?
Offline
no!
hwdetect is used for initrd creation when AUTODETECT=1 is enabled in mkinitrd.conf
Offline
Mr Green wrote:Well I updated ok but net seems to work when it wants maybe clash between 8139 modules :cry:
MODLOAD = "yes" loads everything lol
Add something like this to your modprobe.conf
"alias eth0 8139too"
But use your correct module. Worked for me.
emmm thanks ;-)
Mr Green I like Landuke!
Offline