referring to /etc/init.d/pcmcia: On 4 Apr 2003, Joshua Legbandt wrote: > My apologies, look for this section: > if [ -d $PC ] ; then > echo -n " modules" > /sbin/modprobe pcmcia_core.o $CORE_OPTS > /sbin/modprobe $PCIC.o $PCIC_OPTS > /sbin/modprobe ds.o > elif [ -d $KD ] ; then > /sbin/modprobe pcmcia_core > /sbin/modprobe $PCIC > /sbin/modprobe ds > else > echo $" module directory $PC not found." > break > fi > > and remove the '.o' from the top section (I think, I added the .o back > in), I should have said pcmcia_core, $PCIC and ds... ok, there is an obvious flaw there as you point out -- modprobe does not work with the filenames themselves that end with .o, only the module name, as in "modprobe ds", as you so astutely observed. argh. that's sure *seems* to be a bug. but it also explains another curiosity that puzzled me. the variables above represent PC: /lib/modules/2.4.20-8/pcmcia "pcmcia" directory KD: /lib/modules/2.4.20-8/kernel/drivers/pcmcia as shipped from RH, shrike has no $PC directory, so the fallback is to use the $KD directory, and everything works. however, building a new kernel and doing "make modules_install" not only creates a new /lib/modules directory, but also creates within it a $PC directory with nothing but symlinks to the actual module files under $KD. potentially convenient, but given the atartup script above, pretty much guaranteed to fail. at least, that's what it looks like. rday p.s. is there any possible rationale for the former set of modprobe calls to refer to files with ".o" suffixes? or is that just flat out a bug?
