Bugzilla Bug 171295

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 an attachment (id=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