Aaron Griffin wrote:
Idea #2: $ mv /etc/udev/rules.d/00-load-blacklist.rules /etc/udev/rules.d/00-load-blacklist.rules.disabled in /etc/rc.sysinit, add ". /lib/udev/mod-blacklist.sh" and "export BLACKLSIT MOD_AUTOLOAD" right before the udevd --daemon call comment out the echo lines in the mod-blacklist script if you care
Hopefully the environment vars that udev sees are also seen by scripts that it executes...
Sorry for crossposting, but I couldn't not add some remarks :)
Following discussion on dev mailing list regarding new udev and initscripts, I have one question - why rely on separate blacklist defined in rc.conf ?
modprobe supports blacklisting itself in modprobe.conf (to be precise - it blacklists all aliases for specified modules, which is exactly what's needed here). You can use raw modprobe and probably speed up things nicely, without any extra scripts.
That mod-blacklist.sh will be called on every uevent once - environment is not preserved between uevents (even with line proposed by Aaron), and must be fresh on every uevent.
Btw - you can monitor environment with udevmonitor --env
Is there particular reason, why you use monolithic single udev.rules file ?
Defaults in etc/udev/rules.d and etc/udev/packages are pretty clean and logical (standard rules from udev-118). Also they are split into xy-something.rules files so any specifics you need overridden in Archlinux, can be easily done so, with i.e. last_rule option and separate files. Easier for you to maintain, also easier for users to adjust for their particular needs
Compatiblity rules for loading scsi devices are no longer needed, as far as i know.
Few others can be skipped as well (check 80-drivers.rules for current state, also gentoo 30-kernel-compat.rules for interesting reference).