During boot on a system with an ipw3945 and ipw3945d that has upgraded to udev-104-r12 will have an ugly error printed out when the module is loaded due to the initscript not being able to be run before the sysinit completes. This is only a minor annoyance, as the everything works perfectly even with it (and the error exists with any version of udev, it's just hidden prior to r12). This was caused by changes to udev to make it work correctly with a silent fbsplash screen, which actually made udev much more verbose in modprobe errors. The solution is to modify the /etc/modules.d/ipw3945d file to redirect output to /dev/null and return a successful exit code, no matter what. The downside is that real errors will be missed, but that would happen anyway with old versions of udev. Tested on amd64 with ipw3945d-1.7.22-r4 with udev-104-r12. Without the fix, big glaring error, ipw3945d autostarts in boot. With the fix, no visible error, ipw3945d autostarts in boot. Same result either way, just no confusing error. Modified /etc/modules.d/ipw3945d is attached.
Created attachment 113610 [details] Fixed /etc/modules.d/ipw3945d
My suggestion is, to let udev call the init-script, that then gets started along with the net and bluetooth init-scripts udev called at end of runlevel boot. Or isn't that possible?
The way I understand it, that would require some entirely new method of calling it when a module is inserted/removed (probably meaning rather heavy changes to either udev or baselayout), since this is currently called using plain old modprobe - the initscripts are simply noting that it 'tried' to start, and then starting it at the proper time in the boot runlevel. Like I noted, this *is* a purely cosmetic error, since it has existed since ipw3945d 1.7.22-r4 was introduced (the first revision where modprobe started the daemon). The only reason this even shows up now is the recent changes to udev for sending all output to the correct console (for silent fbsplash) caused it to, seemingly inadvertently, become more verbose on modprobe errors. The modprobe -q switch (which was added to when modprobe was run in modprobe.sh from udev) only hides missing module errors, from what I tested, and not all errors. If there's an easier, or more proper way, to do this then someone is certainly welcome to find it - but both looking at how udev handles module loading and how modprobe works with ipw3945d, I found this to be the simplest, cleanest solution. As well, from what I tested, it makes the lack of error reporting no worse than when udev itself was hiding the output, instead of modprobe.
Cosmetic workaround for the moment :(. Right now I am using udev-111 (used to give same ugly message), but instead using /lib/udev/modprobe.sh from udev-104-r11 (just seems to sweep it under carpet as said ;-).
I think (up to now masked) udev-115-r5 and later will solve this, as we entirely deleted the modprobe-wrapper, and no longer redirect modprobe output to console.
Fixing per comment #5
