why is /etc/init.d/pcmcia still "broken"?
Robert P. J. Day
rpjday at mindspring.com
Tue Jan 6 09:38:31 UTC 2004
having just built a new 2.4.22-2135 kernel under a new install of FC1, i
was puzzled as to why my linksys pcmcia wireless card didn't come up at
boot time. or any pcmcia functionality, for that matter. having been
down this road before with the 2.5/2.6 kernels, i quickly tracked it down
to the same old problem with the /etc/init.d/pcmcia file.
if [ -d /lib/modules/preferred ] ; then
PC=/lib/modules/preferred/pcmcia
else
PC=/lib/modules/`uname -r`/pcmcia
fi
KD=/lib/modules/`uname -r`/kernel/drivers/pcmcia
if [ -d $PC ] ; then
echo -n " modules"
--> /sbin/modprobe pcmcia_core $CORE_OPTS # fixed
--> /sbin/modprobe $PCIC $PCIC_OPTS # fixed
--> /sbin/modprobe ds # fixed
elif [ -d $KD ] ; then
/sbin/modprobe pcmcia_core
/sbin/modprobe $PCIC
/sbin/modprobe ds
else
echo $" module directory $PC not found."
break
fi
the lines above originally had references to pcmcia_core.o,
$PCIC.o and ds.o, which is syntactically invalid for the current
modprobe command. things work fine for a fresh install, but will
fail the first time you build a new kernel since installing the
modules will create the directory /lib/modules/`uname -r`/pcmcia,
which changes the boot-time logic and, consequently, no PCMCIA.
i recall finding this, and reporting it long ago, for the 2.5
kernel series. i didn't expect to find it still a problem in FC1.
what's the official party line on this? in short, how can this
startup file *possibly* work after someone creates and installs
a new kernel and modules?
this problem was acknowledged long ago. what's it still doing
there?
rday
p.s. i tried to do a quick bugzilla query on this, but even the
broadest queries against FC1 turn up nothing, even though i *know*
there have been submissions against this issue in the past.
More information about the fedora-list
mailing list