sndconfig 'sndcore.o not found in module search path'

sndconfig 'sndcore.o not found in module search path'

Post by Colin Wats » Sun, 31 Dec 1899 09:00:00

>Situation: Upgraded to Redhat 6.1.  Recompiled kernel using 2.2.13pre16 &
>pre17.  Sound stopped working somewhere along the way.  

>Details: Ran sndconfig to reconfigure sound support, instead of doing it
>manually.  Sndconfig reports...

>"You don't seem to be running a kernel with modular sound
>enabled. (soundcore.o was not found in the module search path)."

>...yet, lsmod reports...

>Module                 Size Used by
>ppp_deflate           40548  0 (autoclean)
>bsd_comp               3632  0 (autoclean)
>ppp                   20812  2 (autoclean) [ppp_deflate bsd_comp]
>slhc                   4352  1 (autoclean) [ppp]
>sound                 59096  0 (autoclean) (unused)
>soundcore              2788  3 (autoclean) [sound]
>soundlow                304  0 (autoclean) [sound]

>The sound modules can be unloaded.  Reloading them with insmod
>works without error...

>/sbin/insmod /lib/modules/2.2.13pre17/misc/soundcore.o
>/sbin/insmod /lib/modules/2.2.13pre17/misc/soundlow.o
>/sbin/insmod /lib/modules/2.2.13pre17/misc/sound.o


Sounds like your /etc/conf.modules (or /etc/modules.conf) is broken:
look for the lines beginning with "path". Or you might just need to
run '/sbin/depmod -a' as root.

Colin Watson                                      [cjw44 at]
Trinity College, Cambridge, and Computer Science       []
"Everyone, please welcome our new friend Stef. He's here with us
 because he thinks he's a penguin." -


1. zsh's 'typeset -U path' wipes out path/PATH

I've found a bug (or at best a very perverse "feature") in zsh; it
can be illustrated by the following three short scripts:

# script_A
echo $#path
typeset -U path
echo $#path
# eof

# script_B
source script_A
# eof

# script_C
c_fxn () { source script_A }
# eof

Note that both the contents of script_B and the body of the function
c_fxn defined in script_C consist of the same one line, namely
"source script_A".  Now,

% source script_B
% source script_C

In words, when script_A is sourced within a script that is itself
being sourced, typeset -U path preserves the components of PATH
(or at least their number), but if script_A is sourced within the
body of a *function*, calling the function causes the expression
typeset -U path to *clear* the contents of PATH.

Please-please-please don't tell me this is a feature!  I'd lose
all faith in the designers of zsh if this turns out to be a feature!

More importantly, how does one get around this problem.  I've tried
saving the value of $path before calling 'typeset -U' on it, and
restoring it afterwards, but the results have been disastrous (I've
tried too many variants to describe them all).


NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.

2. Linux on Canon Innova 350CD laptop ?

3. Can't Alter My Path, Can't Find My Path

4. Documentum

5. Sting search w/o 'find' or 'du'

6. Kernel architectures

7. Combining 'find' and 'grep' or searching in general

8. AMS PowerCD Bootdisk needed

9. New kernel stops booting at ''finding module dependencies''

10. Linker can't find libsocket.a - search path problem?

11. Help 'Modprobe Can't find module sound'

12. insmod: 'couldn't find the kernel version the module was compiled for'

13. KDE 'search path'?