Construyendo un kernel particularizado
Mucha gente nueva en Linux se pregunta con frecuencia "¿ Por qué debo construir mi propio Kernel?". Debido a los avances que se han desarrollado para los usos de los modos del Kernel, la respuesta más precisa a esa pregunta es, "al menos que tu conozcas porque necesitas contruir tu propio kernet, probablemente no debas hacerlo.". Por lo que al menos que tengas una razón para construir un kernel personalizado (o tengas esa curiosidad), puedes saltar este paso y continuar en la la sección de nombre Sendmail.
En el pasado, era necesario recompilar el kernel si se añadía nuevo hardware al sistema. El kernel era, en otras palabras, estático. Mejoras en los kernels Linux 2.0.x permiten que muchos de los drivers para hardware puedan ser modularizados en componentes que pueden ser insertados bajo demanda. Sin embargo, hubo grandes problemas al tener varios kernels en el sistema compilados para diferentes mejoras (un buen caso es el SMP ver sus monoprocesador). Nuevas mejoras con la modularización de la versión 2.2.x del kernel de Linux han permitido la coexistencia de múltiples kernels (aunque sin compartir módulos).
Para más información sobre como gestionar módulos del kernel véase la sección de nombre Cargando módulos del Kernel en Capítulo 3. La mayor parte de los cambios permanecen ocultos excepto cuando se recompila un kernel particularizado para un sistemas.
Construyendo un kernel particularizado
Estas instrucciones permiten tomar ventaja de la potencia y la flexibilidad disponibles con la modularización del kernel. Si no se quiere aproveechar la modularización, véase por favor la sección de nombre Construcción un kernel monolítico para una explicación de los diferentes aspectos al construir e instalar un kernel monolítico. Se asume que se ha instalado el paquete kernel-headers y el paquete kernel-source y que todos los comando se ejecutan desde el directorio /usr/src/linux.
Lo más importante es asegurarse de que se tiene un disquete de arranque de emergencia que funcione en caso de que se cometa un error. Si no se creó un disco de arranque durante la instalación, úsese el comando mkbootdisk para hacer uno. El comando estándar es similar a mkbootdisk --device /dev/fd0 2.2.x. Una vez hecho, comprobar el disco de arranque para asegurar que arrancará el sistema.
Es importante empezar la construcción del kernel con el árbol de fuentes en un estado conocido. Por lo tanto, se recomienda que se empiece con el comando make mrproper. Esto eliminará todos los ficheros de configuración junto con los restos de cualquier construcción previa que puedan estar desperdigados por el árbol de fuentes. Ahora hay que crear un fichero de configuración que determinará que componentes se incluirán en el nuevo kernel. Se enumeran los métodos de configuración del kernel más abajo:
make config — Programa de texto interactivo. Los componentes se presentan y se responde con Y (si), N (no), o M (módulo).
make menuconfig — Un programa gráfico a base de menús. Los componentes se agrupan por categorías, se seleccionan los componentes deseados en la misma manera que en el programa de instalación de Red Hat Linux. Se cambia la etiqueta que corresponda al elemento que se quiera incluir; Y (si), N (no), o M (módulo).
make xconfig — Programa para X Windows. Los componentes aparecen listados en diferentes niveles de menús, y se seleccionan usando el ratón. Una vez más, seleccionar Y (si), N (no), or M (módulo).
make oldconfig — Es un script no interactivo script que pondrá el Makefile con los valores por defecto. Si se usa el kernel parcheado de Red Hat, se pondrá la configuración que venía para el sistema. Esto es útil para poner el kernel a unos valores por defecto que funcionan y poder luego desactivar lo que no quiere.
 | Nota |
|---|---|
Para poder usar kmod (véase la sección de nombre Cargando módulos del Kernel en Capítulo 3 para más detalles) y módulos del kernel debe responderse Yes a kmod support y module version (CONFIG_MODVERSIONS) support al configurar. |
Si se quiere construir un kernel con un fichero de configuración (/usr/src/linux/.config -- este fichero es creado una vez por alguno de los métodos arriba citados una vez ejecutados) que ya ha sido creado con alguno de los métodos arriba citado, se pueden omitir los comandos make mrproper u make config y usar el comando make dep seguido de make clean para preparar el árbol de fuentes para construir.
El siguiente paso para hacer un kernel modularizado es simplemente editar /usr/src/linux/Makefile y compilar los componentes del código fuente en un programa ejecutable que el ordenador pueda utilizar para arrancar. El método aquí descrito es el más sencillo para recuperarse de un posible error. Si se está interesado en otras posibilidades, se pueden encontrar detalles en el Kernel-HOWTO o en el Makefile en /usr/src/linux en el sistema Linux.
Editar el Makefile y cambiar la línea: EXTRAVERSION = para que tenga un nombre único (como añadir iniciales al final del texto, como por ejemplo EXTRAVERSION = -2.5.0sjs). Esto permite mantener las versiones nueva y vieja al mismo tiempo en el sistema.
Construir el kernel con make bzImage.
Construir los módulos que se hayan configurado con make modules.
Instalar los nuevos módulos (incluso si no se construyó ninguno) con make modules_install. Esto instalará los módulos en en el directorio /lib/modules/ utilizando después de "modules" el nombre especificado en el Makefile. Para el ejemplo sería /lib/modules/2.2.15-2.5.0sjs/.
Si se tiene un adapatador SCSI y se hizo el controlador SCSI un módulo, habrá que construir una nueva imagen de disco ram initrd (véase la sección de nombre Creando una imagen initrd; nótese que hay pocas razones prácticas para hacer el controlador SCSI modular en un kernel particularizado). A menos que se tengan razones específicas para crear una imagen initrd, no crearla y no añadirla a lilo.conf.
Para tener una fuente redundante de arranque protegerse de un posible error en el nuevo kernel, debería manteenerse el kernel original disponible. Añadir un nuevo krenel al menú de LILO es tan simple como renombrar el kernel original en /boot, copiar el nuevo kernel a /boot, añandiendo unas pocas líneas a /etc/lilo.conf y ejecutando /sbin/lilo. Aquí hay un simple ejemplo del fichero /etc/lilo.conf que se instala con Red Hat Linux por defecto:
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
message=/boot/message
linear
default=linux
image=/boot/vmlinuz-2.2.16-12
label=linux
initrd=/boot/initrd-2.2.16-12.img
read-only
root=/dev/hda8
other=/dev/hda1
label=dos |
Ahora hay que actualizar /etc/lilo.conf. Si se construyó una nueva imagen initrd hay que decirle a LILO que la use. En este ejemplo de /etc/lilo.conf se han añadido cuatro líneas en medio del fichero para indicar otro kernel del que arrancar. Se ha renombrado /boot/vmlinuz a /boot/vmlinuz.old y cambiado su etiqueta a old. También se ha añadido una nueva línea initrd para el nuevo kernel:
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
message=/boot/message
linear
default=linux
image=/boot/vmlinuz-2.2.16-12
label=linux
initrd=/boot/initrd-2.2.16-12.img
read-only
root=/dev/hda8
image=/boot/vmlinuz-2.2.16-12.sjs
label=test
initrd=/boot/initrd-2.2.16-12sjs.img
read-only
root=/dev/hda8
other=/dev/hda1
label=dos
|
Ahora cuando el sistema arranca y se pulsa Tab en la línea de comandos de LILO boot:, las opciones disponibles se mostrarán;
LILO boot:
linux test dos
|
Para arrancar el kernel viejo (linux) basta con presionar Enter, o esperar a que se acabe el tiempo de espera. Si que quiere arrancar con el nuevo (test), teclear test y pulsar Enter.
Un resumen de los paso seguidos:
Copiar el kernel compilado al directorio /boot utilizando el nombre que salió de cambios anteriores al Makefile. Aquí hay un ejemplo:
cp -p /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-2.2.15-2.5.0sjs /usr/src/linux/System.map /boot/System.map-2.2.15-2.5.0sjs
Editar /etc/lilo.conf.
Crear un nuevo disco ram de inicio, imagen initrd (véase la sección de nombre Creando una imagen initrd) si es necesario.
Ejecutar /sbin/lilo. Se puede añadir la opción -v a lilo para obtener informaci& oacute;n más detallada si se cree que hay algún problema.
Se puede empezar a probar el nuevo kernel rearrancando el ordenador y observando los mensajes para asegurar que el hardware es detectado apropiadamente.
Creando una imagen initrd
Una imagen initrd es necesaria para cargar un módulo SCSI en el momento del arranque. Si no se necesita una imagen initrd, mejor que no se haga y no se edite lilo.conf para incluir dicha imagen.
El script /sbin/mkinitrd puede construir una imagen initrd apropiada para el ordenador si se dan las siguientes condiciones:
El dispositibo de bloque de loopback está disponible.
El fichero /etc/conf.modules tiene una línea para el adaptador SCSI; por ejemplo:
alias scsi_hostadapter BusLogic
Para construir la nueva imagen initrd, hay que ejecutar /sbin/mkinitrd con parametros tales como:
/sbin/mkinitrd /boot/newinitrd-image 2.2.15-2.5.0sjs |
Donde /boot/newinitrd-image es el fichero que se usará para la nueva imagen, y 2.2.15 es el kernel cuyos módulos (de /lib/modules) deberían ser usados en la imagen initrd (no necesariamente la misma versión de kernel que se encuentra en ejecución).
Construcción un kernel monolítico
Para construir un kernel monolítico hay que seguir los mismos pasos que para construir un kernel modularizado con unas pocas excepciones.
Al configurar el kernel sólo responder Yes y No a las preguntas (no hacer nada modular). Además, debería responderse No a kmod support y module version (CONFIG_MODVERSIONS) support al configurar.
Omitir los pasos:
make modules make modules_installEditar lilo.conf y añadir la línea append=nomodules.