Luis Angel Cofiño

 

29/12/2003: Configurarlo todo "por el libro"

Pues lo primero es bajarse las fuentes del nuevo kernel. En mi caso, he decidido instalar la versión 2.4.23, así que puedo, o bien instalar un fichero "tar.gz", o bien mediante un "apt-get".

Ojo, porque con "apt-get" solo debeis instalar fuentes del kernel, no se recomienda usarlo para cambiarlo por otro ya compilado. En cualquier caso, yo he decidido usar el sistema clásico, así que me voy a kernel.org y me bajo el fichero con las fuentes que más me interesen. En mi caso, linux-2.4.23.tar.gz

Ahora tengo que descomprimirlo en el directorio /usr/src. Comprobareis que el fichero tar.gz ocupa unos 40 Mb, pero una vez descomprimido se convierten en 150 ó 200 Mb dependiendo de la versión. Esto es porque las fuentes son texto puro, sin binarios, con lo que se comprimen muy bien.

	[16:59:43/0][lacofi@claudia:~]$ su
	password:
	[17:01:22/0][root@claudia:/home/lacofi]# cd /usr/src
	[17:02:06/0][root@claudia:/usr/src]# tar -xzvf linux-2.4.23.tar.gz
	[17:04:15/0][root@claudia:/usr/src]# ln -s linux-2.4.23 linux
	[17:04:19/0][root@claudia:/usr/src]# ls -d linux
	linux -> linux-2.4.23/

El sistema buscará siempre las fuentes del kernel en /usr/src/linux/. Por eso, tenemos que crear un enlace simbólico desde el verdadero directorio en el que están. Podemos instalar cuantas fuentes de kernel queramos, incluso varias versiones simultáneamente, por ejemplo la 2.4.23 y la 2.6.0, pero con solo cambiar este enlace simbólico le estaremos diciendo al sistema cuál es la que estamos compilando realmente.

Ahora llega la auténtica pesadez: configurar el kernel.

	[17:10:03/0][root@claudia:/usr/src]# cd linux 
	[17:10:11/0][root@claudia:/usr/src/linux]# make menuconfig

También sirve "make xconfig". En los nuevos kernels de la serie 2.6.x también podeis encontrar "make gconfig". Da igual. Cambia el aspecto en pantalla más o menos agradable, pero todos los interfaces hacen lo mismo. Personalmente, encuentro que el más sencillo y funcional es "menuconfig", pero es una cuestión de gustos más que de otra cosa.

Elijais el interfaz que elijais, ninguno os va a librar de la principal pesadez de compilar un kernel: tendreis que repasar una por una todas las opciones que aparecen, y por todos los submenús, activando y desactivando opciones según sea vuestro hardware. Naturalmente, teneis que conocer muy bien cuál es vuestro equipo. Quizás os pueda ayudar la salida del comando "dmesg", que os puede proporcionar valiosa información acerca de DMAs, chips que están en vuestra placa madre, etc. Pero cada equipo es un mundo aparte, así que no puedo ayudaros en eso y es inútil que os cuente qué opciones elegí yo. Al final, tendreis que recorrer todo el árbol de menuconfig o xconfig seleccionando y deseleccionando las vuestras.

Lo que sí debeis tener en cuenta es que muchas de las opciones (no todas) se pueden activar de dos formas distintas: incorporándolas al kernel o añadiéndolas como módulo. Si se activa simplemente con "yes" o "*", el código de esa opción quedará metido dentro, una vez compilado. Pero si se activa como módulo, el kernel solo llevará una marca para que acceda un módulo aparte, convirtiéndose éste en una especie de "kernel satélite" que se une al verdadero kernel solo cuando es necesario.

Por regla general, activaremos de forma plena aquellas opciones que formen parte de un hardware permanente. Por ejemplo, todas mis particiones de linux son de tipo reiserfs (no uso ext2), con lo que meteré el soporte reiserfs dentro del kernel, pero ext2 o vfat o iso9660 (el sistema de los CD-ROM) solo como módulo. Del mismo modo, el soporte para la tarjeta ethernet que me une a Telecable lo meteré también dentro del kernel, puesto que funciona continuamente (es una conexión permanente, de banda ancha). Por el contrario, el soporte para la otra tarjeta ethernet, la que une a Claudia y Moira, lo activaré como módulo, puesto que a veces están conectados pero a veces no: meter ese código dentro del kernel sería un desperdicio.

Para qué engañaros: la configuración del kernel es larga y tediosa. Afortunadamente, no hay por qué hacerla toda de una sola vez. Se puede hacer a ratos perdidos, grabando y leyendo lo ya hecho desde un fichero alternativo. Si vais al final de la lista de menúconfig vereis dos opciones "load" y "save" desde fichero alternativo, con lo que cuando nos cansemos, grabamos y cerramos. Este fichero será además muy valioso, porque a medida que vayamos modificando cosas, nos permitiría, en caso de error, retroceder sobre nuestros pasos y compilar un kernel idéntico a otro previo que sí funcionaba. Por eso, grabaremos estos ficheros alternativos con un nombre fácilmente identificable (en mi caso kalimero001, kalimero002, kalimero003, etc) y los pondremos a salvo en otro directorio, como copia de seguridad.

En cualquier caso, echadle un vistazo a las ayudas que están disponibles con casi todas las opciones. Están en inglés, claro, pero tienen bastante sentido común: a menudo dicen cosas como "si no sabes de qué estoy hablando, no lo necesitas, así que elige 'no'." ;-).

Si salimos de menuconfig, nos preguntará si queremos guardar la configuración. Aquí ya no se refiere al fichero alternativo sino al real, el que usará para compilar (para los curiosos, es /usr/src/linux/.config). Solo tendremos que contestar que sí cuando la configuración esté ya completa.

En mi caso, he configurado todo mi hardware como creo que es, incluyendo opciones avanzadas de las que no estoy seguro. Pero, mal que bien, he terminado. Así que salimos de menuconfig, decimos que sí, que lo grabe, y regresamos a la línea de comandos. Ahora, empezamos a compilar.

	[23:01:03/0][root@claudia:/usr/src/linux]# make dep; make clean; make bzImage

Empiezan a salir mensajes crípticos por la pantalla. No entiendo ni jota, pero parece que va para largo, así que me voy a tomar un café.

Tarda menos de lo que parece. Unos 5 ó 6 minutos en total. Pero todavía nos quedan los módulos, claro. En cualquier caso, cuando finaliza la compilación del núcleo, aparecerá un fichero llamado "bzImage" en el subdirectorio "arch/i386/boot/". Puede que salga un mensaje de error advirtiendo que el núcleo es demasiado grande para caber en un disquette (lo ignoramos). Tambien aparecerá otro fichero en "/usr/src/linux/" que se llama System.map. Vale, pero hay que ponerlos en su sitio.

	[23:09:24/0][root@claudia:/usr/src/linux]# cp System.map /boot/System.map-2.4.23
	[23:09:50/0][root@claudia:/usr/src/linux]# cd arch/i386/boot
	[23:09:54/0][root@claudia: ~~/i386/boot]# cp bzImage /boot/vmlinuz-2.4.23
	[23:10:13/0][root@claudia:/usr/src/linux]# cd /usr/src/linux

Ahora editamos el fichero /etc/lilo.conf y añadimos las opciones necesarias para que arranque el nuevo núcleo. Concretamente, añadimos la siguiente entrada:

	image=/boot/vmlinuz-2.4.23
		root=/dev/hda8
		label=Personal
		read-only

Naturalmente, suponemos que /dev/hda8 es la partición de nuestro Linux, la que se monta como "/".

Tened en cuenta que estamos añadiendo el nuevo kernel, no sustituyendo el antiguo (no se lo recomiendo a nadie, porque si la cosa no marcha, os quedais sin poder arrancar). Por eso, la entrada de /etc/lilo.conf es añadida a las que ya están, no sustituye a las viejas. Así, podemos arrancar con el nuevo o con el viejo, si las cosas van mal.

Ahora hacemos eficaces los cambios de lilo.conf:

	[23:15:24/0][root@claudia:/usr/src/linux]# lilo
	Added Linux *
	Added Personal
	Added Win2000

Ahora tenemos que compilar los módulos:

	[23:16:38/0][root@claudia:/usr/src/linux]# make modules; make modules_install	

Y nos vamos a ver la tele, porque esto sí que tarda un buen rato. Observad que pongo "make modules_install" y no "make install". Ésta última orden instalaría el kernel recién creado y lo metería en /boot/, pero no me gusta cómo lo hace. Yo prefiero manipular los nuevos núcleos a mano.

Cuando termine la compilación de los módulos, los meterá a todos en /lib/modules/2.4.23/, con lo que no se confunden nunca con los originales que venían de serie (núcleo 2.4.18-bf2.4, en mi caso).

Bueno, pues llega la hora de la verdad. Rebotamos la máquina. Cuando aparece Lilo elegimos "Personal" y vemos como sale el mensaje "Loading vmlinuz-2.4.23....". Después, la pantalla se queda en blanco. Eternamente. Ni un triste mensaje "kernel panic" que nos diga qué puñetas ha fallado. Simplemente se queda en blanco hasta que pulsamos el botón reset. Cuando vuelve a aparecer Lilo elegimos "Linux" y arrancamos como siempre.

La primera en la frente. Bueno, dicen que rara vez se consigue a la primera. :_)

 

30/12/2003: Intentonas desesperadas

Vale. Volvamos a empezar. Afortunadamente, ya tenemos la configuración hecha, así que se trata de ir corrigiendo. Eso nos ahorrará mucho trabajo, ¿verdad?.

Por otro lado, el hecho de que la pantalla se nos quede en blanco, nos orienta un poquito, si lo pensamos bien. Porque eso podría significar o un error tan gordo que no accede siquiera al procesador, o algo tan simple como que no engancha la pantalla.

Bien, hago un par de cambios, en el tipo de procesador y en la pantalla: concretamente, tengo una tarjeta Nvidia TNT2, que no aparece en los listados, pero sí una Nvidia GForce, así que la selecciono dentro del kernel, a ver que pasa. El procesador lo pongo en Pentium III (Coppermine), que es el mío.

	[15:01:08/0][root@claudia:/usr/src/linux]# make dep; make clean; make bzImage

Esta vez me sorprende la rapidez con la que compila. ¡Apenas un minuto!.

Instalo el nuevo kernel sustituyendo a la anterior porquería. Paso de los módulos, de momento, porque van a ser los mismos.

	[15:10:02/0][lacofi@claudia:/usr/src/linux]# cd arch/i386/boot
	[15:10:07/0][lacofi@claudia: ~~i386/boot]# cp bzImage /boot/vmlinuz-2.4.23
	[15:10:12/0][lacofi@claudia: ~~i386/boot]# cd /usr/src/linux
	[15:10:15/0][lacofi@claudia:/usr/src/linux]# cp System.map /boot/System.map-2.4.23

No necesito modificar Lilo porque he sobreescrito el kernel con el mismo nombre, así que ya está configurado.

Reboto la máquina y cuando sale el menú de Lilo elijo "Personal". Veo aparecer el mensaje "Loading vmlinuz-2.4.23.....". Después, la pantalla se queda en blanco. Este ordenador me está empezando a caer muy mal.

Rearranco con "Linux". Estoy bastante mosca por la rapidez con la que ha compilado. Demasiada, me parece. El tamaño del kernel no es el mismo que tenía ayer, así que da la impresión de que SI ha hecho algo, pero... ¿tal vez está usando algún tipo de caché para ahorrarse trabajo?. Solo por si acaso, prefiero asegurarme.

	[15:15:58/0][root@claudia:/usr/src/linux]# make mrproper

Ahora, el ordenador hace una limpieza y elimina TODO lo que procede de anteriores compilaciones, con lo que deja las fuentes mondas y lirondas, como recien desempaquetadas. Me supongo que también se cepilla la configuración previa, pero no los ficheros alternativos que he ido guardando. Cuando termina:

	[15:18:03/0][root@claudia:/usr/src/linux]# make menuconfig

Cargo el fichero alternativo que había creado y vuelvo a modificar cosas aquí y allá... que si meto ext2 dentro del kernel, en lugar de como módulo, que si cambio otra vez la pantalla gráfica y la pongo como módulo en lugar de dentro del kernel... Cuando termino vuelvo a compilar

La compilación, ahora, vuelve a tardar un montón. Está claro que antes usaba algún tipo de caché. Bueno... cuando termina sobreescribo el nucleo anterior con el recién creado, y reboto.

	[15:35:08/0][root@claudia:/usr/src/linux]# make dep; make clean; make bzImage
	(montón de cosas en chino)
	[15:46:02/0][lacofi@claudia:/usr/src/linux]# cd arch/i386/boot
	[15:47:07/0][lacofi@claudia: ~~i386/boot]# cp bzImage /boot/vmlinuz-2.4.23
	[15:47:12/0][lacofi@claudia: ~~i386/boot]# cd /usr/src/linux
	[15:47:15/0][lacofi@claudia:/usr/src/linux]# cp System.map /boot/System.map-2.4.23
	[15:47:23/0][lacofi@claudia:/usr/src/linux]# reboot
	System is going down now!!!!...

Cuando sale Lilo elijo "Personal".

"Loading vmlinuz-2.4.23...." y pantalla en blanco.

Basta.

 

1/1/2004: Paso a paso se hacen las cosas

Después de pensarlo un poco, he llegado a la conclusión de que puedo pudrirme cambiando opciones una y otra vez, hasta dar con el fallo. En lugar de eso, quizás debería abordar el problema desde otro punto de vista: hacer un núcleo muy sencillo, aunque no lo soporte todo. Pero al menos, que funcione, ¿no?.

Vuelvo a "make mrproper" y "make menuconfig" y empiezo a cambiar cosas de la configuración, pero esta vez a lo bestia. Ahora ya no intento que funcione todo lo que tengo, sino solo lo esencial.

Por ejemplo, en vez de "Pentium III (Coppermine)" elijo "Procesador de la serie 586/686... etc". En vez de AGP como bus gráfico elijo PCI a secas. Elimino el soporte USB. Y todo así. La clave es: cuanto más sencillo mejor.

Ejecuto "make dep ; make clean ; make bzImage", borro recursivamente el directorio /lib/modules/2.4.23, ejecuto "make modules ; make modules_install" y copio el nuevo kernel a /boot, como antes. Instalo Lilo y rearranco.

Y dice:

	Loading vmlinuz-2.4.23......
	Linux version 2.4.23 (root@claudia) (gcc version 2.95.4 20011002) 
	#1 jue ene 1 20:59:43 CET 2004
	BIOS-provided physical RAM map:
	BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
	BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
	BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
	BIOS-e820: 0000000000100000 - 000000000fffc000 (usable)
	BIOS-e820: 000000000fffc000 - 000000000ffff000 (ACPI data)
	BIOS-e820: 000000000ffff000 - 0000000010000000 (ACPI NVS)
	BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
	255MB LOWMEM available.
	On node 0 totalpages: 65532
	zone(0): 4096 pages.
	zone(1): 61436 pages.
	zone(2): 0 pages.
	Kernel command line: BOOT_IMAGE=Kernel ro root=308
	Local APIC disabled by BIOS -- reenabling.
	Found and enabled local APIC!
	Initializing CPU#0
	Detected 666.706 MHz processor.
	...

Síiiii. Y continúa con todos los mensajes del kernel hasta el login en consola. No funciona el login gráfico, claro, porque para simplificar no hemos habilitado los gráficos en nuestro kernel. Pero es linux, y es un nuevo kernel. Nuestro. El primero. Podemos logarnos y arrancar vim o cualquier programa de consola. ¡Estamos ya en marcha!. :-)

Lo primero es poner a salvo la configuración de este kernel.

	[15:30:18/0][root@claudia:/usr/src/linux]# mkdir ~/config_nucleos
	[15:30:19/0][root@claudia:/usr/src/linux]# cp .config ~/config_nucleos/kalimero001

En realidad sí funcionan los gráficos, pero no con los mismos drivers que antes, así que tendría que cambiar el fichero /etc/X11/XF86Config-4, cosa que no quiero hacer. Uno de los primeros objetivos, por tanto, es que los gráficos funcionen con los mismos drivers en ambos kernels. Hasta entonces, uno de los dos núcleos tendrá que quedarse sin X-Window. Naturalmente, el nuevo. :-(

Rearrancamos con el kernel de siempre y volvemos a "make menuconfig". Ahora activo las opciones AGPGART y VIA Apollo Pro, que es el chip que viene en mi placa madre (según me indica el comando dmesg). No se especifica en ningún lado la placa gráfica Riva TNT2 de Nvidia: lo más cercano es Nvidia GForce, pero ya se que no funciona. Así que no selecciono ninguna y compilo el nuevo kernel, con soporte AGPGART pero sin módulo para mi tarjeta.

	[15:35:08/0][root@claudia:/usr/src/linux]# make dep; make clean; make bzImage
	(montón de cosas en chino)

¿Por qué lo hago así?. Bueno, porque resulta que Nvidia ofrece drivers propios, así que me los bajo, los descomprimo en /usr/src y los compilo. Bien, no importa porque seguramente vosotros no teneis una Riva TNT2 (en una placa ya antigua), asi que no me meto en más detalles. De todas formas, solo tendríais que leeros el README.TXT que vienen con los drivers...

La cuestión es que ahora tengo otro kernel recién compilado. Pero esta vez no quiero sobreescribir el previo, que ya funcionaba. Por eso, vamos a recurrir a un pequeño truco. Edito el fichero de root donde almaceno los alias (puede ser .bashrc, pero en mi caso es .alias) y creo dos alias nuevos, así:

	alias copianucleo='cp arch/i386/boot/bzImage /boot/vmlinuz-2.4.23.test\
			; cp System.map /boot/System.map-2.4.23.test'
	alias fijanucleo='cp /boot/vmlinuz-2.4.23.test /boot/vmlinuz-2.4.23\
			; cp /boot/System.map-2.4.23.test /boot/System.map-2.4.23'

Ahora hay que volver a logarse como root para que cargue los nuevos alias especificados en .bashrc.

	[21:43:02/0][lacofi@claudia:/usr/src/linux]# exit
	[21:43:03/0][lacofi@claudia:~]$ su
	password
	[21:43:32/0][lacofi@claudia:/home/lacofi]# cd /usr/src/linux
	[21:43:45/0][lacofi@claudia:/usr/src/linux]# copianucleo

Con el último comando, copiamos el nuevo kernel en un fichero vmlinuz-2.4.23.test (observemos que NO es el mismo que contiene el kernel recompilado funcionante: vmlinuz-2.4.23). Ahora hay que editar /etc/lilo.conf, para añadir las lineas que están en color cian:

	image=/boot/vmlinuz-2.4.23
		root=/dev/hda8
		label=Personal
		read-only
	
	image=/boot/vmlinuz-2.4.23.test
		root=/dev/hda8
		label=Inestable
		read-only

Ejecutamos "/sbin/lilo" para fijar los cambios:

	[21:48:22/0][lacofi@claudia:/usr/src/linux]# lilo
	Added Linux *
	Added Personal
	Added Inestable
	Added Win2000

Bien, pues ya está definida nuestra mecánica de trabajo. :-)

A partir de ahora iremos introduciendo pequeños cambios en los kernel. Cada vez que creemos uno nuevo ejecutaremos el comando "copianucleo" y rebotaremos la máquina. En Lilo, elegiremos "Inestable" y comprobaremos que tal ha quedado. Si el nuevo kernel nos satisface, solo tendremos que ejecutar "fijanucleo" para que lo convierta en nuestro nuevo kernel "Personal" y después pondremos a salvo la configuración copiando el fichero alternativo "kalimeroXX" a "~/config_nucleos". Aún así, siempre dispondremos del núcleo que venía de serie, que de momento seguirá siendo el kernel por defecto.

¿Vale?. Pues venga. Rebotamos la máquina y elegimos "Inestable". ¡Arranca!. Y no solo eso, sino que ahora soporta correctamente la tarjeta gráfica. Ahora ya tenemos X-Window en nuestro nuevo kernel. Pero aún quedan cosas, como USB, Internet, el tipo de procesador, etc. Pero tiempo al tiempo. En cualquier caso, damos unas vueltas, y vemos que este último núcleo consigue lo que pretendía (controlar el sistema gráfico, cosa que el previo no hacía). ¿Estamos satisfechos?. Pues sí. Así que rebotamos y...

	[22:18:42/0][lacofi@claudia:/usr/src/linux]# fijanucleo
	[22:21:12/0][lacofi@claudia:/usr/src/linux]# cp .config ~/config_nucleos/kalimero002

 

5/1/2004: Internet (primer asalto)

Hoy toca compilar otro núcleo que pueda conectarse a Internet.

Bien, ya conocemos parte del camino:

	[23:01:02/1][lacofi@claudia:/usr/src/linux]# make menuconfig

Nos vamos a la sección "Network device support", subsección "Ethernet (10 or 100Mbit)". Activo mi tarjeta Ethernet Realtek 8029 dentro del kernel. No está especificada tal tarjeta en ningún sitio, pero sí la "NE2000 compatible" y yo se que eso incluye la RTL 8029. Por si acaso, se puede consultar en la ayuda de esta opción y ahí vemos que sí se menciona. También activo mi otra tarjeta, una Realtek 8139 Fast Ethernet, pero como módulo. En el resto, y salvo excepciones, me dejo llevar por las recomendaciones que aparecen en las ayudas: cuando dice "en caso de duda contesta no", pues eso. Cuando dice lo contrario, contesto si.

Excepto en un par de cosas. Por ejemplo, en contra del consejo quiero activar IP_TABLES, porque sé que mi cortafuegos lo está usando.

	[23:12:12/1][lacofi@claudia:/usr/src/linux]# make clean ; make bzImage

En esta ocasión estamos probando más cosas. He leido en alguna parte que si se trata de una recompilación sencilla no se necesita repetir el "make dep". Por eso, al principio, no hemos hecho un "make mrproper".

	[23:24:31/0][lacofi@claudia:/usr/src/linux]# make modules ; make modules_install
	(montón de cosas en chino)
	[23:29:42/0][lacofi@claudia:/usr/src/linux]# copianucleo

Reseteamos la máquina y en Lilo elegimos "Inestable".

Reconoce la tarjeta, pero la red no funciona. Por algún motivo no ha conseguido enganchar el servidor de Telecable. (?).

	[23:48:01/0][lacofi@claudia:~]# /sbin/ifconfig eth0
	eth0	Link encap:Ethernet  HWaddr 52:54:05:E5:7F:E7
		UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
		RX packets:2236 errors:0 dropped:0 overruns:0 frame:0
		TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
		collisions:0 txqueuelen:1000
		RX bytes:134877 (131.7 KiB)  TX bytes:0 (0.0 b)
		Interrupt:11 Base address:0xb400

Bueno pues no funciona. Como veis, en IFCONFIG se ve que no se ha asignado ninguna dirección IP a la tarjeta. Bueno, no lo veis porque no está. Eso es precisamente lo que llama la atención, que falta alguna linea donde diga eso tan bonito de "inet addr:212.89.18.113 etc". Hummm... eso nos da una pequeña pista. La tarjeta funciona, pero falla el cliente de DHCP (que es quien asigna las direcciones IP). ¿Probamos a reiniciar la red, a ver qué nos dice?.

	[23:48:05/0][lacofi@claudia:~]# /etc/init.d/networking stop
	[23:48:09/0][lacofi@claudia:~]# /etc/init.d/networking start
	(aquí dice algunas cosas que no nos importan ahora, y luego...)
	Internet Software Consortium DHCP Client V3.0.1rc9
	Copyright 1995-2001 Internet Software Consortium.
	All rights reserved.
	For info, please visit http://www.isc.org/products/DHCP

	run-parts: component debug-enter is not an executable plain file
	run-parts: component debug-exit is not an executable plain file
	socket: Protocol not available - make sure
	CONFIG_PACKET (Packet socket) and CONFIG_FILTER
	(Socket Filtering) are enabled in your kernel
	configuration!
	done.

Caramba, un poco más y nos pone una linea de puntos con el lema "corte por aquí", ¿verdad?. ;-)

Pues está bastante claro: Hay que activar esas dos opciones la próxima vez que compilemos el kernel. Pero será otro día.

¿Estamos satisfechos con este kernel?. Con este no, así que nada de fijanucleo. ;-)

Pero tal vez necesitemos esta configuración más adelante. Por lo menos hemos avanzado algo: las tarjetas de red son reconocidas aunque falla su asignación de direcciones IP. Por eso, guardamos la configuración de este kernel en "~/config_nucleos/kalimero003"

 

12/1/2004: Internet (segundo asalto)

Tengo el pálpito de que va a ser un buen día, así que vamos a empezar desde una posición de ventaja ;-).

	[12:12:28/0][lacofi@claudia:~]$ su
	password:
	[12:13:13/0][lacofi@claudia:/home/lacofi]# cd /usr/src/linux
	[12:13:54/0][lacofi@claudia:/usr/src/linux]# make mrproper
	(montón de cosas en chino)
	[12:15:01/0][lacofi@claudia:/usr/src/linux]# make menuconfig

Cargo la configuración que había guardado en el último fichero alternativo. y reviso como tenía ajustados los parámetros de red. Efectivamente, observo que la opción "CONFIG_FILTER" estaba desactivada, así que la activo. Ya puestos, también pongo algunos parámetros de USB.

	[12:19:21/0][lacofi@claudia:/usr/src/linux]# make dep ; make clean ; make bzImage
	(montón de cosas en chino)
	[12:26:29/0][lacofi@claudia:/usr/src/linux]# make modules ; make modules_install
	(más cosas en hebreo)
	[12:31:18/0][lacofi@claudia:/usr/src/linux]# copianucleo
	[12:31:21/0][lacofi@claudia:/usr/src/linux]# reboot
	System will shutdown NOW!!!

Reinicio el sistema y, en Lilo, elijo "Testando". Sale el mensaje "Loading vmlinuz.test..." y después tres líneas de mensajes. Después, el ordenador se cuelga. (!!!). Lo siento, no me acordé de anotar lo que ponía el mensaje de error, pero venía a decir que el Kernel estaba fuera de no se dónde.

No parecía un error del Kernel, propiamente dicho, sino que recordaba (apestaba), a un fallo de Lilo. Quizás es que necesito ejecutar lilo tras cada compilación, después de todo.

Reboto y rearranco con mi kernel por defecto, el de Debian. Una vez en la linea de comandos ejecuto Lilo.

	[12:45:34/0][lacofi@claudia:/home/lacofi]# /sbin/lilo
	Added Debian *
	Added Personal
	Added Inestable
	Added Win2000

Y vuelvo a rebotar. En el menú de Lilo elijo la opción "Inestable". Ahora sí arranca (parece que sí, que hay que ejecutar lilo siempre, después de cada compilación, así que ya lo sabeis). El ordenador arranca correctamente, pero la cuestión es si hemos conseguido que funcione Internet después de corregir "CONFIG_FILTER".

	[13:01:58/0][lacofi@claudia:~]$ /sbin/ifconfig eth0
	eth0	Link encap:Ethernet  HWaddr 52:54:05:E5:7F:E7
		inet addr:212.89.28.188  Bcast:212.89.31.255  Mask:255.255.248.0
		UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
		RX packets:451414 errors:0 dropped:0 overruns:0 frame:0
		TX packets:16069 errors:0 dropped:0 overruns:0 carrier:0
		collisions:13 txqueuelen:1000
		RX bytes:33483707 (31.9 MiB)  TX bytes:1409495 (1.3 MiB)
		Interrupt:11 Base address:0xb400

¡¡Siiii señor!!. Vemos que la tarjeta ethernet es reconocida, como antes, pero ahora, además, se ha asignado una dirección IP concreta (por parte del servidor DHCP de Telecable), y se ha configurado una red. Observa la segunda línea, donde figura la dirección IP de mi máquina, la dirección Broadcast y la máscara de red. Pero la prueba de fuego es intentar acceder a algún ordenador que sé que existe en Internet.

	[13:02:12/0][lacofi@claudia:~]$ ping www.google.com
	PING www.google.akadns.net (216.239.59.99): 56 data bytes
	64 bytes from 216.239.59.99: icmp_seq=0 ttl=241 time=97.1 ms
	64 bytes from 216.239.59.99: icmp_seq=1 ttl=241 time=110.4 ms
	64 bytes from 216.239.59.99: icmp_seq=2 ttl=241 time=109.5 ms
	64 bytes from 216.239.59.99: icmp_seq=3 ttl=241 time=91.1 ms
	64 bytes from 216.239.59.99: icmp_seq=4 ttl=241 time=99.5 ms

	--- www.google.akadns.net ping statistics ---
	5 packets transmitted, 5 packets received, 0% packet loss
	round-trip min/avg/max = 91.1/101.5/110.4 ms

¡Y esssooooo!. Estamos en la red. Si funciona también la Intranet, sería perfecto...

	[13:02:34/0][lacofi@claudia:~]$ /sbin/ifconfig eth1
	eth2: error fetching interface information: Device not found

Vaya por Dios. No encuentra a moira. Algo he hecho mal con la configuración de la segunda tarjeta Ethernet. :-?

¿O no?.

Espera un momento... la había configurado como módulo, no dentro del kernel. Tal vez es que el módulo no se ha cargado, simplemente...

	[13:11:16/0][lacofi@claudia:~]$ su
	password:
	[13:11:49/0][root@claudia:/home/lacofi]# modprobe 8139too
	[13:11:59/0][root@claudia:/home/lacofi]# cd /etc/init.d
	[13:12:03/0][root@claudia:/etc/init.d]# ./networking stop ; ./networking start
	[13:12:15/0][root@claudia:/etc/init.d]# /sbin/ifconfig eth1
	eth1	Link encap:Ethernet  HWaddr 20:E0:4C:39:3E:6D
		inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
		UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
		RX packets:49 errors:0 dropped:0 overruns:0 frame:0
		TX packets:59 errors:0 dropped:0 overruns:0 carrier:0
		collisions:0 txqueuelen:1000
		RX bytes:3660 (3.5 KiB)  TX bytes:3831 (3.7 KiB)
		Interrupt:9 Base address:0x2000
	[13:12:39/0][root@claudia:/etc/init.d]# ping moira
	PING moira.es (192.168.0.2): 56 data bytes
	64 bytes from 192.168.0.2: icmp_seq=0 ttl=64 time=0.5 ms
	64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=0.2 ms
	64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=0.2 ms

	--- moira.es ping statistics ---
	3 packets transmitted, 3 packets received, 0% packet loss
	round-trip min/avg/max = 0.2/0.3/0.5 ms

Ahí estaaaas, que te he vistoooo... :-D

Ahora pongo un Memorybird en el puerto USB: lo reconoce y funciona.

Echo un vistazo a diferentes dispositivos: imprimo algo, escaneo algo... escucho un disco, veo una película DVD... De momento, todo bien. ¿Estoy satisfecho?. Pues sí.

	[13:56:10/0][root@claudia:/usr/src/linux]# fijanucleo
	[13:57:04/0][root@claudia:/usr/src/linux]# cp .config ~/config_nucleos/kalimero004

Parece que funciona todo. No de manera perfecta, porque por ejemplo no he activado ni APM ni otros sistemas de gestión avanzada de energía, ni tampoco he optimizado el kernel para un Pentium III, específicamente. Por otro lado, los módulos de USB o de la segunda tarjeta de red, hay que cargarlos a mano, cosa que tendré que arreglar el próximo día. Pero el kernel funciona, funciona perfectamente.

Pero... ¿es mejor que el que venía con Debian?. :-?

Vamos a poner este kernel a prueba, una dificil, con un programa que realmente exija mucho de mi máquina...

Vamos a jugar al bzflag. :-D

La primera sorpresa es que funciona el sonido. No necesito desactivar el de KDE, simplemente funciona. Quizás porque he configurado la tarjeta de sonido dentro del propio kernel, no lo se. El caso es que funciona.

La segunda sorpresa es que bzflag funciona con una suavidad pasmosa. Yo creo que nunca lo había visto correr de una forma tan suave. La tercera son los tiempos de lag que estoy manejando. Internet va mejor que nunca, no se si por casualidad o por el kernel. Pero son demasiadas casualidades juntas. :-)

Salgo de bzflag y someto a la máquina a un poco de estrés. Empiezo a cargar programas potentes, como Openoffice o Mozilla y a ver que tal funcionan. El sistema se comporta muy bien, tengo la sensación de que mejor que antes, como si tuviera más RAM y un procesador ligeramente más rápido.

Sí señor. Ha merecido la pena. :-)

Tanto, que por primera vez no reboto la máquina para volver al kernel de Debian. Y tanto, que unas horas más tarde edito /etc/lilo.conf y cambio la línea donde pone "default=Debian" por otra que pone "default=Personal". Ejecuto Lilo y a partir de entonces, mi nuevo Kernel será el Kernel por defecto. :-)

	[19:04:05/0][root@claudia:/home/lacofi]# /sbin/lilo
	Added Debian
	Added Personal *
	Added Inestable
	Added Win2000

 

15/1/2004: Pequeños ajustes y compilando otro kernel

Hoy hacemos pequeños ajustes en nuestro kernel. Principalmente, vamos ajustar cosas como el tipo de procesador, la gestión de energía, etc. Además, me he replanteado algunos módulos. Algunos de ellos, los voy a meter dentro del kernel. Otras funciones menos importantes las voy a sacar como módulos. En fin, ajustes menores para depurar mi núcleo.

	[22:42:04/0][lacofi@claudia:/usr/src]$ su
	password
	[22:42:12/0][lacofi@claudia:/usr/src]# make mrproper
	(montón de mensajes en chino)
	[22:43:14/0][lacofi@claudia:/usr/src]# make menuconfig
	(hago todos los ajustes)
	[22:45:04/0][lacofi@claudia:/usr/src]# make dep ; make clean ; make bzImage \
	> make modules ; make modules_install ; copianucleo ; lilo

Qué narices, puedo dar todas las órdenes "make" en una sola línea, ¿no?. Bueno pues me voy a ver un rato la tele. Al cabo de un buen rato regreso, compruebo que ya ha terminado, y reseteo el ordenador. En el menú de Lilo elijo "Inestable".

Arranca, sí, arranca. Pero observo en los mensajes del kernel que están saltando un montón de mensajes "unresolved symbols" que antes no aparecían...

¿Qué está pasando?. Pues claro, es lógico cuando lo pienso un poco... El nuevo kernel que acabo de compilar almacenará sus módulos en /lib/modules/2.4.23 pero este directorio es el mismo que usó el anterior kernel. Eso significa que el nuevo kernel se va a encontrar módulos que no tenía previsto encontrar. Digamos que están entrando en conflicto ambos kernels, porque se encuentran con varios módulos que en realidad no le pertenecen.

¿Solución?. Pues tiene mala solución, pero hay una opción que añade una raiz personalizada al kernel compilado (algo así como vmlinuz-2.4.23-kalimero, por ejemplo), de tal forma que los módulos se grabarían en "/lib/modules/2.4.23-kalimero" y no entrarían en conflicto.

Vale, si quieres usar ese sufijo personalizado tienes que editar "a mano" el fichero /usr/src/linux/Makefile y cambiar la entrada "EXTRAVERSION=" que aparece al principio. Normalmente está vacía, así que tienes que añadir algo, por ejemplo "EXTRAVERSION=-kalimero" de tal forma que la próxima vez que compiles, los módulos iran a parar a /lib/modules/2.4.23-kalimero y no entrarán en conflicto con los de /lib/modules/2.4.23 que ya estaban compilados.

Pero lo cierto es que no me interesa esa solución. Recordad que solo quiero UN nucleo funcionante: lo que estoy haciendo es simplemente perfeccionarlo. Así que no tengo ningún interés en conservar el previo, excepto, tal vez, el fichero alternativo donde guardo la configuración. En el peor de los casos, puedo recuperar ese fichero alternativo y recompilar de nuevo cualquiera de mis kernels.

De momento, la solución que adopto es la más macarrónica pero también la más práctica:

	[23:22:32/0][lacofi@claudia:/usr/src]# rm -Rf /lib/modules/2.4.23
	[23:23:24/0][lacofi@claudia:/usr/src]# make modules ; make modules_install
	[23:35:05/0][lacofi@claudia:/usr/src]# reboot

Vale. Solo hace falta compilar los módulos, no el núcleo. Y no hace falta tampoco ejecutar lilo porque no hemos tocado el núcleo.

Eso sí, si arrancamos con el núcleo previo veremos que ahora es él el que falla por encontrar "unresolved symbols" o módulos que le faltan. Lo que pasa es que da igual. Siempre podemos recurrir al fichero alternativo "kalimero004" si todo va mal y hay que recompilarlo (para eso los estamos guardando, ¿no?). Pero de momento, nos interesa más ver éste kernel nuevo. ¿Va bien?. Pues sí, me gusta:

	[23:43:14/0][lacofi@claudia:/usr/src/linux]# fijanucleo
	[23:43:16/0][lacofi@claudia:/usr/src/linux]# cp .config ~/config_nucleos/kalimero005
	[23:43:34/0][lacofi@claudia:/usr/src/linux]# lilo
	Added Debian 
	Added Personal *
	Added Inestable 
	Added Win2000

Vale, pero esto no es todo. Hoy tengo cierto interés por un núcleo concreto, el 2.4.24. El por qué lo veremos otro día ;-)

La cuestión es si me apetece volver a pasar por el peñazo de configurar un núcleo entero desde el principio.

¿O no es desde el principio?. Porque... ¿cómo almacena la información el fichero alternativo "kalimero005", por ejemplo?. Bien, échale un vistazo a ese archivo (o el que tú uses) y verás que es simplemente un listado de opciones en formato de texto plano. ¿Cabe la posibilidad que el kernel 2.4.24 adquiera la información de un archivo de configuración creado con 2.4.23?. Eso me ahorraría mucho trabajo... :-)

Pues dicho y hecho. Me bajo un nuevo kernel 2.4.24, lo descomprimo en "/usr/src" y vamos allá.

	[23:47:13/0][lacofi@claudia:/usr/src]# rm linux
	[23:47:16/0][lacofi@claudia:/usr/src]# ln -s linux-2.4.24 linux
	[23:47:25/0][lacofi@claudia:/usr/src]# cd linux ; cp ~/config_nucleos/kalimero005 .
	[23:47:29/0][lacofi@claudia:/usr/src/linux]# make menuconfig

Nos vamos abajo del todo y le decimos que cargue un fichero alternativo. Nos pregunta cual y le indicamos "kalimero005". Echamos un vistazo y... ¡sí, lo ha configurado todo!.

	[00:15:11/0][lacofi@claudia:/usr/src/linux]# make dep ; make clean ; make bzImage \
	> make modules ; make modules_install

Este kernel lo utilizaremos más adelante. De momento nos limitamos a añadir otra entrada para él en /etc/lilo.conf y luego lo activamos.

	[00:28:13/0][lacofi@claudia:/usr/src/linux]# lilo
	Added Debian
	Added Personal *
	Added 2.4.24
	Added Inestable
	Added Win2000

Y con esto y un bizcocho...

 

16/1/2004: Parchear un kernel y otros ajustes

Pues ya son las ocho. ;-)

Vale, hoy vamos a hacer algún ajuste más, pero lo primero es parchear el kernel.

Ostras, tú, ¿y eso que es?. Bueno, pues un parche viene a ser exactamente lo que parece: un remiendo que se le hace sobre la marcha para incorporar las últimas funcionalidades sin necesidad de pasar por el mal trago de tener que bajarse un kernel completo. En lugar de eso, nos bajamos el parche, que es un fichero que contiene SOLO los cambios (las líneas de código que se quitan, las que se añaden, y esas cosas). No, no hay que editar el código a mano. Hay un programa que hace eso automáticamente, así que hay que ir perdiéndole el miedo. :-)

Es importante no confundirse de parche, eso sí. Tened en cuenta que éste va a presuponer que determinadas líneas de código están en sitios concretos. Si lo aplicais a un kernel distinto, o que ya ha sido parcheado, es posible que se vaya todo a freir espárragos. Por eso, muchas veces los parches para un kernel concreto están numerados, de tal forma que tienes que aplicarlos todos por riguroso orden: se parchea con el número 0, luego con el número 1, y así sucesivamente hasta el que te interesa en realidad. O bien aplicas un "macroparche" que hace TODOS los cambios de una tacada él solito, pero suelen ser de tamaño bastante más grande (cientos de Kb).

En mi caso, voy a aplicar el "parche Kraxel rc1" para 2.4.24 que se puede encontrar en el servidor de video4linux. No os pongo más detalles ni enlaces porque ya lo he hecho y SE que no va a reconocer mi tarjeta Pinnacle. ;-) :-(. Pero está bien como demostración de cómo parchear los kernel. De todo se va aprendiendo en esta vida.

Lo primero, sin duda, es limpiar un poco:

	[20:34:51/0][root@claudia:.../linux]# make mrproper
	(montón de cosas en griego)

Ahora aplicamos el parche. Para los curiosos, estoy usando un CD-RW multisesión para guardar todos los parches y kernels que voy bajando, que el espacio del disco duro empieza a apurar:

	[20:36:11/0][root@claudia:.../linux]# mount /dvd
	[20:36:14/0][root@claudia:.../linux]# zcat /dvd/patch-2.4.24-kraxel.gz | patch -p0
	patching file linux/arch/x86_64/boot/install.sh
	patching file linux/Documentation/Configure.help
	patching file linux/Documentation/scsi-changer.txt
	patching file linux/arch/sparc64/config.in
	patching file linux/arch/sparc64/kernel/ioctl32.c
	patching file linux/drivers/scsi/Config.in
	(etc, etc, etc...)
	patching file linux/mm/mprotect.c
	patching file linux/mm/proc_mm.c
	patching file linux/kernel/ksyms.c
	[20:38:07/0][root@claudia:.../linux]# make menuconfig

Parémonos aquí un segundo. El fichero que contiene el parche es texto puro, así que para aplicarlo hay que usar el comando "cat" y hacer una tubería (pipe) al programa automático que va a aplicarlo, que es "patch". Sin embargo, el fichero de texto está, casi siempre, comprimido con gzip, así que o lo descomprimimos antes o usamos "zcat" que al final es siempre lo más práctico.

Observad que no sale ningún mensaje de error. Buena señal, claro, el parche ha funcionado correctamente y ha encontrado en el código todo lo que esperaba encontrar en el sitio correcto. Si empiezan a salir mensajes de error, el parche no será válido así que es posible que la compilación del kernel o de los módulos aborte con un lacónico mensaje de error. Eso es porque o bien el parche no es el adecuado, o bien ya ha sido parcheado antes y el nuevo es incompatible. Pero no tengais miedo porque es reversible. :-)

Pues sí. Si falla por ejemplo el fichero "tuner.c" que se encuentra en el subdirectorio "drivers/media/video/.", después de aplicar el parche encontraremos otros dos ficheros que antes no estaban: tuner.c.orig y tuner.c.rej (el primero contiene el fichero íntegro, tal y como era antes del parche, así que ahí tenemos la solución. El segundo contiene solo los cambios que no han podido aplicarse así que le interesa más que nada al programador, no a nosotros).

¿Vale?. Pues ahora configuramos el kernel o incorporamos una configuración previa desde uno de nuestros ficheros alternativos. Luego borramos de /lib/modulos/2.4.24 con un "rm -Rf" y compilamos el kernel parcheado y sus módulos. Hacemos un "copianucleo" y ejecutamos lilo.

Reboto y compruebo el kernel. Funciona bien, pero no, no consigue controlar el tuner de mi Pinnacle. Pero al menos sé que los programadores de video4linux están tras ello y yo he aprendido una cosa más.

Aprovecho esta sesión para hacer algún cambio más en el kernel, en plan de perfeccionamiento. Así que vuelvo a "/usr/src/linux" y:

	[22:00:49/0][root@claudia:/usr/src/linux]# fijanucleo
	[22:01:02/0][root@claudia:/usr/src/linux]# make mrproper #hacemos limpieza
	[22:03:13/0][root@claudia:/usr/src/linux]# make menuconfig

Configuramos el kernel. Concretamente, hago unos cuantos ajustes que he ido apuntando en las comprobaciones de los kernels previos:

1. Meto todos los módulos de iptables dentro del kernel. Tengo una conexión permanente a Internet, así que iptables funcionará SIEMPRE, desde el arranque hasta el apagado. Así que no tiene mucho sentido cargarlos como módulos, y estoy harto de que cada vez que pido un listado con "lsmod" me salgan como 20 o 30 módulos en pantalla, la gran mayoría de opciones de iptables.
2. Me voy a la sección de "Console" y activo la sección "Video mode selection support". Esto hace que el arranque muestre los mensajes con letras más guapas usando modos de pantalla de la BIOS distintos a la VGA estandar.
3. Elimino del kernel el soporte APIC. No se muy bien qué es lo que hace. Sé que tiene que ver con las interrupciones IRQ, que tiene que ver con máquinas multiprocesador, y que mi placa madre lo soporta, aunque solo tiene un único procesador. Sé que podría aumentar el rendimiento del ordenador, pero evita que los periféricos entren en hipernación e impide la actuación de APM o de ACPI (no confundir con APIC, que son cosas distintas). De momento, voy a probar sin APIC para ver como me funciona el kernel con ACPI. (jodó, esto parece un trabalenguas) :-)
4. También añado una opción de arranque en lilo.conf, que dice 'append="acpi=force"'. La salida de dmesg me aconseja añadir esta opción porque detecta que mi BIOS es anterior al 2000 y no se fia demasiado, asi que desconecta ACPI. O sea, reconoce que mi placa madre lo soporta, pero como es antigua se resiste un poco y lo desactiva con una advertencia. Bien, decido probarlo, así que añado esta opción para forzar la activación de ACPI, tal y como dice la advertencia de dmesg.

Vale, pues hacemos esos cambios, grabamos la configuración y volvemos a compilar.

	[22:19:23/0][root@claudia:.../linux]# rm -Rf /lib/modules/2.4.24 &
	[22:19:56/1][root@claudia:.../linux]# make dep ; make clean ; make mrproper
	(ahora montón de cosas en hebreo)
	[22:28:00/0][root@claudia:.../linux]# make modules ; make modules_install ; \
	> copianucleo ; lilo
	(el hebreo suena a chino)

Cuando termina, reboto el ordenador y elijo "Inestable" en el menú. Dice "Loading vmlinuz-personal.test...." y luego se queda la pantalla en blanco. El ordenador parece colgado.

¡Ostras!. Acabo de aislar el fallo que me bloqueaba el aparato al principio del todo, mira tú. Deduzco que ha sido "Video mode selection support", pero se comprueba fácilmente compilando otro kernel sin esa opción (no hace falta ni mrproper, ni hacer los módulos ni "make dep", sino solo "make clean ; make bzImage", así que la comprobación es muy rápida). :-D

Así que ya lo sabeis todos: si tras configurar y recompilar un kernel la pantalla se os queda en blanco y el ordenador parece colgarse, probad a retirar la opción "Video mode selection support" de la sección "Console".

 

No puedo montar mi CD-RW

Hoy afronto la última recompilación del kernel que se podría considerar como "necesaria".

El motivo es que me he dado cuenta de que soy incapaz de montar mi CD-RW. Entendámonos, puedo grabar sin problemas usando cualquiera de mis programas habituales, porque acuden directamente a una dirección SCSI concreta. Pero después, no puedo montar el disco que acabo de grabar para leerlo. La otra unidad, el DVD, lo hace sin problemas, pero no la grabadora. Observa los mensajes de error que me da, porque puede ocurrirte a tí:

	[12:12:06/0][lacofi@claudia:~]$ mount /mnt/cdrw
	mount: /dev/cdrw is not a valid block device
	[12:13:12/0][lacofi@claudia:~]$ ls /dev/cdrw
	/dev/cdrw -> hdc
	[12:13:19/0][lacofi@claudia:~]$ su
	password
	[12:14:01/0][root@claudia:~]# mount /dev/hdc /mnt/cdrw -t iso9660 -o ro
	mount: wrong fs type, bad option, bad superblock on /dev/hdc,
		or too many mounted file systems
		(could this be the IDE device where you in fact use
		ide-scsi so that sr0 or sda or so is needed?)
	[12:15:13/0][root@claudia:~]# ls /dev/sr0
	/dev/sr0 -> scd0
	[12:15:27/0][root@claudia:~]# mount /dev/scd0 /mnt/cdrw -t iso9660 -o ro
	mount: /dev/scd0 is not a valid block device
	[12:15:32/0][root@claudia:~]# mount /dev/sda /mnt/cdrw -t iso9660 -o ro
	mount: /dev/sda is not a valid block device

Y así sucesivamente. No encuentro ningún dispositivo en el que poder montar mi CD-RW. ¿Qué está pasando?

Bien, lo que está pasando es que mi kernel sabe cómo montar una unidad IDE, pero no cómo montar una SCSI. Y puesto que he convertido la regrabadora CD-RW en SCSI mediante una emulación (que es imprescindible para poder grabar, dicho sea de paso)... Tonto, ¿verdad?.

La solución es sencilla. Hay un módulo del kernel que hace exactamente eso: decirle al kernel cómo debe montar una unidad SCSI de CD-ROM. Entra en "make menuconfig", vete a "SCSI" y ahí marca como módulo (o dentro del kernel, como prefieras) la opción "Support for SCSI CDRoms". Luego recompila. Ahí lo tienes. Eso crea un módulo que se llama "pr_mod". Basta con cargarlo para que puedas montar tu grabadora en "/dev/scd0". Compruébalo haciendo un "modprobe pr_mod" o bien mete pr_mod en tu fichero /etc/modules y ya está.

Y eso es todo. Es lo último que fallaba en mi kernel. Ahora todo cuanto podía hacer con el original de Debian, puedo hacerlo también con el mío. Quizás no de la misma forma, pero lo hace.

No será la última vez que lo recompile, pero a partir de ahora ya no será por necesidad, sino para mejorar el rendimiento. Y aquí finaliza también esta odisea, porque las próximas veces estaré sobre terreno conocido. :-)

Pero la sección no termina aquí. Hay muchas más cosas de las que hablar, y muchos pequeños trucos que pueden ayudaros a la hora de compilar vuestros kernel.

 

Mi unidad Iomega ZIP IDE se interpreta como SCSI

Decía antes que mi kernel puede hacer lo mismo que el de Debian, pero quizás de otra forma. ¿A qué me refería con esto?.

Pues uno de los problemas es que por algún motivo se cree que mi unidad Iomega ZIP 250 IDE interna no es IDE sino SCSI. No le he dado esa opción en ninguna parte, pero el kernel asume que debe manejarla bajo emulación SCSI, como si fuera una grabadora. ¿Por qué?. Misterios, pero el caso es que me fastidia bastante.

Porque al interpretarla como SCSI emulada, le asigna un dispositivo "/dev/sda". Fale, pero eso me confunde al Memorybird, que antes era "/dev/sda" y ahora pasa a ser "/dev/sdb". Por no hablar del Escáner, que es un SCSI auténtico. :-O

Total, que por culpa de esa chorrada, tengo que montar todos los dispositivos como root o haciendo uso de sudo, porque el /etc/fstab me cambia completamente. Hombre, puedo hacer una chapuza que cambie mis /etc/fstab dependiendo del kernel que arranque, pero es una chapuza muy poco ortodoxa. Lo ideal sería excluir a mi unidad Iomega ZIP de la emulación SCSI. Pero, ¿cómo se hace?.

Sabemos cómo se convierte una unidad IDE en una SCSI emulada. Basta con añadir las opciones que están en color cian en /etc/lilo.conf

	image=/vmlinuz.test
		label=Inestable
		read-only
		append="hdc=ide-scsi acpi=force"

Lo que quizás no sepas es que existe otra opción que sirve para que una unidad IDE no se emule como SCSI, que es justo lo que queremos:

	image=/vmlinuz.test
		label=Inestable
		read-only
		append="hdc=ide-scsi hdb=ide-floppy acpi=force"

¿Ves que fácil?. Solo con esto, mi kernel reorganiza sus unidades SCSI verdaderas y simuladas y quedan justo como están en el fstab. La salida de dmesg se limitará a decir que por opción del kernel, hdb es una unidad IDE removible.

 

Mi nuevo kernel no apaga el ordenador

Vale, este es un problema muy común. Compilas un kernel propio y no consigues que el muy puñetero te apague la máquina. Se queda como un tonto, parado, mostrando ese bonito mensaje que dice "Power off" al final. La leche, si prestas atención incluso oyes el "click" de las cabezas del disco duro al aparcarse... Pero no se apaga.

Si revisas un poco en Google, verás que es un problema bastante común. De hecho, encontrarás facilmente las soluciones más corrientes en la configuración de tu kernel: una es activar la opción "Use Real Mode APM BIOS call to power off" en "General Setup". Si esto no funciona, se puede añadir la opción "append='apm=power-off'" en /etc/lilo.conf.

Vale, pero a mí no me funcionaba con NADA. No había manera de que el ordenador se apagara. Y eso no aparecía en Google. :-?

Bueno, pues mi ordenador era un Pentium III, de hecho de los primeros que salieron. Resulta que mis problemas se solucionaron cambiando el tipo de procesador en la configuración del kernel. En vez de "Pentium-III/Celeron (Coppermine)", que es lo que tenía, seleccioné "586/K5/5x86/6x86/6x86MX Processor family". No he encontrado en Internet nadie al que le haya pasado lo mismo, así que aquí mismo lo publico.

Si tu ordenador es un Pentium III, y no consigues que ninguno de tus kernel recompilados apague la máquina, ya sabes...

 

APIC, ACPI, o APM

Hay tres conceptos confusos en los menús de configuración del kernel, y quizás te planteen problemas acerca de cual elegir. Por lo menos, a mí me los planteó. :-)

APIC	Significa "Advanced Programmable Interrupt Controller". Viene a ser un controlador de interrupciones, incorporado a la placa madre y diseñado por y para el multiproceso, concretamente para poder incorporar múltiples microprocesadores a la placa madre. Proporciona capacidad multiproceso, más IRQs y manejo más rápido de las interrupciones. Algunas placas madre soportan "Local APIC" a pesar de ser placas uniprocesador. La ventaja es un mejor (y más rápido) manejo de los IRQ.
APM	Significa "Advanced Power Manager", y viene a ser un mecanismo de gestión de la energía por parte de la BIOS. Es lo que hace que la pantalla o el disco duro se apaguen cuando llevan un tiempo determinado sin usarse.
ACPI	Significa "Advanced Configuration and Power Interface". Es como la APM, pero bastante más moderno. Es un estandar actualizado, a nivel de hardware, que controla el funcionamiento de la BIOS y proporciona mecanismos avanzados para la gestión de la energía. Va más allá de lo que podía la APM. Así, por ejemplo, convierte la pulsación del botón de apagado en un simple evento, de tal forma que cuando lo detecta, hace un apagado ordenado de la máquina y no una simple desconexión.

Como puedes observar, APM y ACPI son excluyentes. Es decir, o usas una u otra, pero no las dos a la vez. En cambio, cualquiera de ellas puede usarse con APIC sin problemas. Eso sí, si activas APIC en tu kernel, el ordenador nunca llegará a apagarse del todo, ni con APM ni con ACPI.

Mi placa madre soporta las tres cosas. Ciertamente, con APIC he notado una clara mejora del rendimiento. Bien, quizás no del rendimiento, como tal, pero la sensación que da es que el sistema es más ágil, que puedes cambiar de tarea con mucha facilidad. Entre APM y ACPI, no deberías dudar tanto: ACPI sin más.

 

Acelerar la compilación del kernel

Se puede conseguir que la compilación del kernel sea un poco más rápida con la opción "-j5". Esto hace que salten cinco tareas simultáneas (o las que tú quieras) colaborando entre sí para compilar lo mismo. Naturalmente, hay un precio a pagar por esta mayor rapidez: cada uno de esos procesos chupa sus correspondiente recursos del sistema (cpu, memoria...) con lo que el ordenador se vuelve más lento y pesado. Si pretendes hacer otras cosas mientras está compilando (como hago yo, que lo dejo todo funcionando en background), no te recomiendo que abras esta opción, o que al menos uses un número bajo. Con cinco, puede ser soportable. Con más, puede que la compilación se enlentezca (paradójicamente), si los procesos empiezan a robarse memoria y CPU unos a otros. Pero si vas a dejar la máquina compilando sola, esta opción te ahorrará tiempo. Por ejemplo:

	[13:05:22/0][root@claudia:/usr/src/linux]# make dep &&
	> make clean &&
	> make -j5 bzImage &&
	> make -j5 modules &&
	> make modules_install

 

Compilar un kernel de la serie 2.6

Compilar un kernel de la serie 2.6.x no tiene mucho misterio. Es incluso más fácil que los de la serie 2.4.x, especialmente porque se incorpora una nueva opcion: prueba el magnífico "make help". :-)

No voy a meterme mucho, porque todo esto se localiza facilmente en el Google, pero sí recordarte las diferencias y la secuencia de comandos. De nada. ;-)

Y luego instalar en /boot el kernel que se encontrará en arch/i386/boot/bzImage y el System.map que estará en /usr/src/linux. Y modificar Lilo, claro. Eso es igual en ambas series.

Por cierto, si puedes no dudes en probar la serie 2.6. Vale la pena, te lo aseguro. Para mi Debian Woody, en Claudia, ya es un poco tarde, pero para mi Fedora Core 1, en Lynette, incorpora funciones magníficas. La opción de "preemptive kernel" se hace valer, por ejemplo. Los 2.6 son el futuro, no lo olvides...