PDF de programación - Técnicas para actualización y personalización del kernel

Trabajando con el Kernel • PORTADA

Técnicas para actualización y personalización del kernel

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

Cualquier 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 los correspon-

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

r
o
b
e
r
t

f
o
r
i
,


F
o
t
o

l
i

a

W W W . L I N U X - M A G A Z I N E . E S

Número 49

19

PORTADA • Trabajando con el 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-eeepc U
(knopper@Koffer) U
(gcc version 4.3.2 U
(Debian 4.3.2-1) U
) #13
PREEMPT Thu Oct 9 U
04:04:42 CEST 2008

Figura 1: Usamos make gconfig para compilar el ker-

nel en un entorno basado en Gtk.

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 abrimos 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 9 U
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.

Opciones del Kernel

El kernel tiene cierta capacidad de

interactividad – 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.

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
instrucciones
i686, que soporta
máquina de Pentium 2 y superiores, pero
no las de las máquinas basadas en 386 y
486.

las

• 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-

20

Número 49

W W W . L I N U X - M A G A Z I N E . E S

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
linux-image-686

U

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 ramdisk inicial;
de serlo, se instalan los módulos necesarios
en un archivo llamado /boot/initrd.img-
numerodeversion-arquitectura. La herra-
mienta del sistema mkinitramfs es 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:

Listado 1: /etc/lilo.conf

01 image=/vmlinuz

02

03

initrd=/initrd.img

label=Linux

04 image=/vmlinuz.old

05

06

initrd=/initrd.img.old

label=Linux -old

PORTADA • Trabajando con el Kernel

• ¿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.conf algo 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.old e /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.conf manualmente, debemos ejecutar el
comando lilo antes 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 arran