|
Compilación del núcleo de Linux
El hecho de disponer del código fuente del núcleo de Linux (de ahora en adelante, simplemente Linux) nos permite personalizarlo, por ejemplo, para incluir soporte de hardware adicional, características aún no incluidas de serie, corregir problemas conocidos sin depender de que nuestro fabricante lo haga por nosotros o simplemente optimizar el tamaño o la velocidad de ejecución del mismo. Hay que decir sin embargo que esta característica de personalizar y optimizar el sistema operativo no es exclusiva de Linux: en la mayoría de los UNIX comerciales se puede llevar a cabo un proceso conocido como relinkado del núcleo, que consiste en reconstruir el archivo que contiene el sistema operativo para incluir características no presentes previamente, o parametrizar ciertas magnitudes. La diferencia principal es que el relinkado tiene lugar usando componentes binarios, en lugar de archivos de código fuente, como sucede en Linux. Además casi todos los sistemas operativos modernos son modulares, en el sentido de que no es necesario que el núcleo incluya soporte para todo el hardware o características disponibles, sino que existe un conjunto de funcionalidad básica (gestión de procesos, memoria, archivos, etc.) al que se puede añadir de manera más o menos sencilla soporte para más dispositivos o características, mediante los llamados módulos o drivers. Algunos sistemas operativos hay que reiniciarlos para que tomen efecto los cambios, en otros se puede hacer "en caliente", en otros es necesario relinkado e iniciar con la nueva versión del núcleo, etc. En este artículo nos vamos a centrar en describir el proceso para compilar el núcleo de Linux. Iremos paso por paso, detallando qué hay que hacer en cada momento, porqué, y los posibles problemas que nos podemos encontrar. Finalmente indicaremos la configuración necesaria en los dos gestores de inicio más conocidos, LILO y GRUB, para usar el núcleo recién compilado. En primer lugar tenga en cuenta que el núcleo proporcinado por su fabricante dispone de todo el soporte de características y dispositivos de que dispone la versión estándar que puede descargar de kernel.org, y muchas más que el fabricante incluye como servicio a sus clientes. Es decir, casi con toda seguridad su actual núcleo ya soporta todo lo que necesita, aunque para dispositivos especialmente modernos o cuyo funcionamiento no sea aún muy estable es posible que no tenga soporte, y pueda ser necesario recompilar. También puede resultar interesante recompilar para optimizar el núcleo que use, tanto su tamaño como su velocidad de ejecución. Es habitual que los núcleos de los fabricantes no estén optimizados para su procesador, y pueda aumentar el rendimiento recompilando específicamente para su modelo. Además, si sólo compila el soporte necesario para sus actuales dispositivos y para las características que necesita el núcleo será menor, y tenderá a ejecutar más rápido y a ocupar menos memoria. Aunque actualmente el soporte de módulos cargables y las opciones de compilación usadas por los fabricantes evitan en gran medida este problema. Otra posible motivación puede ser la de solucionar algún problema conocido, añadir alguna característica novedosa que desea probar, o actualizar a una versión superior a la proporcionada por su fabricante. Por último, también puede compilar el núcleo simplemente por aprender, y espero que este artículo le resulte útil en su aprendizaje. El primer paso para compilar un núcleo personalizado será obtener el código fuente del mismo, así como el de todos los añadidos que deseemos incluir. La localización de estos añadidos es muy diversa, pero el código fuente estándar del núcleo de Linux se encuentra en kernel.org. Verá que hay disponibles para descargar varias versiones diferentes, en principio debería descargar la correspondiente a la llamada serie estable, que actualmente es la 2.4.20. La actual serie en desarrollo, la 2.5.x, va por la versión 2.5.59, y cuando los desarrolladores consideren que ya es suficientemente estable, la etiquetarán como 2.6.0, que será la primera versión de la siguiente serie estable. No debería usar versiones en desarrollo salvo que sepa bien lo que está haciendo. Quizás le resulte más cómodo descargarse las fuentes del núcleo desde el servidor FTP de kernel.org. Bajo el directorio /pub/linux/kernel/v2.4/ dispone de las fuentes del núcleo para todas las versiones de la serie 2.4.x, así como multitud de archivos con nombres similares a patch-2.4.20.bz2: éstos son parches del núcleo que aplicados sobre las fuentes estándares de la versión inmediatamente anterior (2.4.19 en el ejemplo) nos generan las fuentes del núcleo de la versión indicada por el archivo. La utilidad de estos parches es fundamentalmente evitar la descarga de cada nueva versión completa de las fuentes del núcleo, así como ver en detalle los cambios realizados en las fuentes entre versiones consecutivas. Compruebe como un archivo con las fuentes completas del núcleo ocupa más de 25 MiB de tamaño, pero el parche para llegar a esta versión desde la inmediatamente anterior suelen ser menos de 3 MiB. Para probar esta idea de los parches, descargue la penúltima versión disponible de las fuentes del núcleo en el formato que desee (las versiones con extensión .tar.gz y .tar.bz2 son idénticas, pero por usar algoritmos de compresión diferentes ocupan distinto tamaño). Descargue también la versión del parche para subir a la versión inmediatamente posterior, así como las firmas de ambos archivos: usuario@cliente:/tmp$ wget ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.19.tar.bz2 ... Longitud: 26,042,494 (probablemente) ... usuario@cliente:/tmp$ wget ftp://ftp.kernel.org/pub/linux/kernel/v2.4/patch-2.4.20.bz2 ... Longitud: 4,165,346 (probablemente) ... usuario@cliente:/tmp$ wget ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.19.tar.bz2.sign ... Longitud: 248 (probablemente) ... usuario@cliente:/tmp$ wget ftp://ftp.kernel.org/pub/linux/kernel/v2.4/patch-2.4.20.bz2.sign ... Longitud: 248 (probablemente) ... Antes de hacer nada debería comprobar la autenticidad de los archivos que acaba de descargar, y para ello vamos a usar el comando gpg (incluido en el paquete GnuPG), del que ya hablamos un poco en este artículo sobre slrn. usuario@cliente:/tmp$ gpg --verify linux-2.4.19.tar.bz2.sign linux-2.4.19.tar.bz2 gpg: Firma creada el sb 03 ago 2002 02:43:13 CEST usando clave DSA ID 517D0F0E gpg: Firma correcta de "Linux Kernel Archives Verification Key <ftpadmin@kernel.org>" gpg: ATENCIN: Esta clave no est certificada por una firma de confianza! gpg: No hay indicios de que la firma pertenezca al propietario. Huellas dactilares de la clave primaria: C75D C40A 11D7 AF88 9981 ED5B C86B A06A 517D 0F0E usuario@cliente:/tmp$ Si obtiene un resultado como el anterior puede tener la certeza casi absoluta de que el archivo que ha descargado es realmente el archivo original de las fuentes del núcleo para esa versión. Repita la operación para el archivo de parche. Asegúrese de no olvidar esta verificación cada vez que descargue archivos de Internet, al menos cuando disponga de la posibilidad de hacerlo, que desgraciadamente no siempre sucede así. Lo siguiente será descomprimir las fuentes del núcleo en un directorio sobre el que tenga permiso de escritura. La localización predeterminada, y que recomendamos, es /usr/src, donde crear un directorio para la versión concreta de Linux que vayamos a compilar. En realidad este directorio se creará automáticamente, por cómo están empaquetadas las fuentes del núcleo en el archivo descargado. cliente:/tmp# cd /usr/src/ dardhal:/usr/src# tar jxvf /tmp/linux-2.4.19.tar.bz2 ... cliente:/usr/src# ls -l total 8 drwxr-xr-x 14 573 573 4096 2002-08-03 02:39 linux-2.4.19 drwxr-xr-x 7 root root 4096 2002-12-14 22:49 rpm cliente:/usr/src# chown -Rv usuario.usuario linux-2.4.19/ ... cliente:/usr/src# ln -s linux-2.4.19/ linux cliente:/usr/src# ls -l total 8 lrwxrwxrwx 1 root src 21 2003-01-25 20:18 linux -> linux-2.4.19/ drwxr-xr-x 14 usuario usuario 4096 2002-08-03 02:39 linux-2.4.19 Como puede ver es necesario ser root o pertenecera al grupo src para poder descomprimir las fuentes en este directorio. Las alternativas son muchas: instalar las fuentes como root, y luego cambiar los permisos a los de su usuario, meter a su usuario en el grupo src, o incluso usar un directorio sobre donde tenga permiso de escritura. En cualquier caso puede ser necesario ejecutar un comando chown como el mostrado para dejar el propietario y grupo de los archivos con valores consistentes. En enlace simbólico suele ser buena idea, puesto que algunos programas buscan archivos de cabeceras en /usr/src/linux, sobre todo en tiempo de compilación. Pruebe a entrar en el directorio recién creado, y mire lo que contiene. Como puede verficiar en las primeras líneas del archivo Makefile la versión de las fuentes es la 2.4.19. Si queremos aplicar el parche descargado y actualizar las fuentes a la versión 2.4.20 deberímos ejecutar el siguiente comando: usuario@cliente:/tmp$ cd /usr/src/linux-2.4.19/ usuario@cliente:/usr/src/linux-2.4.19$ bzcat /tmp/patch-2.4.20.bz2 | patch -s -p1 --dry-run usuario@cliente:/usr/src/linux-2.4.19$ bzcat /tmp/patch-2.4.20.bz2 | patch -p1 ... usuario@cliente:/usr/src/linux-2.4.19$ Si vuelve a consultar el archivo Makefile verá que ahora la versión es 2.4.20, como era de esperar tras aplicar el parche anterior. El primer comando patch nos sirve para ver si el parche aplicará limpiamente y en su totalidad, y con el segundo lo aplicamos de manera real, no simulada. Un parche que no aplique correctamente al 100% dejará un núcleo que no compilará, o peor aún, que sí lo hará pero que eventualmente fallará. Si alguna vez quiere "desaplicar" un parche, debería ejecutar el mismo comando patch usado para aplicarlo, pero con la opción adicional -R (reverse). Si quiere añadir soporte de hardware o funcionalidad adicional, actualizar el soporte de alguna característica ya presente en el núcleo, o solucionar algún fallo conocido, ahora es el momento de parchear las fuentes. Por ejemplo, supongamos que desea actualizar la versión de LVM (Logical Volume Manager) presente en el núcleo a la más reciente disponible (1.0.6 a día de hoy). Debemos acudir a la página oficial y descargarnos el archivo con la versión 1.0.6 del programa (lvm_1.0.6.tar.gz). No entraremos en detalles de cómo manejar este paquete, para eso están las instrucciones dentro del archivo descargado. Supongamos que tras seguir las instrucciones del programa obtenemos un archivo parche de nombre lvm-1.0.6-2.4.20.patch. Cualquier otro parche que nos bajemos de Internet o que generemos a partir de ciertos archivos será similar al anterior, o como mucho vendrá comprimido, como sucedía con el parche aplicado en párrafos previos. Para aplicar el parche obtenido en el caso de LVM deberíamos ejecutar los siguientes comandos: usuario@cliente:/tmp$ cd /usr/src/linux-2.4.19/ usuario@cliente:/usr/src/linux-2.4.19$ cat /tmp/lvm-1.0.6-2.4.20.patch | patch -s -p1 --dry-run usuario@cliente:/usr/src/linux-2.4.19$ cat /tmp/lvm-1.0.6-2.4.20.patch | patch -p1 usuario@cliente:/usr/src/linux-2.4.19$ Sólo un par de apuntes: aunque ahora la versión de las fuentes ya es 2.4.20 el nombre del directorio donde se encuentran sigue siendo como al principio. Si queremos ser coherentes deberíamos cambiar el nombre para reflejar la nueva versión, aunque no es necesario. Segundo, que como en el parche anterior primero comprobamos que aplica limpiamente, y sólo si es así aplicamos el parche. Puesto que los parches están creados con respecto a una versión estándar concreta (no parcheada) de las fuentes del núcleo, si parcheamos un núcleo ya parcheado (aunque los parches proporcionen características diferentes) es posible que obtengamos FAILED durante el proceso, lo que indicará que el parche no aplicó completamente. Un último cambio que puede llevar a cabo antes de configurar las fuentes del núcleo consiste en cambiar el identificador de versión para así diferenciar los archivos de este núcleo compilado de los de otros núcleos ya instalados de la misma versión. Si edita el archivo /usr/src/linux/Makefile y modifica la línea que comienza por EXTRAVERSION, por ejemplo dejándola con el contenido EXTRAVERSION = -compilado, el núcleo compilado tendrá como versión la cadena 2.4.20-compilado y los módulos se instalán en directorio aparte, como veremos luego. A continuación deberá configurar las fuentes del núcleo, que consiste en seleccionar todas las opciones que quiere incluir en el núcleo que compilar. Este proceso es el más largo, tedioso y propenso a fallos, sobre todo las primeras veces, y lo peor del caso es que resulta prácticamente imposible evitar estos problemas salvo leyendo la ayuda de todas las opciones de compilación (más de mil) y equivocándose muchas veces. Por suerte una vez que encuentre una configuración que funcione puede guardarla (puesto que está contenida en un archivo de texto) para usarla en futuras compilaciones, incluso de versiones distintas a la actual. Existen tres interfaces de usuario para la configuración de las opciones del núcleo: una en línea de comandos, donde se nos preguntan una por una y de manera secuencial todas las opciones del núcleo, una en consola con menús basados en ncurses y otra gráfica usando Tcl/Tk. Estas tres interfaces de configuración se pueden lanzar con los comandos make config, make menuconfig y make xconfig, respectivamente. La primera de ellas la podemos olvidar, porque al preguntarnos las opciones de manera secuencial sin posibilidad de marcha atrás es tremendamente improductiva y propensa a fallos. La configuración gráfica requiere el intérprete del lenguaje Tcl/Tk, y un servidor X-Window: nos presenta las opciones agrupadas en categorías, y podemos navegar por ellas y seleccionar opciones a nuestra voluntad, usando el ratón. Por último, la opción make menuconfig nos presenta una interfaz de menús en modo texto navegable con las teclas de cursor, que por lo demás es funcionalmente idéntica a la interfaz gráfica, y será la que usemos en este artículo. Para poder ejecutar esta interfaz de menús es necesario tener instalada en la máquina el paquete libncurses-dev, para generar los menús. A continuación puede ver el aspecto de las tres interfaces de configuración mencionadas.
En principio puede moverse libremente por todos los menús y opciones de la interfaz mostrada, aunque la organización de las opciones es tal que lo más lógico es visitarlas en sentido descendente, comenzando por Code maturity level options. Tenga en cuenta que algunas opciones dependen de la presencia o ausencia de otras opciones en lugares distintos de los menús, de manera que es posible que no vea una opción concreta que debería estar ahí simplemente porque ha activado o desactivado otra opción que la oculta. Por ejemplo, si en el primer menú mencionado no selecciona la opción de mostrar las opciones en desarrollo o incompletas habrá ciertas otras opciones que no se le mostrarán. A este respecto hay que advertir que aunque cierta opción se muestre como EXPERIMENTAL habitualmente puede seleccionarla sin miedo a problemas, puesto que estamos compilando un núcleo de la serie estable. Lo mismo se puede decir de las opciones marcadas como NEW, pero no de las marcadas como DANGEROUS, cuyo uso puede causar graves problemas de funcionamiento, especialmente la pérdida de datos en sus discos duros. En cualquier caso lo mejor siempre es leer la ayuda asociada a cada opción, y la documentación de referencia que allí se indique. Además en la ayuda de la mayoría de las opciones, al final de la misma, indica la respuesta que debería dar a la pregunta en caso de que no haya entendido nada. La mayor parte de las veces responder así es lo correcto, y habitualmente lo peor que puede pasar es que deje de incluir alguna opción que sí necesitaba. Por lo demás la operativa para seleccionar las opciones de configuración no necesita de muchas explicaciones, aunque es recomendable hacer un par de indicaciones. Primero, que las opciones pueden aparecer en tres formas de selección: como listas, opciones binarias sí-no, u opciones ternarias sí-no-mó. Cuando accede a una opción de tipo lista (por ejemplo (lista)) se desplegará una nueva ventana donde seleccionar el valor concreto para la opción. Las opciones binarias son de la forma [ ], y de estar activada ([*]) la opción correspondiente se compilará dentro del núcleo de Linux. Las opciones ternarias son de la forma < >, y pueden estar desactivadas, activadas para compilar en el núcleo (<*>) o compiladas para compilar como módulo (<M>). El soporte para las opciones marcadas para compilar en forma de módulo podrá entonces cargarse en memoria automáticamente cuando dicho soporte sea necesario, sin ocupar espacio en memoria mientras tanto (aparte de otras ventajas, como el paso de opciones nuevas a los módulos sin necesidad de reiniciar). Segundo, tenga mucho cuidado en guardar los cambios realizados en la configuración del núcleo al salir, puesto que de lo contrario todo su esfuerzo habrá sido en vano. Cuando seleccione Exit se le preguntará Do you wish to save your new kernel configuration?. Responda No sólo si efectuó cambios que no quiere guardar en el archivo de configuración. Cuando salga de la interfaz de configuración guardando los cambios se generará un archivo de texto con las opciones de configuración seleccionadas, en concreto el archivo /usr/src/linux/.config. Guarde dicho archivo en lugar seguro, porque le servirá para compilar esta y otras versiones del núcleo con las opciones seleccionadas, que tantas horas de leer le puede haber supuesto. De hecho, si alguna vez instala las fuentes de una versión posterior del núcleo para configurarlas igual que el actual bastará copiar este archivo a /usr/src/linux/.config y ejecutar el comando make oldconfig, y responder únicamente a las opciones que no estaban presentes en la versión antigua. El siguiente paso consiste en generar las dependencias para el proceso de compilación, de hecho al salir de la interfaz de configuración ya nos suele indicar cuál es el siguiente paso que debemos dar. Debemos ejecutar el comando make dep, que descenderá por todo el árbol de fuentes generando las dependencias mutuas entre los archivos, en función de las opciones seleccionadas, almacenadas en el archivo /usr/src/linux/.config. Este proceso debería ser razonablemente rápido, aunque depende mucho de la velocidad del disco y de la CPU: en cualquier caso verá por pantalla lo que está sucediendo, y comprobará que el proceso sigue adelante, y no se ha parado. En este punto las fuentes del núcleo ya están preparadas para ser compiladas incluyendo las opciones seleccionadas previamente. Para iniciar el proceso de compilación del núcleo ejecute el comando siguiente. El proceso podrá tardar desde un par de minutos en máquinas con CPU muy potentes y núcleos con pocas opciones, a varias horas en equipos menos rápidos con núcleos llenos de opciones. usuario@cliente/usr/src/linux-2.4.20$ make bzImage ...varios minutos u horas después.... Root device is (3, 2) Boot sector 512 bytes. Setup is 2522 bytes. System is 1032 kB warning: kernel is too big for standalone boot from floppy make[1]: Leaving directory `/usr/src/linux-2.4.20/arch/i386/boot' Varias cosas interesantes: se nos dice que el sistema de ficheros raíz que el núcleo montará durante el arranque corresponde con el dispositivo (major, minor) = (3, 2), que se corresonde con el dispositivo /dev/hda2. También se nos informa que la imagen del núcleo recién compilado tiene un tamaño de 1032 KiB, y que por lo tanto no "cabe" en un disquete (en realidad sí que cabe). Esta imagen del núcleo (el núcleo propiamente dicho), se encuentra en el directorio /usr/src/linux-2.4.19/arch/i386/boot como archivo de nombre bzImage. Este es el archivo que deberá referenciar desde su gestor de inicio para arrancar la máquina con esta versión del núcleo. Sin embargo, hay otro archivo que debe guardar llegado a este punto: /usr/src/linux/System.map. No es imprescindible para el funcionamiento de la máquina, pero la información que muestran utilidades como ps o top será más correcta, y en el improbable caso de que el núcleo falle el mensaje de error que se muestre y guarde en los log podrá ayudar a diagnosticar la causa del mismo. Antes de continuar vamos a copiar estos dos archivos a sus localizaciones habituales, que suele ser el directorio /boot. El nombre del archivo del núcleo puede ser cualquiera, pero el del archivo System.map deberá incluir la versión del núcleo, para distinguirlo de los System.map para otras versiones de núcleo compiladas. Consulte ps(1) para más información sobre los posibles nombres del archivo, aunque citamos aquí la página del manual por si no dispone de ella:
To produce the WCHAN field, ps needs to read the System.map file
created when the kernel is compiled. The search path is:
$PS_SYSTEM_MAP /boot/System.map-`uname -r` /boot/System.map
/lib/modules/`uname -r`/System.map /usr/src/linux/System.map
cliente:/usr/src/linux-2.4.20# cp System.map /boot/System.map-2.4.20 cliente:/usr/src/linux-2.4.20# cp arch/i386/boot/bzImage /boot/nucleo-2.4.20-20030209 cliente:/usr/src/linux-2.4.20# Dejaremos para más tarde la configuración del gestor de arranque para poder seleccionar este nuevo núcleo durante el inicio de la máquina. Ahora pasaremos a compilar los módulos del núcleo, en caso de haber activado el soporte de módulos cargables en la configuración, lo que recomendamos encarecidamente. Después de compilar los módulos habrá que instalarlos en la localización predeterminada, cosa que deberemos hacer como root por los permisos del directorio destino de los mismos.
usuario@cliente/usr/src/linux-2.4.20$ make modules
...
usuario@cliente/usr/src/linux-2.4.20$ sudo make modules_install
Password:
...
cd /lib/modules/2.4.20-compilado; \
mkdir -p pcmcia; \
find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{} pcmcia
if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.4.20-compilado; fi
usuario@cliente/usr/src/linux-2.4.20$
Con la primera instrucción (make modules) compilamos los módulos definidos en la configuración del núcleo. Puesto que los módulos se instalarán bajo un directorio con el nombre de la versión del núcleo bajo el directorio /lib/modules, debemos tener permisos de escritura sobre dicho directorio. De ahí que usemos sudo para ejecutar como root la instalación de los módulos mediante el comando make modules_install. Mediante sudo ejecutamos el comando especificado como otro usuario distinto, en este caso root, porque necesitamos permisos de escritura sobre el directorio /lib/modules/2.4.20-compilado. Bajo ese directorio quedarán copiados todos los archivos con los módulos del núcleo recién compilado, junto con algunos archivos adicionales, como por ejemplo /lib/modules/2.4.20-compilado/modules.dep. Este archivo en concreto contiene las dependencias mutuas entre los módulos, para cargar las dependencias cuando intentemos cargar un módulo que necesite de la presencia previa de otros. De hecho, si después de instalar los módulos añade más provenientes de otras fuentes, por ejemplo un driver, y copia el módulo bajo un subdirectorio de /lib/modules/2.4.20-compilado/kernel deberá ejecutar el comando depmod -ae para regenerar la información de dependencias y comprobar si todos los módulos están bien compilados. Llegados a este punto sólo falta configurar su gestor de inicio para poder elegir durante el arranque de la máquina la versión del núcleo con la que iniciar. Veremos la configuración habitual para los dos gestores de inicio más extendidos, LILO y GRUB. En ambos casos debemos mantener la posibilidad de iniciar la máquina con el núcleo en ejecución, por si acaso el nuevo no funciona, de manera que podamos reiniciar sin problemas para corregir el fallo, recompilar y probar de nuevo. El archivo de configuración de LILO es /etc/lilo.conf. Para eñadir el nuevo núcleo a los ya existentes en su configuración debemos editar el archivo (como root) y añdir un bloque de directivas como el siguiente a continuación del útimo que ya haya:
image=/boot/nucleo-2.4.20-20030209
label=compilado
read-only
Simplemente indicamos la localización del núcleo compilado, y le damos un nombre, que será el que se muestre durante el inicio en el menú de LILO. Para que los cambios sean efectivos es necesario ejecutar (como root) el comando lilo: cliente:/tmp# lilo -v LILO version 22.3.3, Copyright (C) 1992-1998 Werner Almesberger Development beyond version 21 Copyright (C) 1999-2002 John Coffman Released 30-Aug-2002 and compiled at 15:38:21 on Sep 1 2002. Reading boot sector from /dev/hda2 Using MENU secondary loader Calling map_insert_data Boot image: /vmlinuz -> boot/vmlinuz-2.4.17-k7 Added Linux * Boot image: /boot/nucleo-2.4.20-20030209 Added compilado /boot/boot.0302 exists - no backup copy made. Writing boot sector. cliente:/tmp# Hemos ejecutado el comando en modo verboso para ver lo que está haciendo en cada momento. Vemos que se está escribiendo el sector de arranque de la segunda partición primaria del primer disco duro IDE del sistema (/dev/hda2). Se ha añadido un núcleo de etiqueta Linux, que será el que inicie de manera predeterminada (vea el asterisco), y otro de nombre compilado, que es el recién compilado. Si la salida indicase algún tipo de error corríjalo y repita el comando, o puede tener problemas para iniciar el sistema operativo. La configuración de GRUB es similar, e incluso más sencilla, porque basta modificar el archivo de configuración, típicamente /boot/grub/menu.lst, y no es necesario ejecutar comando alguno para hacer efectivos los cambios. Para añadir el nuevo núcleo a la lista de los ya disponibles añada un bloque de directivas como el siguiente al final del archivo: # Nucleo 2.4.20 compilado por nosotros title Mi primer nucleo compilado (2.4.20) kernel /boot/nucleo-2.4.20-20030209 root (hd0,1) La primera línea es un simple comentario, que podemos ignorar. La segunda indica el texto que aparecerá en el menú de GRUB durante el arranque, la tercera indica dónde encontrar el archivo con el núcleo que ejecutar, y la última indica que el sistema de ficheros raíz es /dev/hda2. Como ya hemos dicho antes los cambios ya surtirán efecto la próxima vez que reiniciemos. Si reiniciamos la máquina y seleccionamos el nuevo núcleo (que no hemos puesto como predeterminado) con un poco de suerte iniciará correctamente. Si no lo hace lo más probable es obtener un mensaje del tipo Unable to mount root, que nos indica que el núcleo no ha sido capaz de montar el sistema de ficheros raíz, bien porque lo ha buscado donde no es, o porque lo busca en el sitio correcto pero no es capaz de montarlo. La razón más típica por la cual el núcleo no sea capaz de montar el raíz yendo a buscarlo al lugar correcto es no haber compilado en el núcleo (no como módulo) el soporte necesario para acceder al disco y al sistema de ficheros donde reside el raíz. Por ejemplo, si su raíz reside en un sistema de ficheros ext2 sobre una partición de un disco IDE, es imprescindible compilar en el núcleo el soporte de ambas cosas, así como soporte para consola virtual, y alguna otra cosa que puede descubra a fuerza de prueba y error. Ya para finalizar, resumimos en una lista todos y cada uno de los pasos dados para compilar un núcleo personalizado en Linux, y que hemos detallado a lo largo de este artículo.
Última modificación: 12-March-2003 14:29:24 -0500 |
© 2002-2007 José Luis Domingo López. Todos los
derechos reservados.
Contacte con el webmaster
para informarle de fallos, incorrecciones o sugerencias.
Esta página cumple con los estándares HTML 4.01 y CSS2 del
World Wide Web Consortium.