Am Mon, 31 Aug 2009 10:24:19 +0200 schrieb Thomas Bächler <thomas@xxxxxxxxxxxxx>: > Tom K schrieb: > > SImplest, most Arch-like solution is to load the modules in the > > required order in the rc.conf MODULES array. > > > > I hope that's what you mean by "manually". :) > > With the asynchronous "trigger && load MODULES=() && settle", there > is no way anymore to ensure module loading order! You need to fix > this using persistent naming schemes, which is easy for network > interfaces. It is also easy on alsa devices (index= option) and hard > drives (uuid, label symlinks). But it's not that easy with evdev devices like mouse and remote control. Unfortunately flyspray is still down. But the /dev/input/eventX bug with the inconsistent device naming for the mouse and the IR remote control is back since the latest initscripts update to 2009.08-1, even if the device naming is not switching at every reboot this time. Sometimes (usually) the mouse is /dev/input/event5 and the remote control is /dev/input/event4 and sometimes it's vice versa. A device in /dev/input/by-path does only exist for the mouse, not for the remote control anymore which was inconsistent anyway because of the order in which the modules cx8800 and cx8802 were loaded. Maybe it helps if udev would be updated to 146. It would be even better if the initscripts would be reverted, so that the order in which modules are loaded can be set in the MODULES array in /etc/rc.conf. As you can see these changes in the initscripts probably make the boot process a bit faster (on fast PCs), but lead to many other serious problems (inconsistencies in ALSA modules, DVB modules, ethernet modules, etc.). And only a few modules like the ALSA modules have and index option. As I've written in flyspray, I'm not really a friend of parallel booting, because it's not really the best idea, leads to inconsistencies and makes booting slower on slow PCs. And I don't think that it's user-friendly if people have to write their own udev rules for every device to get udev consistent. And this is definitively not KISS like. Heiko