KERNEL

Transcripción

KERNEL

Facultad de Cs. Exactas y Tecnología
Depto. de Electricidad, Electrónica y Computación
Ing. en Computación
Curso: Administración Avanzada de Linux
KERNEL
2.1 LINUX ES UN KERNEL
El kernel es la parte central, el corazón de un sistema operativo, que se carga primero y permanece
en memoria principal todo el tiempo, administrando el uso del hardware. Mínimamente, el kernel es
responsable de administrar la memoria principal, los procesos (scheduling) y la comunicación entre
ellos (IPC).
Linux es, precisamente, un kernel. Es capaz de cargar módulos en tiempo de ejecución, permitiendo
así extender su funcionalidad a discreción, y por otra parte, manteniendo la cantidad de código
ejecutándose en el “espacio del kernel” (en memoria primaria) en el mínimo posible.
En el kernel de Linux deben estar incluidos los controladores (drivers) de los dispositivos que vayan
a utilizarse. Por ejemplo, si se desea instalar un dispositivo SCSI en el sistema, el kernel debe
soportarlo (esto es, tener la opción de “entenderse” con el dispositivo), y tener incorporados los
drivers correspondientes estáticamente, o cargarlos dinámicamente (desde un módulo). De no ser
así, habrá que crear un kernel que tenga los drivers necesarios.
Lo mismo sucede con todas y cada una de las características atribuibles a Linux, como ser NAT,
filtrado de paquetes con iptables o ipchains, sistemas de archivo (NTFS, ext2, ext3), lenguajes
soportados, etc.
2.2 CUANDO ES NECESARIO COMPILAR UN KERNEL
En general, configurar, compilar e instalar un nuevo kernel es una tarea que requiere mucho cuidado,
puesto que un error en la configuración o en el proceso de instalación puede llevar a la pérdida del
acceso a la máquina.
Consideremos por ejemplo, una máquina que se encuentra en algún lugar remoto del planeta, a la
que accedemos gracias a que esta se conecta a Internet de manera automática usando PPPoE. Si
recompilamos un nuevo kernel y no incluimos el soporte para PPPoE, la máquina no podrá
conectarse a Internet, y de no contar con un mecanismo remoto alternativo para acceder a ella,
alguien tendrá que ir en persona a solucionar ese problema. Por eso es bueno siempre preguntarse
antes de instalar un nuevo kernel si realmente hace falta.
Es necesario compilar un nuevo kernel ante los siguientes casos:
Módulo II: Kernel
1
a. Es preciso aplicar actualizaciones de seguridad y bugfixes en el código del kernel.
b. Se necesitan actualizaciones de drivers existentes.
c. Se necesitan nuevas funcionalidades y drivers. Por ejemplo, ciertas aplicaciones sólo
funcionan con kernels superiores a cierta versión, no se encuentran drivers para Serial ATA
en kernels 2.2.x, etc.
d. Se requiere cierta característica al inicio del sistema que antes no era necesaria (ej., se migra
el sistema de archivo del dispositivo raíz de reiserfs a ext3) y no se desea hacer un Disco
RAM inicial (initial RAMdisk).
e. Se desea reducir el tamaño del kernel sacando todo el código que pueda ser cargado como
módulo. Esto es muchas veces necesario para hacer entrar el kernel en un disquete y hacer
así un disco de arranque.
Del listado anterior, los casos a, b y c suponen la instalación de una nueva versión del kernel. Si no
es necesaria una nueva versión de Linux, el caso d enuncia probablemente la única situación en la
cual es obligatorio compilar un nuevo kernel. Esto sucede más que nada cuando se hacen cambios
relativos al sistema de archivos raíz, puesto que en la secuencia de arranque, primero debe ser
montada la raíz para que luego puedan ser accedidos los módulos del kernel.
Un recurso disponible para evitar la compilación de un nuevo kernel en estos casos es utilizar un
disco RAM inicial (initial RAMdisk). Este es una imagen de un disco, que contiene un sistema de
archivos raíz que se carga en memoria al iniciar el sistema, y en él se incluyen los módulos necesarios
para montar posteriormente la raíz real del sistema (ej.: SCSI, LVM, ext3). El manejo del disco
RAM inicial está asignado al cargador de arranque (bootloader), por ende es preciso indicarle a este
su existencia y ubicación en su archivo de configuración. Luego de su utilización, al montar la raíz
real del sistema, la memoria es liberada para su posterior utilización.
Finalmente, en los casos restantes no es necesario compilar un nuevo kernel. Por ejemplo, para
agregar NAT o el driver de cierto adaptador SCSI que ya esté incluido en el código fuente de Linux
(de la misma versión en ejecución) basta con compilar e instalar un módulo, y ni siquiera hace falta
reiniciar el equipo para comenzar a utilizar la nueva funcionalidad. Esta es una práctica que posee
varias ventajas (menor tiempo de compilación, menor riesgo de perder el control del sistema y otras
que serán evidentes cuando veamos los módulos con mayor detalle) y debe utilizarse siempre que
sea posible.
Módulo II: Kernel
2
2.3 REQUISITOS
Para compilar un kernel reciente (versión 2.4.x o 2.6.x) se necesitan aproximadamente 300 MB de
espacio en disco. Es un proceso que requiere gran capacidad de procesamiento, por lo que puede
tardar horas en máquinas de pocos recursos.
Además, es preciso tener el compilador de C (gcc) y las librerías (libc) de versiones indicadas en el
archivo README que está junto con el código fuente del kernel.
2.4 OBTENCIÓN DEL KERNEL
SuSE presenta un método sencillo para actualizar el kernel de la distribución, mediante YOU (YaST
Online Updater) o los CDs de actualización. Una vez realizada la instalación, el próximo reinicio
cargará el nuevo kernel. Estos kernels vienen optimizados para la familia de procesadores utilizados
por el equipo (Athlon, P4, PIII, etc.) y con la más amplia gama de drivers posibles, compilados
como módulos. Además, corrigen errores de versiones previas y fallas de seguridad.
No hace falta compilar estos kernels, aunque en caso de estar instalado el código fuente del kernel,
también se bajará e instalará el código fuente del nuevo kernel, sin borrar el anterior, en /usr/src/:
srvlinux:/usr/src # dir
total 804
drwxr-xr-x
12 root
root
drwxr-xr-x
12 root
root
lrwxrwxrwx
1 root
root
drwxr-xr-x
18 root
root
drwxr-xr-x
8 root
root
drwxr-xr-x
18 root
root
drwxrwxr-x
22 root
root
lrwxrwxrwx
1 root
root
2.4.21-260-include
drwxr-xr-x
7 root
root
4096 Dec 2
4096 Jan 13
16 Dec 1
4096 Dec 2
4096 Dec 1
4096 Dec 1
4096 Nov 28
24 Dec
4096 Jan 13
08:35 .
2003 ..
13:27 linux -> linux-2.4.21-260
08:25 linux-2.4.21-260
13:27 linux-2.4.21-260-include
13:30 linux-2.4.21-99
04:54 linux-2.6.9
1 13:28 linux-include -> linux2003 packages
Podemos ver en este listado de directorio 3 versiones de kernel. La 2.4.21-99 es la que viene con
SuSE 9.0, una actualización online hecha en Diciembre de 2004 instaló la 2.4.21-260, y finalmente
una versión que no viene con el sistema original de SuSE, la 2.6.9.
El vínculo simbólico “linux” es apuntado directamente a la versión actualizada del kernel de manera
automática. Este vínculo sirve para que ciertos programas que necesitan para su compilación el
código fuente del kernel (iptables, por ejemplo) puedan encontrar la versión adecuada.
Saliendo ya del kernel distribuido y respaldado por SuSE, tanto la última versión del código fuente
del kernel de Linux como las anteriores, se pueden encontrar en www.kernel.org (The Linux Kernel
Archives, LKA) y sus sitios espejos.
Módulo II: Kernel
3
Los archivos con el código fuente vienen “empaquetados” en formato tar, y comprimidos en ambos
formatos gzip y bzip2. Por lo tanto, encontraremos en este sitio archivos tales como linux2.6.7.tar.bz2 y linux-2.6.7.tar.gz, que son el mismo código fuente comprimido con bzip2 y gzip
respectivamente.
2.4.1 Verificación de autenticidad
Es indispensable para la seguridad del sistema verificar la autenticidad del kernel que vamos a
instalar. Un kernel adulterado implica un riesgo de seguridad muy alto.
Los archivos puestos en www.kernel.org son automáticamente firmados con OpenPGP. Esta firma
puede ser usada para probar que el archivo, que puede haber sido obtenido desde uno de los sitios
espejos u otra ubicación, realmente es copia del archivo publicado por LKA.
La llave pública OpenPGP de LKA siempre estará en http://www.kernel.org/signature.html, junto
con cualquier certificado de revocación pertinente.
Esta firma, sin embargo, no garantiza que el sitio maestro de LKA no haya sido comprometido. De
todos modos, en caso de sufrir alguna intrusión, la clave pública será revocada e se publicará
información tan rápido como sea posible en la página mencionada.
Se recomienda no usar versiones de GnuPG anteriores a 1.0.6, dado que se recibieron reportes de
que estas versiones dieron por válida una firma incorrecta.
SuSE instala por defecto GnuPG, y el procedimiento para verificar una firma del kernel es el
siguiente:
1. Importar la clave pública de LKA:
gpg --keyserver wwwkeys.pgp.net --recv-keys 0x517D0F0E
2. Verificar:
gpg --verify linux-2.6.9.tar.gz.sign linux-2.6.9.tar.gz
En caso de que la firma sea buena, se presentará el siguiente mensaje:
gpg: Signature made Mon Oct 18 19:19:21 2004 GMT+3 using DSA key ID
517D0F0E
gpg:
Good
signature
from
"Linux
Kernel
Archives
Verification
Key
<[email protected]>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:
There is no indication that the signature belongs to the
owner.
Módulo II: Kernel
4
Se lee Good signature from “Linux Kernel Archives Verification Key [email protected]”,
lo que confirma la autenticidad. La advertencia (“WARNING:…”) indica que si bien tenemos la
clave pública, no hay certificación de que la clave pertenezca a LKA. Para tener esa certeza, habría
que hacer un camino de confianza (“trusted path”) hasta el que firmó la clave pública de LKA, lo
que queda a criterio de cada administrador.
2.5 CONFIGURACIÓN
Se procede a descomprimir y desempacar el código fuente (que está en formato .tar.gz o .tar.bz2),
preferentemente en /usr/src, con lo que se crea un subdirectorio con la versión del kernel, por
ejemplo, linux-2.6.9.
El paso siguiente es configurar el kernel. Para ello se puede usar make config (no recomendado,
porque pregunta secuencialmente por cada una de las características posibles), make menuconfig
(bastante amigable, recomendado, puesto que utiliza un sistema de menús en la consola) o make
xconfig (desde entorno X). Nos basaremos en menuconfig de aquí en más.
Ahí se presentarán todas las opciones con las que se puede armar un kernel, junto con ayuda (en
inglés) de la mayoría de ellas.
Estas opciones presentarán una casilla de verificación representada por corchetes [ ], y las que
vayan a ser incluidas llevarán un asterisco en la casilla [*]; en los casos en los que la opción pueda
ser compilada como módulo, la tendrá este formato: < > que podrá estar vacío, llevar un asterisco o
una M cuando se seleccione la opción de módulo.
Para alternar entre las opciones se puede usar la barra espaciadora, o directamente Y (para incluir la
opción estáticamente en el kernel), N (para deshabilitar la opción) y M (para incluirla como
módulo). Presionando el signo de cierre de interrogación (“?”) se presenta la ayuda correspondiente
al ítem resaltado.
Esta interfaz crea un archivo que contiene todas las opciones elegidas, y permite guardarlo con un
nombre diferente al predeterminado (que es “.config”), en la opcion “Save Configuration to an
Alternate File”. También permite cargar un archivo distinto al predeterminado, mediante “Load an
Alternate Configuration File”.
Al salir nos pregunta si deben guardarse los cambios y se genera este archivo, que nos permitirá
realizar la compilación.
Si se desea configurar un kernel exactamente como el que se está ejecutando, se puede utilizar make
cloneconfig, que obtiene la configuración de /proc/config.gz y la pone en el archivo .config. Esta
es una característica de SuSE, no necesariamente presente en otras distribuciones ni en el kernel de
LKA. Para ver esa configuración, se puede ejecutar zcat /proc/config.gz | less, ya no sólo
en SuSE sino en cualquier kernel que soporte /proc/config.gz.
Módulo II: Kernel
5
2.5.1 Módulos
Son partes del código del kernel que pueden ser cargados y descargados de la memoria en función
de la necesidad. Por ejemplo, un tipo de módulo son los drivers de dispositivo, que permiten al
kernel acceder al hardware conectado al sistema.
Como se dijo anteriormente, los módulos tienen la ventaja de extender la funcionalidad del kernel sin
que esto implique tener un kernel gigante, y sobre todo, sin necesidad de recompilar el kernel y
reiniciar la máquina cada vez que se quiera agregar un driver por ejemplo.
Los módulos pueden compilarse separadamente del resto del kernel, y ser cargados dinámicamente,
siempre y cuando la opción correspondiente (automatic kernel module loading, activa por
defecto) esté compilada en el kernel.
La tendencia actual es compilar como módulos todo lo que no sea indispensable para el arranque.
Consideremos tener por ejemplo una partición root de tipo ext3, y un CDROM atapi. No es
recomendable configurar el sistema de archivos ext3 como módulo, pues hasta que kmod comience
a ejecutar, no podrá ser cargado; sin embargo, sería bueno que el controlador del CDROM fuera un
módulo.
Sin embargo, hay que considerar el siguiente escenario como un contraejemplo de lo anteriormente
expuesto. SuSE, RedHat, Mandrake, etc. deben preparar sus kernels para hacer arrancar la más
variada gama de configuraciones de hardware. Por lo tanto, las funciones compiladas necesarias
para cubrir todos los casos harían un kernel muy grande, o serían necesarias varias (demasiadas)
versiones de kernels.
Este problema es resuelto creando un kernel genérico mínimo y un initial RAMdisk con todos los
controladores posibles.
2.5.2 Parches
Son fragmentos de código fuente destinados a agregar funciones o reparar errores en un programa.
Sólo se especifican los fragmentos relevantes, que deben ser agregados, eliminados o reemplazados,
por lo que el tamaño de los parches es óptimo.
Se aplican sobre el código fuente, por ejemplo, de la siguiente manera:
srvlinux:/usr/src # cd linux-2.4.21-260
srvlinux:/usr/src/linux-2.4.21-260 # patch -p1 -i ../linux-2.4.21-imq1.diff.ernesto
patching file Documentation/Configure.help
Hunk #1 succeeded at 9520 (offset 699 lines).
patching file drivers/net/Config.in
patching file drivers/net/imq.c
Módulo II: Kernel
6
patching file drivers/net/Makefile
Hunk #1 succeeded at 192 with fuzz 1 (offset 33 lines).
patching file include/linux/imq.h
patching file include/linux/netfilter_ipv4/ipt_IMQ.h
patching file include/linux/skbuff.h
patching file net/core/skbuff.c
Hunk #2 succeeded at 254 (offset 1 line).
patching file net/ipv4/netfilter/Config.in
patching file net/ipv4/netfilter/Makefile
patching file net/ipv4/netfilter/ipt_IMQ.c
patching file net/sched/sch_generic.c
Para más información sobre el comando patch, ver man patch. Un parche puede ser revertido,
esto es, dejar todo como estaba antes, con el parámetro -R:
srvlinux:/usr/src/linux-2.4.21-260 # patch -R -p1 -i ../linux-2.4.21-imq1.diff.ernesto
patching file Documentation/Configure.help
patching file drivers/net/Config.in
patching file drivers/net/imq.c
patching file drivers/net/Makefile
patching file include/linux/imq.h
patching file include/linux/netfilter_ipv4/ipt_IMQ.h
patching file include/linux/skbuff.h
patching file net/core/skbuff.c
Hunk #2 succeeded at 250 (offset 1 line).
patching file net/ipv4/netfilter/Config.in
patching file net/ipv4/netfilter/Makefile
patching file net/ipv4/netfilter/ipt_IMQ.c
patching file net/sched/sch_generic.c
2.5.3 El archivo .config
Módulo II: Kernel
7
Como dijimos anteriormente, este archivo contiene toda la información referida a la configuración de
un kernel. Se lo puede editar normalmente con cualquier editor de texto. Un fragmento de este
archivo podría ser:
#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
# CONFIG_SBUS is not set
CONFIG_UID16=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y
#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# CONFIG_MK8 is not set
# CONFIG_MELAN is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_M586NOCX8 is not set
Más allá de la advertencia, con un poco de cuidado se puede editar el archivo en caso de ser
necesario.
Módulo II: Kernel
8
Podemos observar que es un sistema basado en x86 y que habilita la compilación de características
experimentales. Respecto a los módulos, están habilitados, así como el soporte para “versioning” y
el cargador de módulos automático del kernel, kmod, ambas características que veremos más
adelante.
En la sección de tipo de procesador, vemos que es de la familia K7 (Athlon, Duron) y vemos
muchas opciones comentadas (con un # al comienzo), que están a modo de ayuda. El archivo
.config no necesita de ellas para cumplir su función.
Este archivo es útil para hacer respaldos de un kernel configurado. Para reproducirlo, basta con
tener el código fuente y este archivo.
Cabe remarcar que para obtener la configuración actual de un kernel ejecutándose, si éste soporta
/proc/config.gz, ni siquiera hace falta tener el código fuente, basta con ejecutar zcat
/proc/config.gz > .config.
Si el kernel no soporta /proc/config.gz, puede aún contener el archivo .config dentro de sí mismo.
Para extraerlo, se puede emplear una utilidad que viene con el código fuente de Linux, ubicado en
scripts/extract-ikconfig.
2.6 COMPILACIÓN E INSTALACIÓN
El paso siguiente sería make dep, que genera dependencias necesarias para el resto de la
compilación. Sin embargo, en los kernels más recientes (2.6.x) este paso ya no es necesario.
Luego, make clean bzImage modules modules_install.
Esta única linea realiza el resto, que es limpiar archivos objeto que quedaron de la compilación
anterior, hacer la imagen comprimida del kernel (bzImage), compilar los módulos (modules) e
instalarlos (modules_install). Cada uno de estos pasos puede ser realizado por separado según la
situación y el gusto.
Si se desea crear una imagen del kernel para un disquete, se puede emplear make bzimage, y si el
disco está en la unidad, con make bzdisk no sólo se hará la imagen sino que será grabada en el
disco automáticamente.
Esto último es una buena idea, sobre todo al compilar kernels de prueba, porque si el sistema no
arranca como se espera, simplemente hay que sacar el disquete y reiniciar para que todo quede
como antes.
Adicionalmente, estos discos de arranque pueden ser utilizados cuando no sea posible arrancar
desde el disco duro por alguna falla (no en reemplazo de los discos de rescate, pues éstos tienen
Módulo II: Kernel
9
mucha más funcionalidad, pero podrían ayudar en casos simples) o para replicar sistemas Linux con
sólo copiar los discos rígidos.
2.7 EL ARCHIVO SYSTEM .MAP
Este archivo es una tabla que sirve para relacionar las direcciones de los símbolos (variables y
funciones) utilizadas por el kernel, con sus nombres. Un fragmento de un archivo System.map es el
siguiente:
00476f82
0052a73f
0060e766
00801678
008750fe
00ce9819
00ed1eba
01075bf0
01139ffc
01498f36
014f912d
0184a565
01a4e45c
01b5241f
A
A
A
A
A
A
A
A
A
A
A
A
A
A
__crc_put_filp
__crc_ide_add_proc_entries
__crc_tty_termios_baud_rate
__crc_flush_scheduled_work
__crc___scm_destroy
__crc_make_8023_client
__crc_prepare_binprm
__crc_panic
__crc_max_mapnr
__crc_posix_unblock_lock
__crc_pci_release_regions
__crc_xfrm_alloc_spi
__crc_sb_min_blocksize
__crc_ide_auto_reduce_xfer
Podemos observar que la variable crc_tty_termios_baud_rate está en la dirección 0060e766
del kernel.
El kernel no utiliza nombres de símbolos internamente, y los seres humanos no utilizamos las
direcciones preferentemente. Al compilar, estos nombres son traducidos en las direcciones que el
kernel usa. Sin embargo, a veces es necesario encontrar el nombre para una dirección o viceversa.
Entonces se usa el archivo System.map, que se genera precisamente en la compilación y que refleja
la traducción mencionada. La merecida extensión .map hace referencia a que es un mapa de los
símbolos del kernel.
Por lo tanto, cada vez que un kernel se compila, se genera un nuevo mapa que refleja los símbolos y
las direcciones.
Toda vez que es necesario consultar el mapa, es buscado en la ubicación /boot/System.mapversión. Por ejemplo, veamos un listado del directorio /boot en un sistema con varios kernels
compilados:
srvlinux:/boot # dir
total 8952
drwxr-xr-x
3 root
drwxr-xr-x
24 root
Módulo II: Kernel
root
root
4096 Dec
4096 Dec
1 13:27 .
2 08:40 ..
10
-rw-r--r-lrwxrwxrwx
IMQ
-rw-r--r--rw-r--r--rw-r--r--rw-r--r-lrwxrwxrwx
-rw-r--r--rw-r--r--rw-r--r-drwxr-xr-x
lrwxrwxrwx
-rw-r--r--rw-r--r--rw-r--r-lrwxrwxrwx
athlon
-rw-r--r--
1 root
1 root
root
root
134460 Nov 17 17:54 Kerntypes-2.4.21-260-athlon
24 Jul 3 15:36 System.map -> System.map-2.4.21-99-
1 root
1 root
1 root
1 root
1 root
1 root
1 root
1 root
2 root
1 root
1 root
1 root
1 root
1 root
root
631451 Nov 17 17:58 System.map-2.4.21-260-athlon
root
650151 Jul 3 15:35 System.map-2.4.21-99-IMQ
root
922226 Nov 27 20:46 System.map-2.6.9-Ernesto-18112004
root
512 Jan 13 2003 backup_mbr
root
1 Jan 13 2003 boot -> .
root
1257372 Jul 3 15:35 bzImage-2.4.21-99-IMQ
root
1654917 Nov 27 20:46 bzImage-2.6.9-Ernesto-18112004
root
52392 Nov 17 17:53 config-2.4.21-260-athlon
root
4096 Dec 1 13:40 grub
root
24 Dec 1 13:26 initrd -> initrd-2.4.21-260-athlon
root
977554 Dec 1 13:26 initrd-2.4.21-260-athlon
root
80324 Sep 23 2003 memtest.bin
root
64824 Sep 23 2003 message
root
25 Dec
1 13:26 vmlinuz -> vmlinuz-2.4.21-260-
1 root
root
1214206 Nov 17 17:58 vmlinuz-2.4.21-260-athlon
Se puede observar que hay tantos System.map-versión como kernels (los kernels son los
bzImage y también el vmlinux). Es importante destacar el vínculo dinámico de System.map ->
System.map-2.4.21-99-IMQ, y el caso de que actualmente el sistema está utilizando el kernel
vmlinuz-2.4.21-260-athlon.
Lo que sucede en este caso es que los procesos que necesitan System.map buscan primero
/boot/System.map, y detectan que la versión no corresponde, por lo que a continuación buscan
/boot/System.map-versión, y la encuentran. Esta inteligencia hace posible un entorno multiboot
con diferentes kernels.
Algunos procesos también buscan /System.map y finalmente en el código fuente,
/usr/src/linux/System.map. Pero es mejor y más ordenado no confiarse de esto, por lo que el
paso siguiente, luego de haber compilado, será copiar el archivo System.map en
/boot/System.map-versión.
Hay que tener en cuenta que este mapa es estático, y por lo tanto sirve sólo para el código estático
del kernel. Los símbolos de los módulos, por su naturaleza dinámica, no pueden ser incluidos en
System.map y por lo tanto no tienen relación alguna con este archivo.
Finalmente, sobre la importancia de este mapa se puede decir que pocos procesos lo utilizan,
principalmente klogd, que es el demonio de registro del kernel, toda vez que se produce un error,
para incluir el nombre del símbolo en ese registro. Process Status (ps) también lo utiliza. No contar
con un System.map adecuado (que es lo mismo que no tenerlo) no presenta un error fatal, sino más
que nada una molestia (mensajes como “System.map does not match actual kernel”), y la
imposibilidad de depurar el kernel. Dosemu puede no funcionar correctamente también en estos
casos.
Módulo II: Kernel
11
2.8 EL KERNEL Y SUS PARÁM ETROS
Ahora
vamos
a
encontrar la versión comprimida del kernel en /usr/src/arch
/i386/boot/bzImage (descontando que la arquitectura del sistema es x86).
Veamos un poco de nomenclatura, y de historia. Tradicionalmente, el nombre del archivo que
contiene el kernel se llama vmlinux; vm significa Virtual Memory (memoria virtual), y es
representativo de que este kernel está hecho para manejarla.
Poco después, se desarrolló un método para comprimir la mayor parte de la imagen del kernel y
descomprimirla durante el arranque, de modo que vmlinux pasó a ser vmlinuz, la z por gzip, que
es el formato en el cual (aún hoy) se comprime el kernel.
Antes de bzImage, estaba zImage, hecha para cargarse en la memoria baja de la PC (low
memory), y con la consiguiente restricción en tamaño, que resulta ser inferior a 580kB. Aun hoy
puede hacerse esta imagen, con make zImage.
El nombre del archivo con el kernel que generamos, bzImage, responde a Big zImage, y está
diseñado para cargarse en la memoria alta, permitiendo tamaños mucho mayores. No está
relacionado con el formato de compresión bzip, como el nombre parece sugerir.
A fin de cuentas, el nombre que tenga el kernel no es importante mientras esté correctamente
reflejado en el cargador de arranque (en caso de usar uno). Para seguir la tradición se puede copiar
el archivo usando cp bzImage /boot/vmlinuz-versión.
Ahora debemos preocuparnos por el comportamiento del kernel durante el arranque. Por defecto, el
kernel compilado buscará el sistema de archivos raíz (root filesystem) donde se encuentra el actual,
por ejemplo, /dev/hdb1. Por lo tanto, si estamos compilando un kernel para el sistema actual, no
habrá problema alguno.
Sin embargo, en caso de estar compilando para otro sistema donde el sistema de archivos raíz tenga
otra ubicación, tenemos 2 opciones para evitar el error (kernel panic) que se producirá como
consecuencia de la búsqueda del root donde no está: la primera es usar el comando rdev para
establecer en el mismo kernel el valor correcto para este parámetro, por ejemplo, rdev
/boot/bzImage-2.6.9 /dev/hda7. Para mayor información, consultar la página del manual de
rdev (man rdev). Si estamos preparando un disquete booteable que contiene el kernel, esta es la
solución a emplear.
Si se cuenta con un cargador de arranque como GrUB o LILO, se presenta la segunda opción, que
es especificar la ubicación del sistema de archivos raíz en la definición del kernel. Por ejemplo, en
GrUB, esto quedaría así:
title Linux
kernel (hd0,0)/boot/vmlinuz root=/dev/hda1 vga=0x317 splash=silent
desktop showopts
Módulo II: Kernel
12
Acá tenemos la oportunidad de observar otros parámetros del kernel, por ejemplo, vga=0x317
establece el modo de presentación del monitor. Con vga=ask se presenta una lista de los modos
disponibles. Más información sobre los modos de video se encuentra en /usr/src/linuxversión/Documentation/svga.txt.
muestra la imagen que enmarca a GrUB y la primera consola sin mostrar los
mensajes previos a la presentación de la imagen. desktop es un agregado de SuSE que ajusta el
comportamiento del kernel al indicar que la máquina es de escritorio (en lugar de un servidor).
showopts hace que GrUB muestre las opciones de booteo, pero estos tres últimos no son
parámetros del kernel propiamente dichos, sino más bien, parámetros del proceso de arranque.
splash=silent
La lista completa de parámetros del kernel se puede encontrar en el código fuente, en
/usr/src/Linux-versión/Documentation/kernel-parameters.txt. Sin embargo, vamos
a destacar algunos de los más útiles.
La consola en general es la primera terminal virtual, esto es, los mensajes de arranque se muestran
en el monitor a través de la placa VGA. A veces puede ser útil tener otro dispositivo para la
presentación de estos mensajes, y para la interacción con el sistema. Por ejemplo, un puerto serie, o
incluso una impresora. Para ello viene el parámetro console, que permite especificar este
dispositivo, por ejemplo, console=/dev/ttyS1,9600, para elegir el segundo puerto serie a 9600
bps.
Pueden incluso especificarse varias consolas simultáneas para visualizar los mensajes del kernel,
hasta una por cada tipo (una serie, una paralelo, una VGA) Es bueno tener en cuenta que para que
todo esto sea posible, los controladores del puerto serie deben estar compilados en el kernel.
Otra de las opciones importantes es el runlevel, que se puede especificar como un número. Por
ejemplo, si escribimos un 1, el sistema iniciará en modo monousuario. Lo mismo sucede con S o
single. Esto es especialmente útil cuando el proceso de arranque se detiene en alguna de las etapas
de init.
Veremos un tercer parámetro, con lo que se consigue algo similar al anterior. Por defecto, el kernel
ejecuta el comando /sbin/init una vez que terminó de cargarse. El parámetro init permite
establecer un comando diferente. Por ejemplo, configurando init=/bin/sh, al terminar de
cargarse el kernel quedaríamos en el shell, desde donde se pueden realizar tareas de reparación.
2.9 AJUSTE DE GRUB PARA EL ARRANQUE CON EL NUEVO KERNEL
Conociendo todo esto, configurar un gestor de arranque para que utilice el nuevo kernel será
sencillo. Basta con modificar una entrada existente o crear una nueva para el nuevo kernel, y
establecer a gusto los parámetros adecuados.
Módulo II: Kernel
13
Una de las funciones más interesantes de GrUB para el control de máquinas de difícil acceso o
simplemente sin monitor ni teclado es la posibilidad de especificar (similarmente a lo que sucede con
el kernel) una consola serie.
Para lograr esto, los pasos son sencillos. Primero, hay que asegurarse de no haber establecido la
opción --disable-serial cuando se compilaron las imágenes de GrUB.
Luego, en el archivo de configuración (típicamente /boot/grub/menu.lst), incluir las líneas:
serial --unit=1 --speed=9600
terminal --timeout=10 serial console
Siendo consistentes con el ejemplo dado para “console” del kernel, esto configura el COM2 a 9600
bps. La instrucción terminal indica que puede ser tanto serie como la tradicional, en la que primero
se presione una tecla.
Un archivo típico de configuración de GrUB en un sistema SuSE sería:
# Modified by YaST2. Last modification on Mon Jan 13 09:29:18 2003
color white/blue black/light-gray
default 0
timeout 8
gfxmenu (hd0,0)/boot/message
###Don't change this comment - YaST2 identifier: Original name: linux###
title Linux
kernel (hd0,0)/boot/vmlinuz root=/dev/hda1 vga=0x317 splash=silent
desktop showopts
initrd (hd0,0)/boot/initrd
###Don't change this comment - YaST2 identifier: Original name: floppy###
title Disquete
root (fd0)
chainloader +1
###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe
kernel (hd0,0)/boot/vmlinuz root=/dev/hda1 showopts ide=nodma apm=off
acpi=off vga=normal nosmp noapic maxcpus=0 3
initrd (hd0,0)/boot/initrd
###Don't
change
this
comment
memtest86###
title Prueba de memoria
kernel (hd0,0)/boot/memtest.bin
Módulo II: Kernel
YaST2
identifier:
Original
name:
14
Acá se pueden observar varios comandos, como color que asigna colores al menú, default que
establece cuál de todas las opciones de arranque debe estar predeterminada, timeout para saber
cuánto esperar antes de arrancar con la opción predeterminada y gfxmenu que indica dónde está la
imagen de fondo (splash). Estos son comandos generales e independientes de la opción de arranque.
Ya en las opciones de arranque se presentan los comandos kernel, que determina la ubicación del
mismo y le pasa parámetros, e initrd, que indica a GrUB la posición del initial RAMdisk, puesto que
como vimos anteriormente, le corresponde a GrUB el manejo de este “disco RAM”.
Una mención aparte merece la opción Disquete, donde el método de arranque es diferente, y es el
mismo utilizado para Windows en todas sus versiones. root especifica el sistema de archivos raíz, y
luego chainloader +1 carga el sector de arranque de ese disco o partición. El comando
chainloader (fd0)+1 sintetizaría los dos mencionados.
Por ejemplo, podríamos arrancar un SO Windows 98 residente en la segunda partición del primer
disco IDE de la siguiente manera:
root (hd0,1)
makeactive
chainloader +1
El comando makeactive hace activa la partición raíz, dejándola lista para arrancar.
GrUB tiene una línea de comandos, donde se pueden usar las instrucciones de manera interactiva, y
se puede acceder a él en un sistema SuSE apretando ESC en la pantalla del cargador de arranque.
Es recomendable leer el manual de GrUB, que se puede encontrar en el sitio de GNU:
http://www.gnu.org/software/grub/manual/grub.html.
2.10 CÓMO SE CARGAN LOS MÓDULOS EN EL KERNEL
Cuando un kernel que tiene posibilidad de cargar automáticamente los módulos necesita una
característica que no posee en memoria, el demonio de los módulos del kernel kmod ejecuta
modprobe con un parámetro que puede ser o bien directamente el nombre del módulo, como sería
ip_tables, o bien un nombre más genérico, como eth0. En esta circunstancia, modprobe
buscará en /etc/modprobe.conf esta cadena, y se encontraría con la línea:
alias eth0 via-rhine
que le indicará que el nombre del módulo a cargar es via-rhine.
Acto seguido, modprobe busca en /lib/modules/version/modules.dep, por ejemplo,
/lib/modules/2.4.21-260-athlon/modules.dep, y revisa cuales son las dependencias de
Módulo II: Kernel
15
via-rhine, esto es, si via-rhine necesita que otros módulos sean cargados antes que él mismo. En este
caso, la línea:
/lib/modules/2.4.21-260-athlon/kernel/drivers/net/via-rhine.o:
/lib/modules/2.4.21-260-athlon/kernel/drivers/net/mii.o
nos indica que hace falta cargar mii antes. El archivo modules.dep es generado por depmod –a,
que en general, no hace falta ejecutar porque de ello se encarga make modules-install.
En el paso final, modprobe llama a insmod, que es el proceso que de hecho carga los módulos
(pero no comprueba dependencias), de esta manera:
insmod /lib/modules/2.4.21-260-athlon/kernel/drivers/net/mii.o
insmod /lib/modules/2.4.21-260-athlon/kernel/drivers/net/via-rhine.o
Si el kernel no soporta la carga automática, habrá que cargar el módulo correspondiente
manualmente antes de poder utilizar el hardware, en este ejemplo, una placa de red. Cabe destacar
que si ejecutamos el último comando insmod sin haber ejecutado el anterior, con seguridad se
producirá un error de “unknown symbol”, que indica que hay funciones o variables (símbolos) que
se necesitan para cargar via-rhine que no están en memoria.
Los comandos para el manejo de módulos son los 2 que vimos anteriormente, modprobe e insmod
más lsmod (que presenta en pantalla todos los módulos en memoria) y rmmod (que elimina un
módulo de memoria, pero necesita soporte del kernel, o sea, una opción llamada “kernel module
unloading” debe estar activada).
Los módulos del kernel se encuentran en /lib/modules, y están separados por versiones. Esto
sirve al propósito de que al instalar los módulos de un kernel de una versión diferente no se borren
los de las versiones anteriores. Pero fundamentalmente, ayuda a modprobe a encontrar los módulos
de la versión del kernel que se está ejecutando, debido a que en general, los módulos compilados
para una versión del kernel no sirven para otra.
Recientemente, una característica llamada “module versioning support” permite cargar módulos de
versiones distintas al kernel en ejecución. Sin embargo, esta función no está completamente
desarrollada aun, por lo que es considerada como experimental.
2.11 CONSIDERACIONES Y CONSEJOS ÚTILES.
Con respecto a la compilación del kernel, es interesante en primer lugar leer el resultado del
comando make help, para dominar las opciones, que se encuentra en los kernels de LKA.
Módulo II: Kernel
16
Si se desean agregar módulos, no hace falta recompilar el kernel, sino sólo los módulos nuevos. Esta
es una de las mejores ventajas de los módulos, y fue mencionada con anterioridad. El comando
make modules modules_install bastará para tener los nuevos módulos compilados e
instalados.
El comando make clean elimina los archivos generados por la compilación, pero conserva la
configuración. Al compilar un kernel para la misma máquina, a veces es posible hacerlo sin la
limpieza, lo que acelera el proceso puesto que muchos archivos objeto ya están hechos. Sin
embargo, esta práctica puede causar problemas, por lo tanto, ante la primera dificultad por hacer
andar el nuevo kernel, se recomienda limpiar y recompilar.
Los comandos make mrproper o make distclean limpian el código fuente de todos los archivos
producto de la configuración y compilación. Por ende, también borran .config. Sin embargo, los
parches aplicados permanecen, puesto que ya son parte del código fuente mismo.
Módulo II: Kernel
17

KERNEL

Transcripción

Documentos relacionados

9.4. Módulos del kernel