C
ualquier experto nos diría que Linux es el kernel, es decir, la capa de abstrac-ción de hardware y todo lo que vemos a través de nuestra pantalla no suelen ser más que aplicaciones de software de la colección GNU. Linux es el núcleo del sistema operativo que hace que una máquina sea utilizable al estilo Unix. A nivel técnico, un kernel consta de los siguientes componentes básicos: • soporte para el hardware y loscorrespon-dientes controladores;
• un planificador de tareas (el denominado scheduler), que distribuye entre los distintos programas la capacidad de computación disponible (ciclos de CPU) y los recursos de hardware, permitiendo que dichos progra-mas se ejecuten independientemente sin que se produzcan conflictos o dobles blo-queos (deadlocks);
• un gestor de memoria virtual y de sistemas de archivos que adjudica memoria y espa-cio disponible en disco a los programas del sistema.
La mayoría de los usuarios se conforman con el kernel incluido en su distribución de Linux sin preocuparse de nada una vez lo están usando. Pero puede darse el caso de que nece-sitemos un controlador o un componente del sistema que no esté compilado en nuestro sis-tema Linux, o incluso puede que simplemente queramos jugar un poco con nuestro kernel, decidiéndonos un día a reemplazarlo, recom-pilarlo o a ampliar sus funcionalidades. En este artículo describiremos algunas de las téc-nicas con las que llevar a cabo todas estas tareas.
¿Por Qué Actualizar?
Si nos fijamos en los changelogs de las últi-mas versiones de Linux publicadas, podemos ver una enorme cantidad de bugs soluciona-dos y de nuevas funcionalidades que dan la impresión de que vamos a disfrutar de increí-bles mejoras en el rendimimento y la estabili-dad, todo con la actualización de un solo paquete. Por desgracia, la realidad no es tan simple. Debido al rápido desarrollo del kernel, se liberan nuevas versiones prácticamente cada mes. La mayoría de ellas no aportan cambios significativos, a no ser que estemos buscando algo muy específico. E incluso cuando se anuncia un nuevo subsistema o componente en las noticias, es bastante improbable que dispongamos en nuestros repositorios de la última versión del kernel. Casi todas las distribuciones proporcionan versiones estables y bien testeadas que podrían contener ciertas funcionalidades nue-vas y mejoras sobre las publicaciones más novedosas pero conservando un número de versión más bajo por motivos de compatibili-dad con módulos de terceras partes. Si lo que buscamos es la versión más actual (aunque probablemente poco testeada), tendremos que compilar el kernel nosotros mismos.
¿Por qué querría alguien preocuparse por actualizar su kernel Linux? Puede que tras
KERNEL TEC
Cuando se necesitan controladores para dispositivos de hardware de
terceros, o incluso a la hora de reparar un sistema, puede que sea
nece-sario actualizar el kernel Linux. POR KLAUS KNOPPER
robert fori, Fotolia
pasar un montón de tiempo hackeando nues-tro sistema Linux nos veamos en la tesitura de tener que arreglar un sistema que se nos ha roto porque nos hemos olvidado de alguna opción importante. O, en algunos casos, es posible que el nuevo kernel contenga un con-trolador o un módulo que mejore el soporte para algún dispositivo de hardware. En otros, la actualización podría incluso suponer un importante agujero de seguridad.
Comprobando la Versión del
Kernel
Para determinar qué versión de kernel esta-mos ejecutando abriesta-mos una terminal e intro-ducimos:
uname -a
con lo que debería aparecernos algo como:
Linux eeepc 2.6.26.5-eeepc U
#13 PREEMPT Thu Oct 9U
04:04:42 CEST 2008 i686 U
GNU/Linux
Otro comando,
cat /proc/version
nos informa además acerca del compilador usado para construir nuestro kernel.
Como veremos más adelante, esta información nos puede resultar útil a la hora de trabajar con módulos del kernel:
Linux version U
2.6.26.5-eeepcU
(knopper@Koffer) U
(gcc version 4.3.2 U
(Debian 4.3.2-1) U
) #13
PREEMPT Thu Oct 9U
04:04:42 CEST 2008
La salida mostrada pone de manifiesto varios aspectos del sistema:
• El kernel pertenece a la serie 2.6. • La revisión secundaria es la 26.
• El nivel de parche (seguramente para la solución de bugs) es 5.
• Probablemente se compiló para un sistema EeePC, aunque esta cadena puede especifi-carse en el campo EXTRA-VERSION del Makefile del kernel.
• La arquitectura del sistema está basada en i686, que soporta las instrucciones máquina de Pentium 2 y superiores, pero no las de las máquinas basadas en 386 y 486.
• La versión de GCC utilizada para compilar este kernel desde el código fuente fue la 4.3.2 en un sistema Debian. El binario se obtuvo a partir de la decimotercera ejecu-ción del compilador sobre las mismas fuen-tes. La compilación se llevó a cabo el Jue-ves 9 de Octubre de 2008.
• El kernel es preemptive. Es decir, ha sido compilado con el propósito de ser usado en un sistema de escritorio con una interac-ción más rápida que una máquina orien-tada a servidor de computación.
Toda esta información detallada acerca del estado del sistema actual, proporciona un punto de partida interesante para la compren-sión del proceso de actualización del kernel.
Actualización de Paquetes
La mayoría de las distribuciones Linux pro-porcionan un método sencillo de actualiza-ción del kernel a través del gestor de paquetes del sistema. Si no necesitamos un kernel per-sonalizado u optimizado, actualizarlo a través del gestor de paquetes de nuestra distribución suele ser más sencillo que compilarlo e insta-larlo manualmente y por nuestra propia cuenta.
Aquí describimos cómo actualizar nuestro kernel a través de Aptutide, el sistema de ges-tión de paquetes basado en Debian. Los
con-ceptos son similares para el resto de sistemas. En caso de tratarse de otro gestor de paquetes, se recomienda consultar su documentación.
Los paquetes del kernel en Debian solían llamarse kernel-image. Recientemente se les cambió el nombre por linux-image. Los foro-fos de la línea de comandos quizás prefieran instalar la nueva imagen de kernel con el comando
aptitude install U
linux-image-686
en lugar de hacerlo mediante un gestor de paquetes gráfico. En cualquier caso, los pasos ejecutados son básicamente los mismos:
1. El paquete se descomprime y desempa-queta en una nueva ubicación. La parte está-tica del kernel va a /boot/vlinuz-numerodever-sion-arquitectura; los módulos del kernel van a /lib/modules/numerodeversion.
2. Unos scripts comprueban si para nuestro sistema es necesaria o no una ramdiskinicial; de serlo, se instalan los módulos necesarios en un archivo llamado /boot/initrd.img-numerodeversion-arquitectura. La herra-mienta del sistema mkinitramfses la respon-sable de la creación de dicho archivo. Sus archivos de configuración se encuentran bajo /etc/initramfs-tools/, que es donde se hacen determinadas configuraciones, como por ejemplo los cambios en la configuración de la ramdisk. A no ser que los nombres de los módulos cambien, o que tengamos planeado activar software para RAID o LVM, no deberí-amos tocar nada aquí.
3. Se le notifica al cargador de arranque la existencia de un nuevo kernel para que pre-sente la correspondiente opción de arranque. A menos que se elimine el kernel antiguo (algo que no debería ocurrir automática-mente), su entrada permanecerá en el archivo de configuración del cargador de arranque, así que podremos escoger el kernel antiguo desde el menú del cargador de arran-que.
Antes de reiniciar el sistema, comprobare-mos lo siguiente:
PORTADA
• Trabajando con el Kernel
20
Número 49 W W W . L I N U X - M A G A Z I N E . E S El kernel tiene cierta capacidad deinteractividad – podemos arrancarlo especificando opciones que afectarán a parte de su funcionamiento o que incluso modificarán algunos de sus valores en el momento de arrancarlo y sin tener que reiniciar. El usuario técni-camente preparado suele disfrutar jugando con sus opciones.
Opciones del Kernel
01 image=/vmlinuz
02 initrd=/initrd.img
03 label=Linux
04 image=/vmlinuz.old
05 initrd=/initrd.img.old
06 label=Linux -old
Listado 1: /etc/lilo.conf
Compilación y
Personalización del
Kernel
Podemos personalizar un kernel para situaciones específicas, o bien aña-dirle nuevas funcionalidades ausen-tes en el kernel predeterminado de nuestra distribución. Para ello tene-mos que probar suerte y compilar el kernel nosotros mismos. Comenza-mos instalando el ensamblador y el compilador de C (los paquetes gccy binutils). Por ejemplo, en Debian, basta con ejecutar
sudo aptitude install U
binutils gcc make
Luego obtenemos las fuentes del kernel desde el sitio web de kernel.org [1], o desde uno de sus mirrors, y las desempaquetamos. En vez de instalar la última versión, podemos conse-guir la última versión principal y aplicar los parches publicados posteriormente:
wget -c http://www.kernel.org/U
pub/linux/kernel/v2.6/U
linux-2.6.28.tar.bz2
tar jxvf linux-2.6.28.tar.bz2
Los siguientes pasos dependen de si quere-mos cambiar algo en la configuración de nuestro antiguo kernel o actualizarlo deján-dolo todo como estaba.
Después de desempaquetar las fuentes del nuevo kernel, lo más sencillo es copiar pri-mero la configuración del kernel antiguo al nuevo directorio si no se van a hacer dema-siados cambios. Con esta estrategia nos aho-rramos tener que configurar los cientos de opciones una a una y determinar los valores que necesitará el sistema.
El conjunto de opciones y configuraciones del kernel se guarda en un archivo llamado .config(nótese el punto inicial; el archivo no es visible en primera instancia) ubicado en el directorio que contiene las fuentes del kernel, que en este caso sería linux-2.6.28/.config.
En Debian, disponemos de una copia del archivo .configdel actual kernel en el mismo directorio en el que se encuentra el binario del kernel (/boot/config-versiondelkernel). En otras distribuciones, conviene echar un vis-tazo dentro del paquete con las fuentes correspondientes a la versión del kernel insta-lado en el sistema.
Después de copiar la configuración del ker-nel antiguo al directorio de las fuentes del nuevo kernel, vamos a dicho directorio,
cd linux-2.6.28
y comenzamos con la configuración del ker-nel, moviéndonos por todas las opciones dis-ponibles.
Dependiendo de si hemos instalado los entornos de desarrollo Qt3o Gtk2, podemos compilar e iniciar un interfaz gráfico para configurar el kernel con
make xconfig
para un entorno basado en QT, o
make gconfig
para uno basado en Gtk (Figura 1).
Si los archivos de desarrollo no están insta-lados, los comandos no funcionarán. En ese caso disponemos de una alternativa basada en texto que sólo necesita las librerías de ncurses:
make menuconfig
Este comando se usó para crear la captura de la Figura 2.
Como último recurso,
make config
siempre funcionará, pero es necesario confir-mar una tras otra cada una de las opciones del kernel, por lo que el comando resulta bas-tante agotador.
Algunas opciones sólo son de tipo acti-vado/desactivado (como ciertas funcionalida-des que afectan a la parte estática del kernel); otras funcionalidades nos permiten elegir entre compilar el driver en el kernel o como un módulo que se cargará desde disco una vez activado el sistema de archivos inicial.
Para compilar un kernel optimizado para nuestro sistema debemos averiguar cuál es nuestro hardware. Es recomendable compilar el controlador de disco duro responsable del • ¿Tuvimos que instalar o recompilar
módu-los nuevos para que el sistema pudiese arrancar? En el improbable caso de que el controlador de nuestro medio de arranque principal necesitase un driver no incluido en el kernel o la ramdisk, tendremos que compilar e instalar el módulo correspon-diente antes de reiniciar; de no hacerlo, puede costarnos bastante arrancar el sis-tema con el nuevo kernel.
• ¿Está el cargador de arranque preparado correctamente para el nuevo kernel? Por ejemplo, LILO (the Linux Loader– uno de los primeros cargadores de arranque para Linux independiente del sistema de archi-vos) debería contener en su archivo /etc/ lilo.confalgo similar a lo mostrado en el Listado 1. En el caso del cargador de arran-que GRUB, el archivo /boot/grub/menu.lst debería contener entradas similares a las del Listado 2.
En el Listado 1, /vmlinuz.olde /initrd.img.old son enlaces simbólicos a los archivos anti-guos (pero existentes) del kernel y la ramdisk ubicados en /boot. Con este método podemos arrancar el kernel antiguo si el nuevo no fun-ciona como esperábamos. Si editamos /etc/ lilo.confmanualmente, debemos ejecutar el comando liloantes de reiniciar el sistema, ya que el cargador de arranque LILO necesita actualizar su registro de la ubicación del archivo del kernel. El cargador de arranque GRUB, por contra, utiliza su propio controla-dor para el sistema de archivos para poder localizar los archivos por sí mismo.
Si creemos que nuestro sistema está ya pre-parado para el nuevo kernel, podemos reini-ciar y comprobar si todo funciona correcta-mente. Si el nuevo kernel no arranca por alguna razón, basta con seleccionar el ante-rior desde el menú de arranque. De este modo se restaura la configuración previa.
PORTADA
• Trabajando con el Kernel
22
Número 49 W W W . L I N U X - M A G A Z I N E . E S 01 title=Linux02 root (hd0,0) 03 kernel /vmlinuz 04 root=/dev/hda1 05 initrd /initrd.img 06
07 title=Linux-old 08 root (hd0,0) 09 kernel /vmlinuz.old
root=/dev/hda1
10 initrd /initrd.img.old
Listado 2: /boot/grub/
menu.lst
Ya podemos empezar a compilar con un simple
make
que se tomará su tiempo. Antes de volver a ejecutar este proceso, es buena idea elimi-nar los bielimi-narios antiguos con make clean.
El proceso de compilación de los módu-los más experimentales puede fallar con según qué versiones de kernel y compila-dor. A menos que se esté familiarizado con el lenguaje C y se cuente con una prepara-ción suficiente como para editar el código fuente directamente, lo más sencillo es deshabilitar sin más el driver problemá-tico.
Después de compilar con éxito, ya pode-mos instalar el kernel:
• manualmente, con el comando sudo make install, que copia arch/i386/boot/ bzImagea /boot/vmlinuz-* y todos los módulos del kernel a /lib/modules/ numerodeversion/. Con el fin de infor-mar al cargador de arranque acerca de la existencia del nuevo kernel para que lo incluya entre las demás opciones de arranque, sigue siendo necesario editar lilo.conf (para LILO) o menu.lst(para GRUB) manualmente;
• creando e instalando un paquete específico para nuestra distribución. El gestor de paquetes debería encargarse de todas las modificaciones necesarias sobre la configuración del cargador de arranque y, de ser necesario, de crear una ramdisk ini-cial.
En Debian, el asistente para la creación de paquetes del kernel es make-kpkg, que se puede invocar desde el mismo directorio que contiene las fuentes del kernel:
make-kpkg —us —uc U
—rootcmd fakeroot U
kernel_image
Luego, instalamos el paquete del kernel resul-tante:
sudo dpkg -i ../U
linux-image-versionkernel*.deb
En las distribuciones basadas en RPM hay que editar el archivo .spec del paquete de fuentes del kernel antiguo para especificar la versión del nuevo kernel, y ejecutar rpm -ba archivo.specpara iniciar la compilación y cre-ación del paquete.
No hay que olvidar la obligatoriedad de (re)compilar todos los módulos que no for-man parte de las fuentes del kernel original.
Trabajando con los Módulos
del Kernel
Antes de desechar el kernel Linux antiguo y actualizar el sistema base entero, es preciso recordar que Linux proporciona una solución menos radical ante la integración de nuevos drivers y funcionalidades. Los módulos carga-bles por el kernel, o LKM(Loadable Kernel Modules, son piezas de código ejecutable que no pertenecen a la parte estática del kernel (base), sino que se cargan aparte, en una fase arranque de disco, así como el driver de disco
genérico (IDE/SATA), en el kernel.
Para averiguar qué driver del kernel es el adecuado para nuestro hardware, ejecuta-mos
lspci -vmm -k
que nos muestra además el nombre del com-ponente del kernel o módulo correspondiente a un chipset determinado.
Normalmente, no pasa nada por compilar módulos para hardware que no tenemos. Estos drivers se ignoran mientras no se detecte nuevo hardware y Udev, el sistema de detección automática de hardware bajo demanda, los cargue. Sólo hay que tener cui-dado con drivers recíprocamente excluyentes. El sistema USB, por ejemplo, soporta varios que no siempre son intercambiables. El driver de bajo rendimiento ub(USB block), se sabe que empeora drásticamente el rendimimento y la estabilidad de dispositivos de almacena-miento USB que funcionarían perfectamente con el driver usb-storage.
Durante la configuración del kernel nos encontramos con varias opciones que pare-cen importantes pero que no son muy auto-explicativas. El archivo de ayuda de la configuración proporciona una visión general (que no siempre resulta de ayuda); se puede encontrar más documentación en el directo-rio Documentationde las fuentes del kernel – el archivo kernel-parameters.txtes especial-mente interesante. El método más seguro, en cualquier caso, es conservar la configuración predeterminada, que funciona con casi todas las combinaciones de hardware.
Después de terminar de configurar el ker-nel, salimos de la interfaz de configuración con Save Changes.
PORTADA
• Trabajando con el Kernel
24
Número 49 W W W . L I N U X - M A G A Z I N E . E SHay muchas distribuciones que sólo compilan un juego mínimo de drivers directamente en el kernel estático para instalar luego el resto de drivers en forma de módulos en el sistema de archivos raíz. Los drivers necesarios para el montaje del sistema de archi-vos raíz se guardan en la ramdisk ini-cial. Personalmente prefiero prescindir de la ramdisk inicial en las instalacio-nes en disco duro, y compilar directa-mente en el kernel los drivers necesa-rios para el acceso a disco. Lo mismo ocurre con los drivers USB, que pue-den ser necesarios en fases muy tem-pranas del proceso de arranque (por ejemplo, teclados USB o almacena-miento en discos externos). Si el sis-tema de archivos raíz se encontrase parcialmente dañado y no pudiésemos cargar más drivers desde él, aún podrí-amos montar otros medios desde una terminal de emergencia y recuperar el sistema. Además, el proceso de arran-que es más simple si no hay una ram-disk de por medio. Pero esto, como siempre, es cuestión de gustos.
¿No Hay ramdisk?
Hay hardware que cuenta con más de un driver, pero de entre los disponibles, tenemos que elegir uno necesaria-mente. Los controladores de discos duros IDE, por ejemplo, funcionan tanto con los drivers de dispositivos de blo-ques IDE como con la nueva interfaz PATA, que se conecta a SATA. Para los controladores que cuentan tanto con puertos SATA como con puertos IDE, la combinación SATA/PATA puede que sea la más adecuada. A veces también puede funcionar el activar simultánea-mente los controladores IDE y SATA/ PATA: Tan pronto como un driver blo-quea los recursos de E/S, el otro falla sin
mayores repercusiones. Pero otras veces la cosa no va tan bien y cada dri-ver bloquea partes del otro, impidiendo el acceso directo a memoria (DMA), ralentizándose o desapareciendo los discos duros, o produciéndose reseteos o tiempos de espera agotados. Si esco-gemos el driver SATA/PATA para el con-trolador de un disco duro en vez del dri-ver IDE que se solía usar, debemos ase-gurarnos de cambiar /dev/hda por /dev/ sda en /etc/fstab, ya que PATA trata los discos duros como discos SCSI. Debe-mos hacer lo mismo con las líneas root=/dev/hda1 de los archivos lilo.conf o menu.lst.
posterior del proceso de arranque. Los drivers de dispositivos, drivers de sistemas de archi-vos y otras ampliaciones personales se suelen implementar en forma de módulos del ker-nel. Al separar el código en un módulo aparte, se elimina la necesidad de actualizarlo todo cuando sólo se quiere añadir un único componente.
El kernel proporciona cientos de drivers para hardware, pero a veces, como sucede
con los nuevos modelos de portátil, algu-nos (como WLAN, LAN y muchos dri-vers para cámaras) sólo se encuentran disponibles en proyectos independien-tes, sin estar aún aceptados para ser incorporados al kernel. En otros casos, la misma licencia podría suponer un impe-dimento a la hora de integrar el código en el kernel base, o el código podría no estar lo suficientemente testeado como para alcanzar los estándares de calidad exigidos por el grupo de desarrollo del kernel. En estos casos, lo que se suele hacer es obtener el código fuente de dichos módulos y compilarlo uno mismo.
Se pueden encontrar módulos en forma de paquetes con código fuente en sitios como SourceForge [2]. Algunos ejemplos destacados de módulos del kernel disponi-bles públicamente son MadWifi [3] (para ciertos chipsets WiFi muy extendidos) y GSPCA [4] (para cámaras web). Por desgra-cia, a veces no resulta sencillo compilar el código fuente de un módulo con los kernels
más nuevos debido a los errores provoca-dos por cambios en la API del kernel.
Antes de compilar nuevos módulos debe tenerse en cuenta que, para este tipo de tareas, se necesitan exactamente las mismas fuentes del kernel que se usaron en la compi-lación de su binario (para que acepten el nuevo módulo en tiempo de ejecución), así como la misma versión del compilador GCC. Bajo determinadas circunstancias, también es posible cargar módulos compilados para otros kernels (ligeramente diferentes), mediante insmod -f, pero se corre el riesgo de desestabilizar el sistema con instrucciones de código máquina y símbolos que no concuer-dan en el kernel. Si el kernel instalado es el proporcionado por nuestra distribución (desde DVD o repositorios de internet), es bastante probable que esté disponible tam-bién su árbol de fuentes.
El sistema Makefilede la versión 2.6 del kernel nos ofrece una manera sencilla de ave-riguar las opciones de compilación correctas necesarias para la construcción de nuevos módulos para nuestro kernel, ahorrando
Para compilar un kernel capaz de ejecu-tarse en una variedad lo más amplia posible de placas y procesadores dife-rentes (o al menos en las distintas variantes basadas en *86), se ha de leer con detenimiento el archivo de ayuda con las opciones específicas de cada procesador y elegir optimizaciones genéricas y valores conservadores, en vez de características específicas de cada procesador y funcionalidades para la mejora de la velocidad. Un kernel compi-lado para procesadores 80386 se ejec-tuará en cualquier AMD o Pentium reciente; un kernel compilado para pro-cesadores modernos no funcionará en un procesador más antiguo. La mejora del rendimiento de un kernel compilado específicamente para un procesador determinado es relativamente baja (en torno al 5-8%) debido a que los progra-mas de escritorio suelen hacer menos llamadas a las funcionalidades extendi-das del procesador, a menos que este-mos usando un juego con muchos cál-culos rápidos y un rendimiento conside-rable. Incluso puede que no se note mucho que hemos compilado un kernel para procesadores nativos de 64 bits, si lo que ejecutamos son aplicaciones de 32 bits. La mayoría de las CPUs de 64 bits pueden ejecutar aplicaciones de 32 bits, pero no al revés. El tamaño de
memoria máximo soportado también podría suponer un problema: Los proce-sadores con soporte para PAE (Physical Address Extension) pueden hacer uso de hasta 64GB de RAM, pero un kernel compilado con PAE fallará inmediata-mente con un procesador sin soporte para PAE. La opción más segura es limi-tar la cantidad a 4GB, que es una canti-dad válida para la mayoría de procesa-dores de 32 bits, de la cual sólo en torno a 3GB es RAM útil, mientras que el resto se destina a direccionamiento interno. En máquinas que nunca tendrán más de 1GB de RAM, la opción no high memory support habilita la configuración más adecuada para el direccionamiento de memoria.
El resto de opciones que mejoran el ren-dimiento del kernel y lo hacen más flexi-ble son todas inherentes al tipo de pro-cesador y a la sección de funcionalida-des. Aquí podemos seleccionar de forma segura Symmetric Multiprocessing (pero no necesariamente los planificado-res optimizados para SMP/hyperthrea-ding), Preemptible Kernel (Escritorio con menores retardos) y Generic x86 Sup-port (optimizaciones para toda una fami-lia de procesadores). Para el resto de opciones, es mejor leer la ayuda antes de hacer cualquier cambio. Algunas son
inofensivas y mejoran el rendimiento del sistema bajo determinadas circunstan-cias, mientras que otras limitan el número de procesadores en los que fun-cionará el kernel. Normalmente, habilitar Symmetric Multiprocessing (SMP) no suele tener consecuencias no deseadas, incluso con procesadores antiguos, que lógicamente no lo soportan. El kernel comprueba si el procesador soporta SMP (o hyperthreading); de no sopor-tarlo, se usan procedimientos para monoprocesador. Habilitar SMP en siste-mas sin capacidad de multiprocesa-miento, normalmente hace que el kernel sea ligeramente más grande, pero no se nota ninguna diferencia en cuanto a velocidad a menos que se esté ejecu-tando en una máquina muy antigua o lenta. Algunas placas reportan errónea-mente tener dos procesadores cuando realmente sólo tienen uno instalado, provocando un colapso al habilitar SMP indebidamente. En estos casos se puede forzar el modo monoprocesador con las opciones de arranque nosmp o maxc-pus=0. Con módulos del kernel de los que sólo se dispone de los binarios (módulos que probablemente haya que cargar mediante insmod -f), puede que sea necesario que el kernel no sea SMP, ya que podría haber instrucciones incompatibles en su API.
Ajustándonos al Hardware
Si se coloca el módulo dentro de un direc-torio llamado modulesun nivel por encima de las fuentes del kernel, make-kpkgtratará de compilar y de crear un paquete Debian con él automáticamente después de terminar su tarea con el kernel.
Conviene instalar los nuevos módulos bajo /lib/modules/versiondelkernel/ (a veces se usa un subdirectorio llamado extra) y prepa-rar la carga automática de dependecias con
depmod -ae
Si la versión del kernel actual no es la misma que la del kernel con el que vamos a usar el módulo, añadimos la versión como último argumento del comando. Ahora ya debería-mos poder cargar el módulo mediante el comando modprobe nombredelmodulo.
Después de cargar el módulo, dmesg mues-tra los errores que se hayan podido producir. Cuando la versión del módulo no concuerda con la del kernel en ejecución, el error apa-rece en dmesg, en vez de hacerlo en la termi-nal desde la que se ejecutó insmodo mod-probe. El mensaje invalid module format – symbol versions mismatchindica justo eso, que el módulo no fue compilado con las fuen-tes correspondienfuen-tes al kernel en ejecución.
¡El Sistema Ha Muerto!
A veces ocurre que la actualización del kernel parece terminar con éxito,
pero luego el sistema no arranca. Que no cunda el pánico (aunque el kernel lo sufra). En la Figura 3 se ilustra un ejemplo de la salida que podríamos tener con un arranque fallido. Antes de profundizar en los detalles sobre cómo actuar ante esta situación, es buena idea repasar el típico inicio de un PC basado en *86. Antes de comenzar cualquier multitarea, el sis-tema lleva a cabo un pro-ceso muy lineal. En la Figura 4 se muestran los cinco pasos principales que la máquina lleva a cabo nada más encenderse (el 4º paso es opcional, pero la mayoría de las distribucio-nes lo realizan). Los prime-ros estadios del proceso son independientes del sis-tema operativo que se vaya
a ejecutar. Los procedimientos dependientes del sistema operativo no comienzan hasta lle-gados al tercer paso. En caso de que algo fuese mal, si el sistema no arrancase, lo primero que habría que hacer sería identificar en qué parte del proceso ocurrió el fallo, revelando la fuente del problema.
Si la BIOS no pudiese identificar ningún dispositivo arrancable, el mensaje diría algo como no bootable harddisk found, hit return to continue. Los fallos producidos durante el paso 2 normalmente acaban mostrando erro-res del cargador de arranque que dicen que no pueden encontrar el archivo del kernel en el disco duro para cargarlo, lo que significa que puede que hayamos especificado mal el nombre del archivo en la configuración, o nos hayamos olvidado de ejecutar lilodespués de editar el archivo lilo.conf; o grubno tenga el plugin para el sistema de archivos necesario para encontrar en el disco el archivo del ker-nel. Quizá el nombre de archivo sea dema-siado complicado para la sencilla implemen-tación del sistema de archivos de grub, o de nuevo puede que hayamos escrito mal el nombre o hayamos introducido un disco duro incorrecto en menu.lst.
En la Figura 3, el paso 3 parece haberse lle-vado a cabo correctamente, puesto que no se muestra ningún error fatal ni se colgó la máquina durante la primera inicialización del hardware por parte del kernel. Debido a que parte del trabajo a los desarrolladores de
módulos.
Usaremos cloop, el dispositivo de loopback comprimido, como ejemplo de compilación e instalación de módulos del kernel, ya que se ha de recompilar cada vez que se actualiza el kernel de un LiveCD.
El código fuente de Cloopestá disponible en Internet [5]. Para desempaquetar el tarball usamos
tar zxvf cloop_2.628-2.tar.gz
Después de entrar en el directorio cloop-2.628, compilamos el módulo con:
make obj-m=cloop.o cloop-objs=U
compressed_loop.o -C U
/mnt/knoppix.build/U
Microknoppix/Kernel/U
linux-2.6.28 M=`pwd`
Se trata de un proceso bastante genérico que debería funcionar con la mayoría de los módulos. Debe haber un Makefileen el direc-torio raíz de las fuentes del módulo, aunque podría estar vacío en caso de que obj-my modulename-objsestén definidos como varia-bles en el comando make. La declaración obj-m=cloop.oindica al Makefile del kernel que el objeto principal del módulo se llamará cloop.o, mientras que cloop-objs=compres-sed_loop.c le dice que compile el archivo fuente de C compressed_loop.ccomo único componente de cloop.(k)o.
El resto lo gestiona el Makefile del kernel, ubicado en el directorio /mnt/knoppix.build/ Microknoppix/Kernel/linux-2.6.28, especifi-cado mediante la opción -Cdesde la línea de comandos. En el Listado 3 se muestra el pro-ceso de compilación.
El módulo cloop.ko, que ya se puede cargar usando insmod, aparece entonces en el direc-torio actual. Algunos módulos ya vienen con su propio Makefile, que es el que deberíamos probar primero, aunque es casi seguro que habrá que especificar la ubicación de las fuentes del kernel antes de empezar a compi-lar. De no existir un enlace simbólico /usr/src/ linux apuntando a dicha ubicación, el comando
sudo ln -snf U
/ruta/a/las/fuentes/del/kernelU
/usr/src/linux
puede resultarnos útil para no tener que andar indicándole al Makefile de cada módulo dónde ha de buscar las fuentes.
PORTADA
• Trabajando con el Kernel
26
Número 49 W W W . L I N U X - M A G A Z I N E . E Sla salida no muestra ningún mensaje de tipo unable to load ramdisk, podemos creer que el paso 4 se ha llevado a cabo correcta-mente. Pero en realidad es posible que la ramdiskempleada por el cargador de arran-que se sobreescribiera al descomprimir en memoria la imagen del kernel. Normal-mente, este problema ocurre cuando el ker-nel estático resulta demasiado grande como para caber en la zona de memoria anterior a la destinada para la ramdisk(que es una dirección fija en la mayoría de los cargadores de arranque). Este problema suele darse cuando la imagen del kernel sobrepasa los 2.5MB de tamaño aproximado. Nosotros ni siquiera usamos una ramdisk. En lugar de eso, compilamos dentro del kernel todos los drivers necesarios para el montaje del sis-tema de archivos raíz.
El arranque ha ido bien hasta el paso 5, momento en el que el kernel monta el sis-tema de archivos raíz y le pasa el control al primer programa, init. Las posibles causas de un fallo en esta fase son:
• El tipo de sistema de archivos necesario para acceder a la partición raíz no está compilado en el kernel ni se encuentra dis-ponible como módulo en la ramdisk. • El driver controlador del disco duro no se
encuentra presente (que no es el caso en la Figura 3).
• Se especificó una partición raíz errónea como argumento para el kernel, bien desde el cargador de arranque o desde la línea de comandos del arranque.
• El disco duro está estropeado o mal confi-gurado en la BIOS.
Puede haber otras causas implicadas en el fallo, pero las anteriores son, sin duda
alguna, las más comunes. Si falta el soporte para el driver del disco duro, del controlador, o del sistema de archivos, es necesario volver a configurar y recompi-lar el kernel, por lo que primero habría que activar el kernel anterior.
Si ya no disponemos del kernel anti-guo o éste no funcionase, podemos eje-cutar un sistema LiveCD desde una memoria flash o desde un CD/DVD. Desde una terminal de root, montamos la partición con
mount -o dev /dev/sda1 U
/media/sda1
y hacemos un
chroot /media/sda1
para acceder al sistema de archivos como si el sistema hubiese arrancado directamente. Desde aquí, podemos montar todas las parti-ciones con
mount -a
y, eventualmente, compilar un nuevo kernel, arreglar el cargador de arranque y volver a intentarlo. Es probable que no queramos recompilar como root, así que sólo tenemos que cambiar a un usuario común con su -nombredeusuario. No debemos olvidarnos de volver a montar todas las particiones – al menos en modo de sólo lectura, si no des-montarlas – para forzar/escribir los cambios a disco:
umount -arvf
Conclusiones
Instalar un nuevo kernel no es como insta-lar esa nueva versión de OpenOffice que añade nuevas funcionalidades y mejoras a nuestra rutina diaria. Los kernels de las ver-siones principales, así como los kernels experimentales, no suelen ser tan rápidos debido a los efectos colaterales que sus desarrolladores no previeron. Al contrario que cualquier aplicación de software, un nuevo kernel no proporciona necesaria-mente mejores servicios ni más capacida-des. Si ya tenemos un kernel estable y no sufrimos reseteos repentinos, ni cuelgues, no hay ninguna razón que nos lleve a creer que un nuevo kernel supondría necesaria-mente una mejora.
A menos que se estén experimentando errores importantes durante su uso, pode-mos conservar nuestro viejo kernel sin temor alguno. Las principales razones para actualizar un kernel son corregir problemas o añadir nuevo hardware no soportado.
Cuando se está trabajando con una amplia variedad de drivers, o se necesita personalizar el sistema para un uso especí-fico, las técnicas descritas en este artículo no son un mal comienzo para la compila-ción y actualizacompila-ción del kernel Linux. ■
01 make: Entering directory
`/mnt/knoppix.build/Microknoppix/Kernel/linux-2.6.28’ 02 LD
/mnt/knoppix.build/Microknoppix/Kernel/cloop-2.628/built-in.o 03 CC [M]
/mnt/knoppix.build/Microknoppix/Kernel/cloop-2.628/compressed_loop.o 04 LD [M] /mnt/knoppix.build/Microknoppix/Kernel/cloop-2.628/cloop.o 05 Building modules, stage 2.
06 MODPOST 1 modules 07 CC
/mnt/knoppix.build/Microknoppix/Kernel/cloop-2.628/cloop.mod.o 08 LD [M]
/mnt/knoppix.build/Microknoppix/Kernel/cloop-2.628/cloop.ko 09 make: Leaving directory
`/mnt/knoppix.build/Microknoppix/Kernel/linux-2.6.28’
Listado 3: Salida
[1] Kernel.org: http://www.kernel.org
[2] SourceForge: http://sourceforge.net/
[3] MadWifi: http://madwifi-project.org/ wiki/About/MadWifi
[4] GSPCA: http://mxhaard.free.fr/
[5] Código fuente de Cloop: http:// debian-knoppix.alioth.debian.org/ sources/
RECURSOS
Hay veces que resulta interesante arrancar un nuevo kernel directamente desde un sistema Linux en ejecución. Sólo es posible cuando el kernel en eje-cución soporta la llamada al sistema kexec y las utilidades de kexec están correctamente instaladas.
kexec —initrd=U
/boot/initrd.img-2.6.28 U -append=”root=/dev/sda1” U -l /boot/vmlinuz-2.6.28 kexec -e
Con esta técnica nos saltamos los pasos 1 (BIOS) y 2 (bootloader), car-gando e iniciando el nuevo kernel (y la ramdisk inicial) directamente.
