[arch-general] A little weirdness at boot time

[Heiko Baums]

Am Mon, 31 Aug 2009 10:24:19 +0200
schrieb Thomas Bächler <thomas at archlinux.org>:

> 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