I'm filing this as a new bug report, even though I have figured it out (see the summary and below) and solved it by now, and though it is quite similar to bug 4819; the reason it that I believe it IS a bug (whereas 4819 is classified NOTABUG), and because it had got me puzzled for a long time. I'll start with the description I had written before I had found it out: After upgrading to kernel 2.2.12 (with corresponding new initscripts), I found that sound was no longer functioning, and errors pertaining to sound modules were signalled during bootup. So I renamed /etc/isapnp.conf and /etc/conf.modules so as to begin with a clear slate, and ran sndconfig (also form redhat 6.1, version sndconfig-0.38-1). It starts correctly recognising the sound card, a Creative ViBRA16X PnP. Then it goes on to play a sound sample, which fails, with the message: The following error occurred running the modprobe program /lib/modules/2.2.12-20/misc/sound.o: a module named sound already exists soundcore: Device or resource busy sound: No such file or directory Exiting sndconfig at this point leaves the following file /etc/conf.modules (I don't include /etc/isapnp.conf, as it is quite long): alias sound sb pre-install sound /sbin/insmod sound dmabuf=1 alias midi opl3 options opl3 io=0x388 options sb io=0x220 irq=5 dma=1 mpu_io=0x330 Leaving this file as it is causes the same error found by sndconfig to be reported at boot time, and sound does not function. The error message issued by modprobe is understandable, since one can find in /lib/modules/2.2.12-20/misc/ files names sb.o AND sound.o; therefore the line `alias sound sb' seems to be doing something that is not in order. Indeed, by changing "sound" in that line, and its first occurrence in the next line, into something that does not correspond to an existing module (the name I tried was "soundcard"), one succeeds in getting sound to function; one must also make this substitution in /etc/rd.d/rc.sysinit. The program /sbin/modprobe I used is from modutils-2.1.85-4, not from the latest version modutils-2.1.121-14 shipped with redhat 6.1. To my surprise (because it seemed the the problem was a badly chosen alias name, not the functioning of modutils) the problem disappeared when I finally got around to upgrading modutils. Note however that I had not broken any recorded dependency by upgrading initscripts and sndconfig without changing modutils. In fact the dependency in initscripts explictly states "modutils >= 2.1.85-3", so it should have worked withmodutils-2.1.85-4; sndconfig does not mention modutils at all (I think it should though, as it is calling modprobe). I hadn't initially upgraded modutils, as it depends on vixie-cron, whose rpm I had not fetched because nothing in its description suggested that it was essential for properly functioning a basic system. So two questions remain, for which I would like to know the answer. First, why dosndconfig/rc.sysinit choose an alias name that conflicts with an existing kernel module, while (it seems to me) any other name would do better? And was modprobe specially modified to allow such practice, just so that there could be a gratuitous incompatibility with older versions? Second, why do sndconfig and initscripts not declare their dependency on a recent version of modutils, while they seem to deliberatly exploit a recently added feature? In fact this is far from the only case where upgrading on a package-by-package base, without _ever_ overriding dependencies, broke some part of the system; almost every functionality that I normally depend on has been broken at some point. I am tempted to conclude that either (1) RPM technology is incapable of describing the kind of dependencies that actually exist between packages in a redhat system, or (2) RedHat doesn't really care about properly recording dependencies because they want people to buy a boxed set (for every new release) and than either do a completely new install, or at best an upgrade in one fell swoop (cross your fingers, emergency power generator on stand-by) from CD.
The alias is named that way for backwards compatibility. That's what the sound module was if you compiled it as one big module back in the 2.0 days. Also, up until recently, if the kernel tried to open a sound device when none was loaded, it would try and load the 'sound' module. Hence that alias. As for exploiting that feature of modutils, it was because we didn't know that it broke on older modutils releases.
In any case, this behavior will be fixed in sndconfig-0.40-1, which will use the 'sound-slot-0' alias.