I can corroborate this bug. I just upgraded to module-init-tools
3.7-pre9-1, and oss-compat 0.0.4+nmu3, and had the exact same thing
happen to me.
I found that the minimal way out of it was to comment out any line
in any /etc/modprobe.d/* file that began with "install" and referenced
any sound-related module. Once I did that, I got the oss-compat postinst
to run to completion cleanly.
Best I can surmise from my process list trace is that anytime you try
to modprobe module A, and module A has an install command of the form:
install A modprobe --ignore-install A && { modprobe --quiet B }
and module B depends on module A based on modules.dep, then the infinite
loop strikes:
modprobe A
install-command for A
modprobe --ignore-install A
modprobe --quiet B
modprobe A
install-command for A
modprobe --ignore-install A
modprobe --quiet B
modprobe A
.... and so on.
It appears to me (in my uneducated, have not looked into it in depth
opinion), that "modprobe A" is running the install command even if
module A is already installed. That would be a sufficient condition to
trigger this bug, when an install rule of the form I mentioned above is
present.
(BTW, Matthew: killall -STOP /sbin/modprobe works wonders in this
situation. ;-)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
