Hi all,
Having been bitten by this bug, and having read Michael Biebl's
explanation, I tried to make my system bootable again by blacklisting
the sg module. To my surprise, this didn't work at all!
Digging a bit further, I think I came up with an alternative
explanation. I don't think that kmod-builtin being faster than modprobe
do. The bug was caused in commit [1] by changing
RUN+="kmod sg"
to
RUN{builtin}="kmod load sg"
In particular, the operator was changed from "+=" to "=".
IMHO, that is the actual cause for this bug: whenever a scsi_device
appears, the RUN clause of the generic module loading rule
ENV{MODALIAS}=="?*", RUN{builtin}="kmod load $env{MODALIAS}"
at /lib/udev/rules.d/80-drivers.rules:5, which would have loaded sd_mod,
is overwritten by the RUN clause of the sg-specific rule.
The fix would simply be to change the RUN clause of the sg-specific rule
from
RUN{builtin}="kmod load sg"
to
RUN{builtin}+="kmod load sg"
This change fixes the problem on my system.
What do you think?
Tommaso Colombo
[1]
http://anonscm.debian.org/gitweb/?p=pkg-systemd/systemd.git;a=commitdiff;h=f11a2ddeb6a43f99179f2f9d322ee08cb41db5b0
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
