Kerneld con Linux COMO <author>Henrik Storner <tt/(storner@osiris.ping.dk)/ <newline> , Traducción por Juan José López <tt/(laveneno@hotmail.com)/ <date>vers. 1.7, July 19, 1997 (trad: 2 Ago 1998) <abstract> Este documento explica el funcionamiento y configuración de kerneld bajo Linux </abstract> <toc> <sect>Introducción <p> Este documento explica como puede usar kerneld en los kernel Linux. Describe <itemize> <item>Qué es kerneld. <item>Por qué usar kerneld. <item>De dónde obtener las piezas necesarias. <item>Cómo configurarlo todo. <item>Cómo dar información a kerneld sobre los módulos que no conoce. <item>Cómo espiar a kerneld (puede ser útil para su configuración) <item>Usos especiales de kerneld. <item>Fallos conocidos y cosas feas. </itemize> La última versión de este documento en su versión original en Inglés puede encontrarse en <htmlurl url="http://eolicom.olicom.dk/~storner/kerneld-mini-HOWTO.html" name="http://eolicom.olicom.dk/~storner/kerneld-mini-HOWTO.html">. Entre entregas de este mini-HOWTO puede encontrar las modificaciones en mi lista de cambios <htmlurl url="http://eolicom.olicom.dk/~storner/kern.html" name="http://eolicom.olicom.dk/~storner/kern.html"> (sin estructurar). <bf/N. del T./- La última versión de la traducción de este documento puede encontrarse en el ftp de INSFLUG <em/(Impatient and Novatous Spanish Fidonet LiNUX Users Group)/ <htmlurl url="http://www.insflug.nova.es" name="http://www.insflug.nova.es">. <sect1>Agradecimientos <p> 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: <itemize> <item>Bjorn Ekwall <tt/bj0rn@blox.se/. <item>Ben Galliart <tt/bgallia@luc.edu/. <item>Cedric Tefft <tt/cedric@earthling.net/. <item>Brian Miller <tt/bmiller@netspace.net.au/. <item>James C. Tsiao <tt/jtsiao@madoka.jpl.nasa.gov/. </itemize> El autor, al igual que el traductor, apreciarían mucho los ánimos y las sugerencias enviadas por los lectores de este mini-HOWTO. <sect>Qué es kerneld <p> Kerneld es una característica introducida durante el desarrollo de los kernels 1.3 por Bjorn Ekwall (<tt/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: <itemize> <item>Puede ser configurado para ejecutar un programa de usuario en vez del salvador de pantalla, por tanto permitiéndole usar cualquier programa como salvapantallas. <item>Similar al soporte para salvapantallas, usted puede cambiar el ``beep'' estándar de la consola por algo completamente diferente ... </itemize> Kerneld consiste en dos entidades separadas: <itemize> <item>Soporte en el kernel de Linux para el envío de peticiones a un daemon indicando que se necesita un módulo para realizar una tarea determinada. <item>Un daemon a nivel de usuario capaz de decidir qué módulos deben cargarse para servir a la petición del kernel. </itemize> 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. <sect>Por qué usar kerneld <P> Hay varias buenas razones para usar kerneld. Las que mencionaré son aquellas que yo considero - otras personas lo necesitarán por motivos diferentes. <itemize> <item>Si debe construir kernels diferentes para varios sistemas los cuales solo difieren entre sí en pequeños detalles - diferentes targetas de red, por ejemplo - entonces puede construir un solo kernel y varios módulos, en vez de construir kernels individuales para cada sistema. <item>Los módulos son mucho más sencillos de probar para los programadores - no necesita rearrancar el sistema para cargar y descargar el controlador. (Esto es aplicable para todos los módulos, no solo aquellos cargados por kerneld). <item>Reduce el uso de memoria del kernel, lo cual significa que tendrá más memoria libre para las aplicaciones. La memoria usada por el kernel <em/nunca/ es enviada al área de intercambio (swap), por lo que si tiene 100Kb de controladores que no usa en su kernel, están símplemente malgastando RAM. <item>Algunas de las cosas que uso - el controlador de disquete-cinta ftape, por ejemplo, o iBCS - solo están disponibles en módulos. Pero no quiero preocuparme de cargarlos y descargarlos cuando los necesite. <item>La gente que hace distribuciones de Linux no tiene que construir 284 imagenes de arranque diferentes - cada usuario carga solo los controladores necesarios para su hardware. Esto es usuado por ejemplo por RedHat 4.0 en su instalación. <item>Por supuesto, hay también razones por las que no desearía usarlo - puede que prefiera tener solo una imagen del kernel con todos sus drivers compilados internamente. En ese caso está leyendo el documento equivocado. </itemize> <sect>De dónde obtener las piezas necesarias <p> 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 ( <em/N. del T./ - durante la traducción la última versión es la 2.0.34): <itemize> <item><htmlurl url="ftp://sunsite.unc.edu/pub/Linux/kernel/v2.0" name="ftp://sunsite.unc.edu/pub/Linux/kernel/v2.0/linux-2.0.29.tar.gz"> <item><htmlurl url="ftp://tsx-11.mit.edu/pub/linux/sources/system/v2.0" name="ftp://tsx-11.mit.edu/pub/linux/sources/system/v2.0/linux-2.0.29.tar.gz"> <item><htmlurl url="ftp://ftp.funet.fi/pub/OS/Linux/PEOPLE/Linus/v2.0" name="ftp://ftp.funet.fi/pub/Linux/PEOPLE/Linus/v2.0/linux-2.0.29.tar.gz"> </itemize> El daemon a nivel de usuario se incluye en el paquete <tt/modules-1.2.8/, y con el <tt/modules-2.0/. Normalmente se encuentran disponibles en los mismos sitios que los fuentes del kernel, pero las localizaciones oficiales incluyen: <itemize> <item><htmlurl url="ftp://sunsite.unc.edu/pub/Linux/kernel/modules-2.0.0.tar.gz" name="ftp://sunsite.unc.edu/pub/Linux/kernel/v2.0/modules-2.0.0.tar.gz"> <item><htmlurl url="ftp://tsx-11.mit.edu/pub/linux/sources/sbin/" name="ftp://tsx-11.mit.edu/pub/linux/sources/sbin/modules-2.0.0.tar.gz"> <item><htmlurl url="ftp://ftp.funet.fi/pub/OS/Linux/tools/" name="ftp://ftp.funet.fi/pub/Linux/tools/modules-2.0.0.tar.gz"> </itemize> <bf/NOTA:/ Si desea probar la carga de módulos con los últimos kernels de <em/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. <sect>Cómo configurarlo todo <P> 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 <tt/make install/. Esto compilará e instalará los siguientes programas en /sbin: <tt/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 <tt>/etc/rc.d/rc.S</tt> (si está corriendo Slackware), o al fichero <tt>/etc/rc.d/rc.sysinit</tt> (si está corriendo SysVinit, por ejemplo Debian, RedHat, Caldera): <tscreen><verb> # 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 </verb></tscreen> La primera parte carga el propio kerneld. La segunda parte llama a <tt/`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. <bf/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, <em/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 <tt/README/ que encontrará en el nivel superior de sus fuentes de Linux. Cuando ejecute <tt/make config/ para configurar el kernel, debe prestar atención a algunas preguntas que aparecen pronto: <tscreen><verb> Enable loadable module support (CONFIG_MODULES) [Y/n/?] Y </verb></tscreen> Debe seleccionar el soporte para módulos, ¡o no habrán módulos que cargar con kerneld! Responda Y (sí). <tscreen><verb> Kernel daemon support (CONFIG_KERNELD) [Y/n/?] Y </verb></tscreen> 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 <tscreen><verb> Normal floppy disk support (CONFIG_BLK_DEV_FD) [M/n/y/?] </verb></tscreen> 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 <tt/make config/, ejecute <tt/make dep/, <tt/make clean/, <tt/make zImage/ o <tt/make zlilo/, <tt/make modules/ y <tt/make modules_install/. ¡Buf! <tt/make zImage/ deja la imagen del nuevo kernel en el fichero <tt>arch/i386/boot/zImage</tt>. 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 <htmlurl url="ftp://ftp.insflug.nova.es/es/Kernel-Como.gz" name="ftp://ftp.insflug.nova.es/es/Kernel-Como.gz">. <sect1>Probando el nuevo kernel <p> Rearranque con el nuevo kernel. Cuando el sistema esté en funcionamiento, podrá ejecutar <tt/ps -ax/, y podrá ver una línea para kerneld: <tscreen><verb> PID TTY STAT TIME COMMAND 59 ? S 0:01 /sbin/kerneld </verb></tscreen> 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 <tscreen><verb> 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 </verb></tscreen> 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 <tt>/sbin/lsmod</tt> con lo que dispondrá de un listado de los módulos que actualmente están cargados: <tscreen><verb> osiris:~ $ /sbin/lsmod Module: #pages: Used by: floppy 11 0 (autoclean) </verb></tscreen> 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. <sect>Cómo dar información a kerneld sobre los módulos que no conoce <p> 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: <itemize> <item>controlador de dispositivo de bloques <item>controlador de dispositivo de caracteres <item>formato binario <item>disciplina de línea de tty <item>sistema de ficheros <item>dispositivo de red <item>servicio de red (por ejemplo rarp) <item>protocolo de red (por ejemplo IPX) </itemize> Kerneld determina qué módulo debe cargarse mirando en el fichero de configuración <tt>/etc/conf.modules</tt>. 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 <tscreen><verb> /sbin/modprobe -c | grep -v '^path' >/etc/conf.modules </verb></tscreen> Si desea añadir alguna otra directiva de tipo ``path'' (camino) a los caminos por defecto, <em>necesita incluir todos los caminos por defecto también</em>, ya que una directiva de camino en <tt>/etc/conf.modules</tt> <em/reemplazará/ a todas aquellas que <tt/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 <tt>/etc/conf.modules</tt> deberán ser añadidas a las que modprobe ya conoce. Si usted necesita <em/redefinir/ un alias o una opción, sus nuevas entradas en <tt>/etc/conf.modules</tt> anularán a las que existen por defecto. <sect1>Dispositivos de bloque <p> Si ejecuta <tt>`/sbin/modprobe -c'</tt>, 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: <tscreen><verb> osiris:~ $ /sbin/modprobe -c | grep floppy alias block-major-2 floppy </verb></tscreen> ¿ Por qué block-major-2 ? Porque las unidades de disquete <tt>/dev/fd*</tt> usan el número mayor de dispositivo 2 y son dispositivos de bloques: <tscreen><verb> 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 </verb></tscreen> <sect1>Dispositivos de caracteres <p> Los dispositivos de caracteres son tratados de forma similar. Por ejemplo el controlador ftape utiliza el número mayor de dispositivo 27: <tscreen><verb> osiris:~ $ ls -lL /dev/ftape crw-rw---- 1 root disk 27, 0 Jul 18 1994 /dev/ftape </verb></tscreen> Aun con todo, kerneld no conoce por defecto al controlador ftape - no es listado en la salida que genera <tt>`/sbin/modprobe -c'</tt>. 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, <tt>/etc/conf.modules</tt>: <tscreen><verb> alias char-major-27 ftape </verb></tscreen> <sect1>Dispositivos de red <p> Puede usar igualmente el nombre del dispositivo en vez de <tt/`char-major-xxx'/ o <tt/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 <tscreen><verb> alias eth0 ne </verb></tscreen> 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 <tt/`options'/ (opciones): <tscreen><verb> options ne irq=5 </verb></tscreen> Esto hará que kerneld cargue el driver para NE2000 con el comando <tscreen><verb> /sbin/modprobe ne irq=5 </verb></tscreen> Por supuesto, las opciones disponibles son específicas del módulo que está cargando. <sect1>Formatos binarios <p> 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 ``<tt>binfmt-xxx</tt>'', 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 <tt/binfmt_aout/ para ejecutables ZMAGIC (a.out) es: <tscreen><verb> alias binfmt-267 binfmt_aout </verb></tscreen> ya que el número mágico (véase <tt>/etc/magic</tt>) para los ficheros ZMAGIC es 267. (Si hecha un vistazo a <tt>/etc/magic</tt>, 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 <tt/binfmt_aout/ necesitamos: <tscreen><verb> 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) </verb></tscreen> Los formatos binarios a.out, Java e iBCS con reconocidos automáticamente por kerneld, sin niguna configuración. <sect1>Disciplinas de línea (slip, cslip y ppp) <p> Las diciplinas de línea son pedidas mediante ``<tt>tty-ldisc-x</tt>'', 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 (<tt/bsd_comp/), debe añadir las siguientes líneas a su <tt>/etc/conf.modules</tt>: <tscreen><verb> alias tty-ldisc-3 bsd_comp alias ppp0 bsd_comp </verb></tscreen> <sect1>Familias de protocolos de red (IPX, AppleTalk, AX.25) <p> 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 ``<tt>net-pf-X</tt>'' 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 <tt>include/linux/socket.h</tt>). Por lo que para cargar automáticamente el módulo de IPX, necesitaría disponer de una entrada como esta en <tt>/etc/conf.modules</tt>: <tscreen><verb> alias net-pf-4 ipx </verb></tscreen> Véase también la sección <em/Fallos conocidos/ para solucionar algunos mensajes en tiempo de carga relacionados con familias de protocolos sin definir. <sect1>Sistemas de ficheros <p> 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'': <tscreen><verb> alias iso9660 isofs </verb></tscreen> <sect>Dispositivos que requieren configuraciones especiales <p> Algunos controladores requieren un poco de configuración fuera de los normales alias. <itemize> <item>Dispositivos de caracteres con número mayor 10: ``Dispositivos variados'' <item>Dispositivos SCSI <item>Dispositivos que requieren inicializaciones especiales </itemize> <sect1>char-major-10: Ratones, watchdogs y aleatorizadores. <p> 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 <tt>/dev</tt> para char-major-10, verá que hay una gran cantidad de dispositivos muy diferentes, incuyendo <itemize> <item>Ratones de varios tipos (bus, PS/2) <item>Dispositivos watchdog (<em/N. del T./ - la traducción literal de <it/watchdog/ es ``perro guardian'', es un dispositivo que rearranca la máquina si no se escribe en el en el plazo de un minuto) <item>El dispositivo `random' (aleatorizador) del kernel. <item>Interfaz APM (<it/Advanced Power Management/) </itemize> Obviamente, estos dispositivos están controlados por diferentes módulos, no por uno solo. Por este motivo, la configuración de kerneld para estos <em/dispositivos variados/ usa tanto el número mayor como el número menor: <tscreen><verb> alias char-major-10-1 psaux # For PS/2 mouse alias char-major-10-130 wdt # For WDT watchdog </verb></tscreen> 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. <sect1>Cargando controladores SCSI: la entrada scsi_hostadapter <p> Los controladores para los dispositivos SCSI consisten en un controlador para el adaptador SCSI (<em/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 <tt/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 <tt>/etc/conf.modules</tt> que indique a kerneld cual de entre todos los controladores SCSI disponibles es el que debe cargar: <tscreen><verb> alias scd0 sr_mod # sr_mod para CD-ROM's SCSI... alias scsi_hostadapter aha1542 # ... necesita el controlador Adaptec </verb></tscreen> 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 <em/hay/ una manera de hacer que kerneld carge más de un controlador SCSI. La idea es de James Tsiao: <tscreen><verb> 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. </verb></tscreen> 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. <sect1>Cuando cargar un módulo no es suficiente: La entrada `post-install' <p> 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 (<tt/bgallia@luc.edu/): <tscreen><verb> 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 </verb></tscreen> Lo que hace esto es que después de cargar el módulo, kerneld ejecuta el comando indicado en la entrada <tt/`post-install sound'/. Con esto conseguimos configurar el módulo de sonido mediante el comando <tt>`/usr/local/bin/setmix -f /etc/volume.conf'</tt>. Esto puede ser útil para otros módulos, por ejemplo el módulo lp puede ser configurado con el programa tunelp añadiendo <tscreen><verb> post-install lp tunelp <options> </verb></tscreen> Para que kerneld reconozca estas opciones, necesitará la versión de kerneld 1.3.69f o posterior. <bf/NOTA:/ Una versión anterior de este mini-HOWTO mencionaba una opción llamada <tt/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. <sect>Espiando a kerneld <p> 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 <tt>/etc/conf.modules</tt>: La utilidad kdstat. Este pequeño pero útil programa viene en el paquete <tt/modules/, pero no esa compilado ni instalado por defecto. Para construirlo: <tscreen><verb> cd /usr/src/modules-2.0.0/kerneld make kdstat </verb></tscreen> Entonces, para hacer que kerneld muestre información sobre lo que está haciendo, ejecute <tscreen><verb> kdstat debug </verb></tscreen> 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 <tt>/etc/conf.modules</tt> y añadir un alias para el módulo necesario para que el trabajo se realice. Para parar la depuración, ejecute <tt>`/sbin/kdstat nodebug'</tt>. <sect>Usos especiales de kerneld <p> Se que usted podría preguntar sobre como configurar el módulo salvapantallas ... El directorio <tt>`kerneld/GOODIES'</tt> en el paquete <tt/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: <tscreen><verb> cd /usr/src/linux patch -s -p1 </usr/src/modules-2.0.0/kerneld/GOODIES/blanker_patch </verb></tscreen> Entonces vuelva a construir e instalar el nuevo kernel. Cuando el evento del salvapantallas se activa, kerneld ejecutará el comando <tt>`/sbin/screenblanker'</tt> - 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 <tt>/sbin/screenblanker</tt>. Su fichero de comandos o salvapantallas debe atraparlo, y terminar. ¡Recuerde restaurar la pantalla al modo texto original! <sect>Fallos conocidos y cosas feas. <p> <sect1>Por qué obtengo el mensaje ``Cannot locate module for net-pf-X'' cuando ejecuto ifconfig <p> 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 <tt>/usr/src/linux/include/linux/socket.h</tt> para comprender el significado de cada número). Desafortunadamente, <tt/ifconfig/ genera estos mensajes, por lo que mucha gente obtiene unos cuantos mensajes registrados cuando el sistema arranca y ejecuta <tt/ifconfig/ para configurar el dispositivo <em/loopback/. Los mensajes son totalmente inofensivos, y puede desactivarlos añadiendo las líneas <tscreen><verb> 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 </verb></tscreen> a <tt>/etc/conf.modules</tt>. Por supuesto, si usa IPS como módulo, no debe añadir la línea para deshabilitar IPX. <sect1>Depués de arrancar kerneld, mi sistema se ralentiza cuando activo mi conexión PPP <p> Han habido unos cuantos informes de este problema. Parece ser consecuencia de alguna desaforunada interacción entre kerneld y el script <tt/tkPPP/ que se usa un varios sistemas para configurar y monitorizar la conexión PPP - el script aparentemente ejecuta bucles mientras ejecuta <tt/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. <sect1>¡Kerneld no carga mi controlador de SCSI! <p> Añada una entrada para el adaptador SCSI en su <tt>/etc/conf.modules</tt>. Vea la descripción de la entrada <tt/``scsi_hostadapter''/ descrita anteriormente en este documento. <sect1>¡modprobe se queja de que `gcc2_compiled' está indefinido! <p> Este es uno de los fallos de las utilidades de módulos, que aparece solo con las <tt/binutils/ 2.6.0.9 y posteriores, y está documentado en la documentación de binutils. Así que lea las <em/``release notes''/ de las binutils. Otra opción es obtener una actualización de las <tt/module-utilities/ que superen este problema, por ejemplo <tt/modules-2.0.0/. <sect1>Mi controlador de sonido se olvida de la configuración del volumen <p> 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 <tt/``post-install''/. <sect1>DOSEMU necesta algunos módulos - ¿cómo puedo hacer que kerneld los cargue? <p> 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. <sect1>¿Por qué obtengo los mensajes ``Ouch, kerneld timed out, message failed''? <p> 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 <tt>/usr/sbin/kerneld</tt>. Si el problema persiste, deberá enviar un mensaje electrónico con un informe de fallo a <htmlurl url="mailto:linux-kernel@vger.rutgers.edu" name="linux-kernel@vger.rutgers.edu">, pero <em/por favor/ asegúrese de que dispone de las últimas versiones del kernel y de kerneld antes de dar a conocer el problema. <sect1>mount no espera a que kerneld cargue el módulo del sistema de ficheros <p> Ha habido unos cuantos mensajes indicando que el comando <tt/mount(8)/ no espera a que kerneld cargue el módulo del sistema de ficheros. <tt/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 <tt/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. <sect1>kerneld falla al cargar el módulo ncpfs <p> Necesita compilar las utilidades ncpfs con <tt/-DHAVE_KERNELD/. Vea el Makefile de ncpfs. <sect1>kerneld falla al cargar el módulo smbfs <p> Está usando una versión antigua de las utilidades <tt/smbmount/. Obtenga la última versión (0.10 o posterior) de <htmlurl url="ftp://tsx-11.mit.edu/pub/linux/filesystems/smbfs/" name="ftp://tsx-11.mit.edu/pub/linux/filesystems/smbfs">. <sect1>He construido todo como módulos, y ahora mi sistema no arranca / kerneld falla al cargar el módulo del sistema de ficheros raíz <p> No puede modularizarse <bf/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 <itemize> <item>Los controladores del disco duro donde se encuentra su sistema de ficheros raíz. <item>El controlador del sistema de ficheros raíz. <item>El formato binario para <tt/init/, <tt/kerneld/ y otros programas. </itemize> (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 <tt>Documentation/initrd.txt</tt> que viene con los fuentes del kernel.) <sect1>kerneld no se inicia en tiempo de carga del sistema - se queja de libgdbm <p> Las nuevas versiones de kerneld necesitan la librería dbm de GNU, <tt/libgdbm.so/, para poder ejecutarse. Muchas instalaciones tienen este fichero en <tt>/usr/lib</tt>, pero probablemente esté intentando ejecutar kerneld antes de que su sistema de ficheros de <tt>/usr</tt> 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 <tt>/usr</tt> haya sido montado, o mover la librería a su sistema de ficheros raíz, por ejemplo a <tt>/lib</tt>. <sect1>Obtengo ``Cannot load module xxx''; ¡pero acabo de reconfigurar mi kernel sin el soporte para xxx! <p> La instalación Slackware (y posiblemente otras) crean un fichero <tt>/etc/rc.d/rc.modules</tt> 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 <tt/rc.modules/, y por eso el error. Modifique su <tt/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. <sect1>He vuelto a compilar mi kernel y los módulos, y todavía siguen los mensajes sobre símbolos sin resolver cuando carga el sistema <p> 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 <tt>/lib/modules</tt>. La solución más fácil es borrar el directorio <tt>/lib/modules/x.y.z</tt> y volver a hacer un <tt/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. <sect1>He instalado Linux 2.1 y ahora no puedo cargar NINGÚN módulo <p> 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 <itemize> <item>Leer los ficheros de documentación y cambios y ver qué paquetes es necesario que actualize en su sistema. <item>Usar la última versión del paquete <tt/modutils/, el cual puede obtenerse en <htmlurl url="ftp://tsx-11.mit.edu/pub/linux/packages/alphabits/" name="ftp://tsx-11.mit.edu/pub/linux/packages/alphabits/">. </itemize> Le recomendaría que usara como mínimo el kernel 2.1.29, si desea usar los módulos con un kernel 2.1. <sect1>Qué hay del trabajo con redes <em/dial-on-demand/ <p> 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 <tt>/sbin/request_route</tt> 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 <tscreen><verb> Todo el tema de la request-route es obsoleto, olvidado y no es necesario [...] Se ha eliminado de los árboles de 2.1.x </verb></tscreen> En vez de usar el fichero de comandos <tt/request-route/ y kerneld, yo recomiendo la instalación del paquete <tt/diald/, que puede encontrarse en <htmlurl url="http://www.dna.lth.se/~erics/diald.html" name="http://www.dna.lth.se/~erics/diald.html">. <sect>Mensajes de Copyright <p> 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 <tt/gregh@sunsite.unc.edu/. </article>