(storner@osiris.ping.dk)
(laveneno@hotmail.com)
Este documento explica como puede usar kerneld en los kernel Linux. Describe
La última versión de este documento en su versión original en Inglés puede encontrarse en http://eolicom.olicom.dk/~storner/kerneld-mini-HOWTO.html. Entre entregas de este mini-HOWTO puede encontrar las modificaciones en mi lista de cambios http://eolicom.olicom.dk/~storner/kern.html (sin estructurar).
N. del T.- La última versión de la traducción de este documento puede encontrarse en el ftp de INSFLUG (Impatient and Novatous Spanish Fidonet LiNUX Users Group) http://www.insflug.nova.es.
Si usted lee alguna cosa incorrecta en de este documento, envíe un mensaje electrónico al autor. Las siguientes personas han contribuido de alguna manera en este mini-HOWTO:
bj0rn@blox.se
.bgallia@luc.edu
.cedric@earthling.net
.bmiller@netspace.net.au
.jtsiao@madoka.jpl.nasa.gov
.El autor, al igual que el traductor, apreciarían mucho los ánimos y las sugerencias enviadas por los lectores de este mini-HOWTO.
Kerneld es una característica introducida durante el desarrollo
de los kernels 1.3 por Bjorn Ekwall (bj0rn@blox.se
). Se
incluye en todos los kernels 2.0 y 2.1 . Permite que los ``módulos''
del kernel - por ejemplo drivers de dispositivos, red o sistemas
de ficheros - sean cargados automáticamente cuando sea necesaria
su utilización, en vez de tener que hacerlo manualmente mediante
modprobe o insmod.
Y para otros aspectos más divertidos, aunque no esten (¿todavía?) integrados en el kernel estándar:
Kerneld consiste en dos entidades separadas:
Ambas piezas deben estar funcionando para que el soporte de kerneld funcione - no es suficiente con que solo una parte o la otra haya sido configurada.
Hay varias buenas razones para usar kerneld. Las que mencionaré son aquellas que yo considero - otras personas lo necesitarán por motivos diferentes.
El soporte en el kernel de Linux se introdujo con Linux 1.3.57. Si dispone de una versión anterior del kernel, necesitará actualizarla si necesita soporte para kerneld. Cualquiera de los ftp típicos de Linux disponen de los fuentes de Linux - recomiendo que se actualice a la última versión estable del kernel, actualmente 2.0.29 ( N. del T. - durante la traducción la última versión es la 2.0.34):
El daemon a nivel de usuario se incluye en el paquete modules-1.2.8
,
y con el modules-2.0
. Normalmente se encuentran disponibles en
los mismos sitios que los fuentes del kernel, pero las localizaciones
oficiales incluyen:
NOTA: Si desea probar la carga de módulos con los últimos kernels de desarrollo 2.1, necesitará usar el último paquete modutils- (NO modules-). Pero antes vea más adelante los problemas con los módulos y los kernels 2.1.
Primero las partes necesarias: Un kernel en condiciones y las últimas
modules-utilities. Instale a continuación las utilidades de módulos.
Es muy sencillo - solo desempaquetar los fuentes y ejecutar make
install
. Esto compilará e instalará los siguientes programas en
/sbin: gensysm, insmod, lsmod, modprobe, depmod, kerneld
.
Recomiendo añadir algunas líneas en sus ficheros de comandos de
inicio para hacer algunas configuraciones necesarias cada vez que
arranque Linux. Añada las siguientes líneas a su fichero
/etc/rc.d/rc.S
(si está corriendo Slackware), o al fichero
/etc/rc.d/rc.sysinit
(si está corriendo SysVinit, por
ejemplo Debian, RedHat, Caldera):
# Cargar kerneld - esto debe suceder muy pronto en el
# proceso de carga, necesariamente ANTES de que ejecute
# fsck en los sistemas de ficheros que necesiten tener
# controladores cargados como módulos.
if [ -x /sbin/kerneld ]
then
/sbin/kerneld
fi
# Sus comandos fsck estándars van aquí
# Y sus comandos mount para montar el fs root como lect-escr
# Actualizar el fichero de las dependencias entre módulos
# Su sistema de ficheros root ya DEBE estar montado como
# lectura-escritura en este momento.
if [ -x /sbin/depmod ]
then
/sbin/depmod -a
fi
La primera parte carga el propio kerneld.
La segunda parte llama a `depmod -a'
al principio. El programa
depmod crea una lista de todos los módulos disponibles y analiza sus
interdependencias, ya que sabe si un módulo necesita tener cargado
otro anteriormente para que él mismo pueda ser cargado.
NOTA: Versiones recientes de kerneld pueden incorporar de forma dinámica la librería dbm de GNU, libgdbm. Si activa esta opción cuando construya las module-utilitites, kerneld no arrancará si libgdbm no se encuentra disponible lo cual puede ser su caso si por ejemplo tiene /usr en una partición separada y ejecuta kerneld antes de que /usr sea montado. La solución recomendada el mover dicha librería de /usr/lib a /lib, o enlazar kerneld de forma estática.
A continuación, desempaquete los fuentes del kenrel, configurelo y
construya un nuevo kernel a su medida. Si no lo ha hecho esto
nunca, necesita leer NECESARIAMENTE el fichero README
que
encontrará en el nivel superior de sus fuentes de Linux. Cuando
ejecute make config
para configurar el kernel, debe prestar
atención a algunas preguntas que aparecen pronto:
Enable loadable module support (CONFIG_MODULES) [Y/n/?] Y
Debe seleccionar el soporte para módulos, ¡o no habrán módulos que cargar con kerneld! Responda Y (sí).
Kernel daemon support (CONFIG_KERNELD) [Y/n/?] Y
Esto, por supuesto, también es necesario. A partir de ahora, muchas de las partes del kernel pueden ser construidas como módulos - verá preguntas al estilo de
Normal floppy disk support (CONFIG_BLK_DEV_FD) [M/n/y/?]
en las que debe responder con una `M' por `Module'. Generalmente, solo los controladores necesarios para el arranque de su sistema - el controlador de disco duro, el controlador de sistema de ficheros raíz - deben estar compilados en el kernel; el resto pueden ser construidos como módulos.
Cuando haya finalizado con el make config
, ejecute make dep
,
make clean
, make zImage
o make zlilo
, make modules
y make modules_install
.
¡Buf!
make zImage
deja la imagen del nuevo kernel en el fichero
arch/i386/boot/zImage
. Necesitará copiarlo en donde guarde
su imagen de carga, o instalarlo con LILO.
Para más información acerca de cómo configurar, construir e instalar su propio kernel, lea el documento ftp://ftp.insflug.nova.es/es/Kernel-Como.gz.
Rearranque con el nuevo kernel. Cuando el sistema esté en funcionamiento,
podrá ejecutar ps -ax
, y podrá ver una línea para kerneld:
PID TTY STAT TIME COMMAND
59 ? S 0:01 /sbin/kerneld
Una de las cosas interesantes de kerneld es que una vez que tiene el kernel y el daemon instalado, realmente se necesitan pocas cosas más. Para comenzar, pruebe a usar uno de los controladores que construyó como módulo - es muy probable que funcione directamente sin ningún otro tipo de configuración. Yo compilé el controlador de disquete como módulo, por lo que solo tengo que poner un disquete de DOS en la unidad y hacer
osiris:~ $ mdir a:
Volume in drive A has no label
Volume Serial Number is 2E2B-1102
Directory for A:/
binuti~1 gz 1942 02-14-1996 11:35a binutils-2.6.0.6-2.6.0.7.diff.gz
libc-5~1 gz 24747 02-14-1996 11:35a libc-5.3.4-5.3.5.diff.gz
2 file(s) 26689 bytes
Y el controlador del disquete funciona - fue cargado automáticamente por kerneld cuando intenté usar la unidad de disquete.
Para ver que el módulo del controlador de diquete está cargado, puede
ejecutar /sbin/lsmod
con lo que dispondrá de un listado de los
módulos que actualmente están cargados:
osiris:~ $ /sbin/lsmod
Module: #pages: Used by:
floppy 11 0 (autoclean)
La palabra ``(autoclean)'' significa que el módulo será automáticamente eliminado por kerneld cuando lleve un minuto sin entrar en uso. Con lo que las 11 páginas de memoria (= 44kB, una página son 4kB) serán usadas solo cuando esté accediendo a la unidad de diquete - si no uso el diquete durante más de un minuto, esa memoria será liberada. Bastante atractivo si no dispone de excesiva memoria para sus aplicaciones.
Aunque kerneld conoce la mayor parte de los módulos de más uso, hay situaciones en las que kerneld no conoce cómo manejar las peticiones del kernel. Este es lo que ocurre con cosas como los controladores de CD-ROM o de red, dado que hay más de un módulo posible que puede ser cargado.
Las peticiones que el daemon kerneld obtiene desde el kernel es para uno de los siguientes elementos:
Kerneld determina qué módulo debe cargarse mirando en el fichero de
configuración /etc/conf.modules
. Hay dos tipos de entradas
en ese fichero: Caminos (donde los ficheros de los módulos se
encuentran), y alias (qué módulo debe ser cargado). Si no dispone de
este fichero todavía, puede crearlo ejecutando
/sbin/modprobe -c | grep -v '^path' >/etc/conf.modules
Si desea añadir alguna otra directiva de tipo ``path'' (camino) a los
caminos por defecto, necesita incluir todos los caminos por
defecto también, ya que una directiva de camino en
/etc/conf.modules
reemplazará a todas aquellas que
modprobe
conozca por defecto.
Normalmente no necesitará añadir más caminos por su cuenta, ya que el conjunto incorporado por defecto tendrá en cuenta todas las configuraciones ``normales'', ¡ lo prometo !
Por otro lado, si desea añadir un alias o una directiva de opción,
sus nuevas entradas en /etc/conf.modules
deberán ser añadidas
a las que modprobe ya conoce. Si usted necesita redefinir un
alias o una opción, sus nuevas entradas en /etc/conf.modules
anularán a las que existen por defecto.
Si ejecuta `/sbin/modprobe -c'
, obtendrá una lista de los
módulos que kerneld conoce, y a qué peticiones corresponden. Por
ejemplo, la petición que termina con la carga del controlador de
disquete es para el dispositivo de bloques que tiene el número
mayor 2:
osiris:~ $ /sbin/modprobe -c | grep floppy
alias block-major-2 floppy
¿ Por qué block-major-2 ? Porque las unidades de disquete
/dev/fd*
usan el número mayor de dispositivo 2 y son
dispositivos de bloques:
osiris:~ $ ls -l /dev/fd0 /dev/fd1
brw-rw-rw- 1 root root 2, 0 Mar 3 1995 /dev/fd0
brw-r--r-- 1 root root 2, 1 Mar 3 1995 /dev/fd1
Los dispositivos de caracteres son tratados de forma similar. Por ejemplo el controlador ftape utiliza el número mayor de dispositivo 27:
osiris:~ $ ls -lL /dev/ftape
crw-rw---- 1 root disk 27, 0 Jul 18 1994 /dev/ftape
Aun con todo, kerneld no conoce por defecto al controlador ftape - no
es listado en la salida que genera `/sbin/modprobe -c'
.
Por lo que para configurar a kerneld para que carge el controlador
ftape, necesito añadir una línea en el fichero de configuración,
/etc/conf.modules
:
alias char-major-27 ftape
Puede usar igualmente el nombre del dispositivo en vez de
`char-major-xxx'
o block-major-yyy'
. Esto es especialmente útil
para los controladores de red. Por ejemplo un controlador para una
placa de red ne2000 actuando como eth0 sería cargada con
alias eth0 ne
Si necesita pasar alguna opción al controlador - por ejemplo para indicar
al módulo qué IRQ está usando la placa de red, necesita añadir una
línea de `options'
(opciones):
options ne irq=5
Esto hará que kerneld cargue el driver para NE2000 con el comando
/sbin/modprobe ne irq=5
Por supuesto, las opciones disponibles son específicas del módulo que está cargando.
Los formatos binarios son tratados de forma similar. Cuando intente
ejecutar un programa que el kernel no sepa como cargar, kerneld recibe
una petición por ``binfmt-xxx
'', donde xxx es un número
determinado por unos pocos bytes iniciales del ejecutable. Por lo tanto,
la configuración para que kerneld soporte la carga del módulo
binfmt_aout
para ejecutables ZMAGIC (a.out) es:
alias binfmt-267 binfmt_aout
ya que el número mágico (véase /etc/magic
) para los ficheros
ZMAGIC es 267. (Si hecha un vistazo a /etc/magic
, verá que
dicho número es el 0413, pero es porque en este fichero se usan números
en octal mientras que kerneld los usa en decimal, y 413o = 267d).
Actualmente hay tres variantes de los ejecutables a.out (NMAGIC, QMAGIC
y ZMAGIC), por lo que para un soporte completo del módulo binfmt_aout
necesitamos:
alias binfmt-264 binfmt_aout # pure executable (NMAGIC)
alias binfmt-267 binfmt_aout # demand-paged executable (ZMAGIC)
alias binfmt-204 binfmt_aout # demand-paged executable (QMAGIC)
Los formatos binarios a.out, Java e iBCS con reconocidos automáticamente por kerneld, sin niguna configuración.
Las diciplinas de línea son pedidas mediante ``tty-ldisc-x
'',
donde `x' es normalmente 1 (para SLIP) o 3 (para PPP). Ambos son reconocidos
por kerneld de forma automática.
Hablando de ppp, si desea que kerneld cargue el módulo de compresión de
datos para ppp (bsd_comp
), debe añadir las siguientes líneas a su
/etc/conf.modules
:
alias tty-ldisc-3 bsd_comp
alias ppp0 bsd_comp
Algunos protocolos de red pueden ser cargados como módulos también. El
kernel pide a kerneld por una familia de protocolos (por ejemplo IPX) con
una petición ``net-pf-X
'' donde `X' es un número indicando la
família que se desea. Por ejemplo net-pf-3 es AX.25, net-pf-4 es IPX y
net-pf-5 es AppleTalk. (Estos números se determinan por las definiciones
AF_AX25, AF_IPX, etc. en el fichero de los fuentes de Linux
include/linux/socket.h
). Por lo que para cargar automáticamente
el módulo de IPX, necesitaría disponer de una entrada como esta
en /etc/conf.modules
:
alias net-pf-4 ipx
Véase también la sección Fallos conocidos para solucionar algunos mensajes en tiempo de carga relacionados con familias de protocolos sin definir.
Las peticiones de kerneld para los sistemas de ficheros son simplemente el nombre del tipo de sistema de ficheros. Un uso normal sería el cargar el módulo isofs para el sistema de ficheros de un CD-ROM, por ejemplo sistemas de ficheros de tipo ``iso9660'':
alias iso9660 isofs
Algunos controladores requieren un poco de configuración fuera de los normales alias.
Los dispositivos de hardware se identifican normalmente con el número
mayor de dispositivo, por ejemplo ftape es char-major-27. De todas
maneras, si mira las entradas en /dev
para char-major-10,
verá que hay una gran cantidad de dispositivos muy diferentes,
incuyendo
Obviamente, estos dispositivos están controlados por diferentes módulos, no por uno solo. Por este motivo, la configuración de kerneld para estos dispositivos variados usa tanto el número mayor como el número menor:
alias char-major-10-1 psaux # For PS/2 mouse
alias char-major-10-130 wdt # For WDT watchdog
Para usar esta característica necesita disponer de la versión de kernel 1.3.82 o superior; las versiones anteriores no pasan el número menor a kerneld, haciendo imposible que kerneld sepa a cuál de estos dispositivos se refiere el kernel.
Los controladores para los dispositivos SCSI consisten en un controlador
para el adaptador SCSI (SCSI host adapter), y un controlador para
el tipo de dispositivo SCSI de que disponga, por ejemplo un disco duro,
un CD-ROM o una unidad de cinta. Todos estos pueden ser cargados como
módulos. De todas maneras, cuando usted quiere acceder por ejemplo a la
unidad de CD-ROM que está conectada con la placa Adaptec, el kernel y
kerneld solo conocen que hay que cargar el módulo sr_mod
para poder
soportar los CD-ROMs SCSI - no conocen a qué controlador SCSI está
conectado el CD-ROM, y por tanto no conocen qué módulo deben cargar para
soportar el controlador SCSI.
Para resolver esto, puede añadir una entrada para el módulo del
controlador SCSI en su /etc/conf.modules
que indique a kerneld
cual de entre todos los controladores SCSI disponibles es el que debe
cargar:
alias scd0 sr_mod # sr_mod para CD-ROM's SCSI...
alias scsi_hostadapter aha1542 # ... necesita el controlador Adaptec
Esto solo funciona con kernels versión 1.3.82 o posteriores.
Esto funciona si solo dispone de un controlador SCSI. Si tiene más de uno, las cosas comienzan a ser un poco más complicadas.
En general, no puede hacer que kerneld cargue un controlador para un adaptador SCSI, si un controlador de otro adaptador ha sido instalado anteriormente - en este caso tendría que compilar dentro de su kernel los dos controladores (no como módulos), o cargar los módulos manualmente.
No obstante hay una manera de hacer que kerneld carge más de un controlador SCSI. La idea es de James Tsiao:
Puede hacer que kerneld cargue el segundo driver SCSI configurando
manualmente las dependencias de su `modules.dep'. Solo necesita una
entrada como esta:
/lib/modules/2.0.30/scsi/st.o: /lib/modules/2.0.30/scsi/aha1542.o
Para hacer que kerneld cargue aha1542.o antes de cargar st.o. Mi
máquina en casa tiene la misma configuración que la de arriba, y
funciona bien con todos mis dispositivos SCSI secundarios, incluyendo
cinta, cd-rom, y dispositivos SCSI genéricos. El inconveniente es que
`depmod -a' no puede detectar estas dependencias, así que debe
añadirlas manualmente, y no ejecutar `depmod -a' durante la carga
del sistema. Pero una vez configurado, kerneld cargará automáticamente
el aha1542.o perfectamente.
Debe tener en cuenta que esta técnica solo funcionará si tiene diferentes tipos de dispositivos SCSI en los dos controladores - por ejemplo discos duros en un controlador, y cd-rom, cintas y genéricos en el otro.
A veces, no es suficiente con cargar el módulo para que las cosas
funcionen. Por ejemplo, si tiene una targeta de sonido compilada como un
módulo, es muchas veces conveniente el modificar el nivel de volumen.
El problema surge debido a que cuando el módulo es descargado, todas
estas modificaciones se pierden. Aquí puede ver un elegante truco
proveniente de Ben Galliart (bgallia@luc.edu
):
La solución final requiere instalar el paquete setmix-0.1
( ftp://sunsite.unc.edu/pub/Linux/apps/sound/mixers/setmix-0.1.tar.gz )
Y luego añadir la siguiente línea a mi /etc/conf.modules :
post-install sound /usr/local/bin/setmix -f /etc/volume.conf
Lo que hace esto es que después de cargar el módulo, kerneld ejecuta el
comando indicado en la entrada `post-install sound'
. Con esto
conseguimos configurar el módulo de sonido mediante el comando
`/usr/local/bin/setmix -f /etc/volume.conf'
.
Esto puede ser útil para otros módulos, por ejemplo el módulo lp puede ser configurado con el programa tunelp añadiendo
post-install lp tunelp <options>
Para que kerneld reconozca estas opciones, necesitará la versión de kerneld 1.3.69f o posterior.
NOTA: Una versión anterior de este mini-HOWTO mencionaba una opción
llamada pre-remove
, que podría ser usada para ejecutar un comando
justo antes de que kerneld descargara un módulo. De todas maneras, esto
nunca ha funcionado - lo más probable es que esta opción desaparezca en
las futuras versiones de kerneld. Todo el tema de las ``especificaciones''
de un módulo está sufriendo algunos cambios en estos momentos, y puede
ser diferente en su sistema cuando lea este documento.
Si lo está probando todo, y todavía no se imagina qué es lo que el kernel
le está pidiendo a kerneld, hay una manera de ver las peticiones que
kerneld recibe, y como consecuencia deducir qué debería aparecer en
/etc/conf.modules
: La utilidad kdstat.
Este pequeño pero útil programa viene en el paquete modules
, pero
no esa compilado ni instalado por defecto. Para construirlo:
cd /usr/src/modules-2.0.0/kerneld
make kdstat
Entonces, para hacer que kerneld muestre información sobre lo que está haciendo, ejecute
kdstat debug
y kerneld comenzará a volcar mensajes a la consola sobre lo que está
haciendo. Si entonces prueba a ejecutar el comando que quiere usar,
verá las peticiones a kerneld; entonces puede ponerse en
/etc/conf.modules
y añadir un alias para el módulo necesario
para que el trabajo se realice.
Para parar la depuración, ejecute `/sbin/kdstat nodebug'
.
Se que usted podría preguntar sobre como configurar el módulo salvapantallas ...
El directorio `kerneld/GOODIES'
en el paquete modules
contiene una serie de parches para el kernel para el soporte de
salvapantallas y beeps de consola en kerneld; no son todavía partes
del kernel oficial. Por lo tanto necesitará instalar los parches del
kernel y volver a construirlo.
Para instalar un parche, use el siguiente comando:
cd /usr/src/linux
patch -s -p1 </usr/src/modules-2.0.0/kerneld/GOODIES/blanker_patch
Entonces vuelva a construir e instalar el nuevo kernel.
Cuando el evento del salvapantallas se activa, kerneld ejecutará el
comando `/sbin/screenblanker'
- que deberá ser un fichero de
comandos del shell que ejecute su salvapantallas favorito.
Cuando el kernel desee desbloquear la pantalla, envía un signal SIGQUIT
al proceso que ejecuta /sbin/screenblanker
. Su fichero de
comandos o salvapantallas debe atraparlo, y terminar. ¡Recuerde restaurar
la pantalla al modo texto original!
Aproximadamente en la versión 1.3.80 del kernel, el código de red fué
cambiado para permitir la carga de familias de protocolos (IPX, AX.25
y AppleTalk) como módulos. Esto propició la aparición de nuevas
peticiones a kerneld: net-pf-X, donde X es un número identificando
el protocolo (véase /usr/src/linux/include/linux/socket.h
para comprender el significado de cada número).
Desafortunadamente, ifconfig
genera estos mensajes, por lo que
mucha gente obtiene unos cuantos mensajes registrados cuando el
sistema arranca y ejecuta ifconfig
para configurar el dispositivo
loopback. Los mensajes son totalmente inofensivos, y puede
desactivarlos añadiendo las líneas
alias net-pf-3 off # Olvidarse de AX.25
alias net-pf-4 off # Olvidarse de IPX
alias net-pf-5 off # Olvidarse de AppleTalk
a /etc/conf.modules
. Por supuesto, si usa IPS como módulo,
no debe añadir la línea para deshabilitar IPX.
Han habido unos cuantos informes de este problema. Parece ser
consecuencia de alguna desaforunada interacción entre kerneld y el
script tkPPP
que se usa un varios sistemas para configurar y
monitorizar la conexión PPP - el script aparentemente ejecuta bucles
mientras ejecuta ifconfig
. Esto envía mensajes a kerneld, para
cargar los módulos net-pf-X (vea arriba), cargando el sistema y
posiblemente generando un montón de mensajes de ``Cannot locate module
for net-pf-X'' en el registro del sistema. El único arreglo conocido
consiste en no usar tkPPP, o cambiarlo para que use otro tipo de
monitorización de la conexión.
Añada una entrada para el adaptador SCSI en su /etc/conf.modules
.
Vea la descripción de la entrada ``scsi_hostadapter''
descrita
anteriormente en este documento.
Este es uno de los fallos de las utilidades de módulos, que aparece
solo con las binutils
2.6.0.9 y posteriores, y está documentado
en la documentación de binutils. Así que lea las ``release
notes'' de las binutils. Otra opción es obtener una actualización
de las module-utilities
que superen este problema, por ejemplo
modules-2.0.0
.
Las configuraciones del un módulo son guardadas dentro del propio módulo cuando es cargado. Por eso, cuando el kernel carga automáticamente un módulo, cualquier cambio que haya realizado es olvidado, y la siguiente vez que el módulo sea cargado será configurado con los valores por defecto.
Puede indicar a kerneld que configure un módulo ejecutando un programa
después de que el módulo haya sido cargado automáticamente. Vea en la
sección anterior la entrada ``post-install''
.
No puede. Ninguna de las versiones de dosemu - oficial o de desarrollo - soportan la carga de los módulos de dosemu a través de kerneld. De todas maneras, si está usando el kernel 2.0.26 o posterior, no necesitará los módulos especiales de dosemu - actualice dosemu a la versión 0.66.1.
Cuando el kernel envía una petición a kerneld, espera recibir una respuesta de aceptación en el plazo de un segundo. Si kerneld no envía este mensaje, el mensaje es registrado. La petición se retransmite, y eventualmente puede terminar.
Esto pasa típicamente en sistemas con una carga muy alta - ya que kerneld es un proceso a nivel de usuario, es planificado como cualquier otro proceso del sistema. En instantes de mucha carga, puede que no sea ejecutado a tiempo para enviar la respuesta afirmativa antes de que el kernel contabilice un segundo.
Si esto ocurre cuando la carga es más ligera, pruebe a rearrancar el
daemon kerneld. (Mate al proceso kerneld, y cárgelo de nuevo con el
comando /usr/sbin/kerneld
. Si el problema persiste, deberá
enviar un mensaje electrónico con un informe de fallo a
linux-kernel@vger.rutgers.edu, pero por favor asegúrese
de que dispone de las últimas versiones del kernel y de kerneld
antes de dar a conocer el problema.
Ha habido unos cuantos mensajes indicando que el comando mount(8)
no espera a que kerneld cargue el módulo del sistema de ficheros.
lsmod
muestra que el módulo correspondiente ha sido cargado, y si
repite el comando mount a continuación este funciona. Esto parece ser
un fallo de las module-utilities
versión 1.3.69f que afecta a
algunos usuarios de Debian - puede ser arreglado obteniendo la última
versión de las utilidades.
Necesita compilar las utilidades ncpfs con -DHAVE_KERNELD
. Vea
el Makefile de ncpfs.
Está usando una versión antigua de las utilidades smbmount
.
Obtenga la última versión (0.10 o posterior) de
ftp://tsx-11.mit.edu/pub/linux/filesystems/smbfs.
No puede modularizarse todo: El kernel necesita tener suficientes drivers compilados internamente para ser capaz de montar el sistema de ficheros raíz, y ejecutar los programas necesarios para ejecutar kerneld. Por eso no puede modularizar
init
, kerneld
y otros programas.(Actualmente esto no es cierto. Los últimos kernels 1.3.x y todos los
2.x soportan el uso de un ram-disk inicial cargado por LILO o LOADLIN,
y es posible cargar módulos a partir de este ``disco''; muy pronto en
el proceso de carga. Cómo hacerlo está descrito en el fichero
Documentation/initrd.txt
que viene con los fuentes del
kernel.)
Las nuevas versiones de kerneld necesitan la librería dbm de GNU,
libgdbm.so
, para poder ejecutarse. Muchas instalaciones tienen
este fichero en /usr/lib
, pero probablemente esté intentando
ejecutar kerneld antes de que su sistema de ficheros de /usr
haya sido montado. Uno de los síntomas es que kerneld no arrancará
durante la carga del sistema (desde sus ficheros de comandos rc),
pero arranca perfectamente si lo arranca a mano cuando el sistema
ha arrancado. La solución es o mover la carga de kerneld después de
que /usr
haya sido montado, o mover la librería a su sistema
de ficheros raíz, por ejemplo a /lib
.
La instalación Slackware (y posiblemente otras) crean un fichero
/etc/rc.d/rc.modules
por defecto el cual hace un modprobe
explícito de unos cuantos módulos. Exactamente de qué módulos depende
de la configuración original del kernel. Probablemente haya
reconfigurado su kernel para dejar de soportar alguno de los que
están siendo probados en rc.modules
, y por eso el error.
Modifique su rc.modules
comentando los módulos que no vaya a usar
más, o borre directamente dicho script y deje que kerneld cargue los
módulos cuando sean necesarios.
Probablemente reconfiguró/recontruyó su kernel y escluyó algún módulo.
Tiene algunos módulos antiguos que no usa pero que siguen estando en
el directorio /lib/modules
. La solución más fácil es borrar
el directorio /lib/modules/x.y.z
y volver a hacer un
make modules_install
desde el directorio de los fuentes del
kernel. Nótese que este problema sólo ocurre cuando se reconfigura el
kernel sin cambiar la versión. Si observa este error cuando esté
actualizando el kernel a una nueva versión, entonces tiene otro problema
diferente.
Linux 2.1 es el kernel en desarrollo actualmente. Como tal, es de esperar que las cosas no funcionen de vez en cuando. Una de las cosas que han cambiado significativamente es la manera en la que los módulos son tratados, y dónde se localizan tanto el kernel como los módulos en memoria. Richard Henderson está actualmente encargado del desarrollo de los módulos en el kernel.
En definitiva, si desea usar los módulos con un kernel 2.1, debe
modutils
, el cual puede
obtenerse en
ftp://tsx-11.mit.edu/pub/linux/packages/alphabits/.Le recomendaría que usara como mínimo el kernel 2.1.29, si desea usar los módulos con un kernel 2.1.
Originalmente kerneld tiene algún soporte para establecer conexiones
mediante llamada por demanda; intentar enviar un paquete por una red sin
que haya sido conectada debería hacer que kerneld ejecutara el fichero
de comandos /sbin/request_route
para activar una conexión PPP o
SLIP.
Esto se convirtió en una mala idea. Alan Cox escribió en la lista de correo sobre el kernel de Linux, que
Todo el tema de la request-route es obsoleto, olvidado y no es
necesario [...]
Se ha eliminado de los árboles de 2.1.x
En vez de usar el fichero de comandos request-route
y kerneld, yo
recomiendo la instalación del paquete diald
, que puede encontrarse
en
http://www.dna.lth.se/~erics/diald.html.
El documento original tiene el copyright (c) Henrik Storner, 1996, 1997.
A menos que se exponga otra cosa, los documentos HOWTO de Linux tienen el copyright de sus respectivos autores. Los HOWTO de Linux pueden ser reproducidos y distribuidos en su totalidad o en parte, sobre cualquier sopore físico o electrónico, siempre y cuando este mensaje de copyright sea mantenido en todas las copias. La redistribución comercial está permitida y alentada; de cualquier modo, el autor desearía ser notificado de cualquier tipo de distribución.
Cualquier traducción, trabajo derivado o agregado incorporando alguno de los HOWTO de Linux debe estar cubierto por esste mensaje de copyright. Esto es, no puede producir un trabajo derivado de un HOWTO e imponer restricciones adicionales a su distribución. Las excepciones a estas reglas serán permitidas bajo ciertas condiciones; por favor póngase en contacto con el coordinador de los HOWTO de Linux en la dirección indicada abajo.
Brevemente, deseamos promover la diseminación de enta información por todos los canales posibles. De cualquier manera, deseamos mantener el copyright de los documentos HOWTO, y deseamos ser informados de los planes de redistribución de dichos documentos.
Si tiene alguna pregunta, por favor póngase en contacto con Greg Hankins,
el coordinador de los HOWTO de Linux, a través del correo electrónico
en gregh@sunsite.unc.edu
.