Serge Winitzki Contenidos: Introducción Primeros pasos hacia la instalación ¡A instalar Linux! La saga del vídeo La varidead es la gracia de Linux Compilando un nuevo kernel Últimos detalles Conexión vía módem a la GNU Apéndice: el Hardware Referencias

GNU/Linux en un Fujitsu 635T

Resumen:

Aquí explico cómo instalé una versión reciente del sistema operativo GNU/Linux desde cero en un ordenador portátil. La idea es que sirva como fuente de información para la gente que quiera instalar Linux en un ordenador portátil similar o incluso en un ordenador de sobremesa, y quizás tiene también algún interés para desarrolladores de distribuciones de Linux. La exposición es totalmente técnica, por lo que los lectores deberán tener amplios conocimientos del sistema operativo Linux (o al menos estar interesados en aprenderlo).

Introducción

Ésta es la segunda vez que instalo un sistema operativo GNU/Linux en un portátil. La primera vez fue con un LapNote P150 y está documentado aquí. He usado información del CDROM de Slackware, como los diferentes HOWTOs, la Guía de Instalación de Linux (Linux Installation Guide versión 3.2) y, naturalmente, la Linux on Laptops web page. Toda la información que sigue se refiere específicamente a la instalación de Slackware 3.5 en un Fujitsu 635T. No he proporcionado enlaces de Internet a programas específicos ya que asumo que el lector será capaz de encontrarlos mediante los sitios de referencia indicados.

Primeros pasos hacia la instalación

Compré un portátil de segunda mano, un Fujitsu 635T, por correo. Como ya me esperaba, el ordenador vino cargado con el llamado sistema operativo con "ventanas", versión "95 OSR 2". La instalación de "windows" había sido probablemente una "reinstalación limpia", hecha por el antiguo propietario antes de vendérmelo. La tarjeta de sonido no era reconocida, y todo el sistema PCMCIA parecía también ausente. No recuerdo ahora si el modo true-color funcionaba. Tampoco probé la opción "suspender a disco", ya que no había una partición para ello en el disco duro y pensé que no funcionaría y podría cargarme la partición existente. (Mis temores estaban infundados: la BIOS reconocía que no existía una partición para suspender a disco y mostró un aviso cuando intenté activar la opción).

Sabía que no era prudente sucumbir a la tentación de borrar "windows" directamente; necesitaba aún extraerle un par de cosas. Primero, instalé el driver de impresora "Generic Text" y usé el Panel de Control para imprimir todos los ajustes de sistema a un fichero, para posibles futuras referencias. Este fichero es quizás la única cosa útil que uno puede obtener de este llamado sistema operativo, ya que el ordenador venía sin manuales ("muchas gracias" al compra-venta de ordenadores, el sabe quién es). En principio, toda esta información debería estar contenida en los manuales de hardware; pero es una práctica de márqueting habitual considerar una instalación de "windows" equivalente a dar toda la información sobre el hardware. Esencialmente, obtienes una copia de "windows" presumiblemente bien instalada de la que puedes intentar extraer información.

Después de copiar el fichero con el resumen de hardware a un disquete, reboté y entré en el setup de la BIOS. La BIOS tiene un agradable interface y te deja controlar

Decidí no enredarme con este llamado sistema operativo nunca más

varios ajustes interesantes, como el número del puerto y de la IRQ de los puertos series y de la tarjeta de sonido, así como el modo del puerto paralelo, el control de energía, etc... También hay dos modos de funcionamiento del PCMCIA; el llamado "CardBus" y el modo "PCIC compatible". "Windows" puede reconocer el sistema PCMCIA en el modo "PCIC" pero no en el modo "CardBus" (como descubrí luego, los dos modos están plenamente soportados en Linux). El control de energía tampoco está soportado en "windows", y el botón de "Undock" prometido por el manual de usuario de la "docking station" tampoco estaba. Decidí no enredarme con este llamado sistema operativo nunca más. Pero aún no era la hora de borrarlo, ya que necesitaba crear un disco de arranque de Linux para cargar el SO Linux.

El primer paso era descubrir cómo crear los discos de arranque de Linux. Ya me había bajado la distribución de Slackware Linux 3.5 y hojeado los ficheros llamados README, INSTALL etc. Según el procedimiento recomendado, usé un programa de DOS llamado "rawrite.exe" que viene con Slackware para escribir las imágenes de los discos de arranque en los disquetes. El comando era algo así como: rawrite.exe bare.i a: ejecutado en el directorio bootdsks.144 del CDROM de Slackware, para hacer un disco de arranque con el kernel más simple ("bare"), y rawrite.exe color.gz a: en el directorio rootdisk para hacer el "rootdisk", que también es necesario para iniciar la instalación de Slackware. Más tarde me imaginé que podría haber usado el disco de inicio "bareapm.i", porque el portátil tiene funciones de "control de energía avanzado" (APM) y así podría haberlas usado durante la instalación inicial, esto es, podría haver suspendido el portátil en mitad de la instalación y continuarla más tarde. Pero al principio no quería usar nada más que el kernel más básico. Como resultado de usar un kernel que no soportaba APM, obtuve unas petadas extrañas cuando dejér el portátil durante una hora y entró en auto-suspend. La típica reacción era que programas aleatorios no se ejecutaban y daban un error de CPU "división por cero" con vuelco de los registros. Cosas como estas desaparecieron cuando empezé a usar el kernel con APM.

¡A instalar Linux!

Con los dos disquetes preparados, reboté el ordenador y obtuve un sistema Linux al que podía entrar como "root" sin contraseña. El mensaje de entrada me decía que ahora tenía que crear algunas particiones de disco para Linux y ejecutar el programa "setup" cuando las tuviera listas. El mismo mensaje me decía que podía usar tanto fdisk como cfdisk para hacer las particiones. Como yo sabía que fdisk no era muy fácil de usar, decidí probar con cfdisk y fui sorprendido por su simple e intuitivo interface en modo texto. Borré la partición FAT de 1.35 GB (adios, "windows") y creé una partición de 64MB para swap y dos (300 MB y 1 GB) particiones nativas de Linux (ext2). Pensé usar la partición más pequeña para ficheros de sistema y la más grande para ficheros de usuario y aplicaciones, por si luego decidía reinstalar Linux no tener que borrarlo todo.

Cuando acabé con cfdisk, inicié el programa setup. Los primeros pasos del setup fueron suficientemente claros: cambiar el teclado (no lo cambié), preparar el espacio de swap, elegir los directorios de origen y destino de la instalación.. Elegí la partición pequeña como partición root (/) y la partición grande que se montara en /usr. El primer problema vino con el directorio origen de la instalación: yo no tenía el CDROM original de Slackware, sinó que me había bajado todos los ficheros y los había grabado en un CDROM usando "windows". Probé varias veces, pero el setup no me reconocía los directorios que yo le daba como directorios

Para solucionar el problema, pulsé Ctrl-Alt-F2

con la distribución de Slackware. El problema era que yo había creado esos ficheros desde un sistema de ficheros de DOS y se habían añadido puntos a los nombres de ficheros, e.g. "README." en lugar de "readme", por lo que el setup tenía problemas con esto (no tube ningún problema similar con el CDROM de Slackware que recibí en el correo pocos días más tarde). Para solucionar el problema, pulsé Ctrl-Alt-F2; como ya sabía de mi experiencia previa con Linux, se usan las teclas desde Ctrl-Alt-F1 hasta F6 en modo texto para cambiar entre consolar virtuales. Obtuve otro mensaje de logín y entré de nuevo como root sin contraseña. Tener una segunda cónsola fue una bendición: estaban disponibles programas tan útiles como mount, ls, y cat, y fue posible montar el CD (sabía por la información de arranque de Slackware que la unidad de CDROM era /dev/hdc, por lo que los comandos para montarla eran mkdir /cdrom; mount /dev/hdc /cdrom), copiar los ficheros de Slackware desde el CD a una de las particiones y renombrar los ficheros que tenian el punto añadido. (Otra opción hubiera sido usar la unidad ZIP para acceder a los ficheros de instalación, pero el kernel "bare" no la soporta, y más tarde descubrí que los ficheros del driver ZIP para puerto paralelo que vienen con Slackware no funcionan en mi máquina, ver más abajo.) Después de esto, le dije al programa setup que "usara ficheros de un directorio ya montado" y Slackware pudo reconocer sus ficheros de instalación. Como podía cambiar a otra cónsola, pude también montar el CD con los ficheros de documentación de Slackware y leer los diversos README's, HOWTO's y obviamente la Installation Guide mientras se hacía la instalación. Poder solucionar los problemas del sistema mientras se configura me pareció muy útil. Pude ver qué sistemas de ficheros estaban montados en cada momento (cat /etc/mtab), montarlos o desmontarlos cuando era necesario (e. g. mount -t ext2 /dev/hda3 /mnt/usr), o hacer cualquier cambio a la situación de los ficheros. Pude entrar en una ventana paralela y ver lo que le ocurria al sistema. En fin, eso hizo la instalación más agradable, ya que no estaba sometido completamente a la merced del script de instalación.

El siguiente paso era elegir los paquetes de software que quería instalar. Elegí todos los paquetes excepto los juegos, el kit de desarrollo del servidor X y la documentación, que de todos modos ya estaba en el CDROM. Entonces el setup ofreció hacer el disco duro de arranque con el boot manager lilo. Elegí la "instalación de lilo automática" usando el kernel bareapm.i. Me salté la configuración de la red, no elegí ninguna fuente especial, le dije que mi modem estaba en COM2, mi ratón era PS/2, y que mi zona horaria era Amsterdam. (¿Por qué no han hecho que funcione PageDown para moverse rápidamente por esa enorme lista de zonas horarias?). Finalmente, reinicié y el sistema se puso en marcha correctamente. Entré de nuevo como root sin contraseña y ya estaba listo, con una potencia computacional de 53 "BogoMips". Más o menos era correcto para un Pentium 133 Mhz (como se indica en el "BogoMips mini-HowTo").

La única mancha era que no podía reconoce la unidad ZIP en el puerto paralelo. El driver (ppa, adaptador de puerto paralelo) decía esencialmente que no

El nuevo driver, "Curtin" version 1.42, autodetecta todo sobre los puertos paralelos correctamente y usa un modo de acceso más rápido con mi puerto paralelo ECP.

había un adaptador de puerto paralelo en el puerto 0x278 (el mensaje era difícil de entender, modprobe ppa decía algo como "init_module: device or resource busy" como línea inicial del mensaje de error). Reinicié y me fui al setup de la BIOS: el puerto paralelo estaba puesto en 0x378. Bien, ¿quizás necesita 0x278? Lo puse en 0x278, cambié al modo de puerto paralelo bidireccional simple, por si acaso, y reinicié de nuevo. Esta vez el driver del puerto paralelo me dijo que no podía encontrar la unidad ZIP en el puerto 0x378. Esto empezaba a parecerse al juego del perro y el gato: ¿por qué el adaptador se negaba a mirar en el puerto correcto? El problema desapareció cuando compilé una versión más reciente del driver del ZIP en puerto paralelo (mira la información importante en la página Linux Laptop web page). El nuevo driver, "Curtin" version 1.42, autodetecta todo sobre los puertos paralelos correctamente y usa un modo de acceso más rápido con mi puerto paralelo ECP.

También traté de modificar a mano el fichero de configuración de lilo, pero encontré que usar el programa liloconfig es más seguro, sobre todo porque olvidé ejecutar lilo después de cambiar la configuración.

Comentarios finales: a veces hay mensajes de error después de hacer algunas de las funciones del setup, pero estos mensajes se pierden inmediatamente cuando se muestra la siguiente panatalla. Me gustaría que los mensajes de error estuvieran disponibles para poder ver si los procedimientos del setup han sido correctos. Quizás esto requiera más trabajo en los scripts, pero no mucho más: por lo menos la salida de los comandos se puede redireccionar para mostrarse cuando se pida. (Hola, Mr. Volkerding, quizás me oigas.)

La Saga del Video

Anticipo que el mayor problema fue configurar el sistema X window para funcionar con mi adaptador gráfico y la pantalla LCD de 800x600. Pero el proceso completo no fue tan costoso; básicamente funcionó solo, sólo me dio problemas el modo de color verdadero.

La distribución de Slackware de Linux viene con XFree86, un servidor de X gratuíto y de gran calidad que prometía suportar plenamente mi chip gráfico. Yo pensaba utilizar Accelerated X pero me decidí en contra porque XFree86 es más configurable y había tenido una mejor experiencia con mi antiguo portátil, menos soportado. Existen dos alternativas para configurar XFree86: el programa de configuración basado en X y el basado en modo texto. El único ratón que tenía era el touchpad algo gastado y voluminoso, por lo que opté por la configuración en modo texto (el interface era un poco cutrecillo pero funcionaba bien). Más tarde descubrí que el interface gráfico no hubiera funcionado en este punto porque es incompatible con gpm, el driver del ratón en modo texto que había seleccionado que se instalase y activase. Matándolo con gpm -k ayudó, pero la configuración gráfica no es realmente tan útil y requiere ratón.

El adaptador gráfico, C&T 65550 con 2MB de memoria, estaba en la lista y seleccioné los modos de 800x600 en todas las profundidades de color. El único problema fue cuando a mitad de la configuración se me ofreció ejecutar X -probeonly para detectar los modos de vídeo viables, pero falló porque en este punto la instalación todavía no había escrito suficiente información en los ficheros de inicialización. Por lo que me salté este paso y seguí adelante a por más preguntas. También ignoré las preguntas sobre las características del monitor (como rangos admisibles de frecuencias de refresco horixontales y verticales); de mi experiencia previa, esta información nunca es necesaria

Este fichero (XF86Config) normalmente está lleno de líneas inútiles insertadas automáticamente por el programa de configuración.

ni suficiente para configuraciones exitosas. Simplemente seleccioné el "generic multisync SVGA monitor" (¿por qué no aparece ninguna pantalla de portátil en la lista?).

Después de acabar todo el proceso de configuración, miré el fichero principal de configuración del hardware de vídeo /etc/X11/XF86Config. Este fichero normalmente está lleno de líneas inútiles insertadas automáticamente por el programa de configuración. La parte más importante en cuanto a hardware se refiere es la llamada sección "Modelines". Cada línea describe un modo de vídeo concreto, correspondiente a una resolución de pantalla, frecuencias de refresco, etc. Cada modo tiene un nombre, y el fichero de configuración se refiere más tarde a los modos por dicho nombre, cuando se le indica al servidor qué modos usar en cada una de las profundidades de color (en la sección Screen del fichero). Si se les da el mismo nombre a varios modos, el servidor solo usará uno de ellos, el que tenga "mejor" frecuencia de refresco y, por lo tanto, calidad de imagen. Por mi experiencia previa configurando el servidor XFree86, conocía el problema con la configuración automática: inserta demasiadas líneas con la misma resolución y las nombra con el mismo nombre, como 640x480 o 800x600, dejando que el servidor elija el "mejor" modo para el monitor dado. Pero puede que uno solo de los modos llamados, por ejemplo 800x600, funcione. Lo que ocurre en la práctica es que el servidor elije el mejor modo, pero por lo que sea no funciona y deja al usuario sin salida. Es mejor renombrar estos modos con nombres difrentes, como 800x600a, 800x600b etc, y dejar que el servidor los use todos. El usuario puede entonces pulsar Ctrl Alt + y Ctrl Alt - para cambiar entre todos los modos disponibles y seleccionar el que mejor se vea.

Por lo cual borré todos los modos excepto los de 800x600, los renombré, los incluí en la sección Screen, y tecleé startx para iniciar el sistema X window. Mi mejor línea fue:

# 800x600 @ 60 Hz, 37.8 kHz hsync
Modeline "800x600a" 40 800 840 968 1056 600 601 605 628 +hsync +vsync

Otra era similar a 56 Hz con casi la misma calidad de imagen. Obtuve una bonita imagen a resolución completa. Sin embargo, no había ningún controlador de ventanas visible. Además el modo de color verdadero no funcionaba. (El modo de color verdadero se inicia con startx -- -bpp 24 ya que en mi chip el modo de color verdadero correcto no es de 32 bits, sinó de 24 bits por píxel, esto es, 24 bpp; el X configurator omite correctamente los ajustes de 32 bits en la sección Screen y también usa por defecto la profundidad de 8bpp.) Ejecuté X con la salida redirigida (startx >& /tmp/startx-output) y miré en el fichero resultante. Esta técnica es muy útil para diagnosticar los problemas de configuración de X, ya que de otro modo los mensajes se desplazan rápidamente fuera de la pantalla.

El problema con el manejador de ventanas que no aparecía era debido a que la variable DISPLAY, por alguna razón, no estaba definida. Esa variable de entorno es necesaria para que todos los programas sepan dónde mostrar sus ventanas. Lo arreglé editando el script startx script (ver más abajo).

El problema del modo de color verdader era que X se quejaba de que el "pixel clock" era demasiado alto en dichos modos. Aparentemente es una limitación real del hardware en el pixel clock. Durante algún tiempo pensé que nunca obtendría el modo de color verdadero, pero un día miré las líneas de modo de otra gente con adaptadores C&T (de un montón de información que encontré en Linux on Laptops web page) y descubrí la siguiente línea con frecuencia de reloj inferior:

#800x600 @ 49.5 Hz vsync, 30 kHz hsync, yucky and flickery even on LCD
ModeLine "800x600b" 28.3 800 816 856 920 600 603 605 618

Este modo tiene una frecuencia de refresco muy baja y una pobre calidad de imagen; cuando la activé, el monitor zumbaba notablemente mientras me lloraban los ojos. Las pantallas LCD dan mejor calidad de imagen que las CRT y normalmente la imagen es aceptable a unos 56 Hz de frecuencia vertical (que sólo sería una terrible pesadilla para los ojos en un tubo típico de 14 pulgadas) pero esto no era nada bueno. No supe lo que hacía pero incrementé la frecuencia a 35.1 en lugar de 28.3 sin cambiar los otros números. El modo funcionó entonces mucho mejor. Probé entonces a cambiar la frecuencia de reloj por 35.4 en la antigua línea y funcionó también. Ahora la estoy usando (en color verdadero) para escribir esto. También he añadido la línea DefaultColorDepth 24 a la sección Screen del fichero XF86Config, para que el modo de color verdadero sea el modo por defecto. Recordaba que había una manera de usar una profundidad de color concreta por defecto, pero tube que mirar los manuales de X para encontrar la palabra exacta: "DefaultColorDepth", ya que el script de configuración de X no puso ningun ejemplo en el fichero.

Para hacer que X aceptara el modo de prueba de 28.3, tube que cambiar el rango de frecuencias permitidas por el monitor. El configurator puso estos rangos:

HorizSync 31.5 - 37.9
VertRefresh 50 - 90
    

Tube que hacer dos toques finales: añadí la línea TextClockFreq 40 al fichero XF86Config para restaurar la frecuencia de texto correcta cuando cambio de una sesión X a una cónsola de texto; y modifiqué el script startx (/usr/X11R6/bin/startx) para mantener la cónsola virtual accesible y poner valor a la variable de entorno DISPLAY (se supone que de esta variable se encarga el controlador de ventanas, fvwm2, pero no parecía funcionar). La parte final del script quedó como:

export DISPLAY=":0.0"
exec xinit $clientargs -- $serverargs >& /tmp/xinit.out &
    

La seguna línea redirecciona toda la salida de la consola de X a un fichero en el directorio temporal, para poder ser examinado si es necesario, y pone todo el proceso de X window en un segundo plano.

La variedad es la gracia de Linux

El sistema estaba listo, pero tenía la impresión que me estaba perdiendo la diversión: tenía dos de las últimas distribuciones semicomerciales, RedHat 5.1 y SuSE 5.2, las dos me prometían facilidad de instalación y configuración, y en su lugar estaba usando la distribución pelada para los hackers, Slackware. Por lo cual decidí probar las alternativas.

SuSE 5.2, con todas sus proclamadas virtudes, nunca arrancó en mi portátil. Preparé los discos de arranque usando mi instalación de Slackware, con el comando dd if=/cdrom/disks/eide01 of=/dev/fd0. Ninguno de los discos de arranque IDE (eide01 a eide03) fue más lejos que mostrar el mensaje "Loading Linux..." (con tres puntos), quizás por un conflicto de memoria, o algo así. He oído de gente que dice que a veces los discos de arranque petan y entonces se necesita jugar con el caché de memoria, o seleccionar diferentes kernels, pero 1) ninguno de los kernels

SuSE 5.2, con todas sus proclamadas virtudes, nunca arrancó en mi portátil.

funcionó, mientras que el setup de la BIOS no me deja cambiar el caché de memoria y 2) ¿por qué me tengo que preocupar si los discos de arranque de Slackware funcionan perfectamente?. Por ello abandoné SuSE. Debo decir también (a pesar de que el inglés no es mi idioma nativo) que sigo pensando que los mensajes de SuSE (en inglés) parecen una mala traducción del alemán.

En cuanto a RedHat 5.1, sentía curiosidad, ya que mi experiencia previa con RedHat fue con la versión 4.2 y había oído que se habían mejorado muchas cosas. El script de instalación era estupendo, sólo tuve que hacer un disco de arranque que funcionó perfectamente y me llevó a la instalación en un momento. El zip de puerto paralelo se detectó bien como "/dev/sda", pero como no lo tenía que usar para la instalación, fue más una molestia; en concreto, no se podiía iniciar fdisk porque decía que "no podía acceder al dispositivo por defecto /dev/sda". Durante el setup tuve una cónsola libre paralela que ya estaba ejecutando bash, y dos consolas para el log de errores (Ctrl-Alt-F3 y F4) para monitorizar el progreso del script. Cuando llegó el momento de seleccionar los paquetes concretos de software a instalar, pude ver cuánto espacio era necesario para cada uno de los componentes, a diferencia que en el script de Slackware. Pero no fue tampoco algo crucial, ya que el espacio total requerido estaba por debajo de los 400MB y yo tenía más del doble de espacio libre en la partición de /usr.

Llegé entonces a la configuración de X, que transcurrió más o menos sin problemas. El fichero /etc/X11/XF86Config resultante de la configuración era algo menos adecuado para mi hardware, ya que no disponía del modo de color verdadero de 24bpp; en su lugar debería haber tirado el modo de 32bpp. Pero yo ya sabía qué modos funcionaban y no fue tan malo después de todo. Mi adaptador gráfico (C&T) fue identificado correctamente. Inicié X sin problemas (excepto que la terminal X usaba texto blanco sobre fondo negro, cosa que a mí no me gusta) y, sólo por probar, intenté iniciar el glorioso rpm ("RedHat package manager", la herramienta que usan para controlar la instalación y desinstalación de software) para instalar el nuevo Ghostscript 5.10 desde el directorio redhat/contrib. Debía ser una cosa deliciosa, pensé, uno sólo debe escribir un comando intuitivo: rpm -i packagename.rpm en lugar del tedioso y críptico tar zxf packagename.tgz, ¿no? Oops... obtuve un mensaje del rpm diciendo que era necesario otro paquete para instalar Ghostscript, algo así como "ghostscript-fonts-standard", y no encontré por ningún lado ese paquete. Encontré otros paquetes de fuentes de Ghostscript, pero no ese. Había visto algo parecido otra vez: recuerdo el rpm diciéndome una vez (bajo RedHat 4.2) que "no tenía el paquete /bin/sh en mi sistema"; /bin/sh es la shell, ¿cómo estaba picando esos comandos sin ella?. Me gustaría oirle decir que falta la placa madre. Típica "locura del rpm", pensé, y lo dejé estar. En general, el sistema parecía funcionar más lento que con la instalación de Slackware de, esencialmente, los mismos componentes.

Entonces probé la herramienta de configuración del sistema linuxconf, llamada "el mejor amigo de los administradores de sistemas". Desgraciadamente, no fui capaz de entender qué es lo que iban a cambiar cada uno de sus desconectados widgets en mi sistema; algunas veces era obvio pero otras era totalmente críptico. La principal tarea para mi es entender la configuración de sistemas y ser capaz de resolver problemas basándome en este conocimiento; sospecho que RedHat y quizás otros seguidores de la doctrina "hazlo-fácil" están tratando de hacer la administración de sistemas "fácil" no ocultando los detalles triviales, sinó haciendo que el administrador ejecute programas que ellos proporcionan y que nunca configure nada a mano.

Otra cosa: aunque detectó la unidad de ZIP, el acceso are terríblemente lento porque el driver que usaban era una versión beta muy antigua que sólo soportaba el modo de acceso más lento, por lo que necesitaba recompilar el driver (y posiblemente el kernel) de cualquier modo. Encontré algunos otros problemas tratando de instalar los fuentes del kernel, no recuerdo lo que fue. Por estas consideraciones y por el miedo a la "locura del rpm", decidí abandonar RedHat y volver al viejo Slackware. Reboté con los discos de Slackware que todavía tenía, repetí la instalación con las cosas que ya sabía y pronto el sistema estaba listo y funcionando de nuevo.

Compilando un nuevo kernel

En el centro de un sistema Linux está el kernel, y yo sabía que debe contener soporte para todos los diversos dispositivos periféricos conectados al sistema, desde el ratón hasta la tarjeta de sonido, pasando por la unidad ZIP de puerto paralelo y la unidad CDROM SCSI externa. También sabía que el kernel puede soportar estos dispositivos de una manera modular, esto es, cargando los drivers bajo demanda y descargándolos más tarde. Esto hace que el kernel sea más pequeño y más flexible, ya que en principio puedes entonces cargar y descargar drivers para dispositivos incompatibles cuando sea necesario. Por ejemplo, el driver de la impresora puede no ser compatible con la unidad de ZIP de puerto paralelo, en cuyo caso sólo podré tener cargado uno de los dos drivers.

El kernel que viene con una distribución de Linux estándar incluye soporte para algunos dispositivos básicos, incluyendo algunos que no tenía intención de tener nunca; los drivers para estos dispositivos simplemente están en memoria y no hacen nada. Es mejor compilar un kernel a medida que soporte justo el ordenador en el que va a correr.

Con esto en mente empezé a configurar y compilar el kernel a medida para mi ordenador. Como elegí instalar los fuentes completos del kernel (versión 2.0.34) cuando instalé Slackware, recompilar el kernel fue muy fácil. Cambié al directorio /usr/src/linux y tecleé make menuconfig para iniciar el script de configuración del kernel en modo texto. Después de breves instantes, me apareció una caja de diálogo muy agradable con las diferentes opciones del kernel. Cada opción está muy bien comentada y fui capaz de mirarlas todas en muy poco tiempo. Entré todo lo que pude, hasta llegar a la tarjeta de sonido (una "ESS AudioDrive") que no aparecía en la lista, pero descubrí mirando en los READMEs que es una clónica SoundBlaster (aunque no está listada explícitamente como SoundBlaster, debería estarlo). Elegí que todos los drivers de dispositivos periféricos se compilaran como módulos; los dispositivos incluían el control de energía ("APM"), la tarjeta compatible SoundBlaster, un ratón PS/2, los puertos serie, la unidad de disquetes, el cdrom, y soporte para disco SCSI (para mi disco ZIP). Hize también módulos para varias cosas de redes, como SLIP y PPP, y para los formatos de ejecutables a.out, ELF y java (por si los necesitaba). Compilé por separado los módulos de sistema de ficheros Macintosh (hfs), que necesito para trabajar con discos ZIP compatibles SGI, y el soporte actualizado para la unidad ZIP de puerto paralelo (esto no viene con el kernel estándar, pero yo lo necesito). Me bajé también el último paquete de PCMCIA (pcmcia-cs-3.0.4) y compilé los módulos de soporte de la tarjeta SCSI y de la tarjeta de red.

Entonces tecleé make dep; make zlilo; make modules; make modules_install y esperé unos 15 minutos. Cuando todo acabó, el nuevo kernel y los nuevos módulos estaban compilados y situados en su localización correcta. Comprobé que el fichero del kernel /vmlinuz era más nuevo y pequeño que el antiguo, grabado como /vmlinuz.old, y reinicié... sólo para comprobar que la máquina ya no arrancaba, parando incluso antes de que se monte ningún sistema de ficheros. La secuencia normal de mensajes de arranque se paraba después de comprobar las particiones en VFS: mounted root (ext2 filesystem) readonly. Ningún sistema de ficheros se montaba como lectura-escritura y ningún script de inicialización (iniciados por INIT) se ejecutaba. Glups.

Después de reiniciar con el disco de arranque de Slackware que tenía el viejo kernel, devolví la vida al sistema, y empezé a mirar por la configuración del kernel y a pensar qué es lo que estaba mal en el nuevo kernel. Pronto lo encontré: estaba tan empeñado en la idea de hacerlo todo modular que había cometido el estúpido error de compilar el soporte para todos los formatos de ejecutables (i.e. a.out, ELF y java) como módulos. El kernel y todos los programas se compilan como ELF. Así pues, cuando el kernel se inicia, no podía ejecutar los programas a no ser que cargue el módulo para el formato ELF, pero para cargar el módulo necesita ejecutar el programa insmod, que está en formato ELF. La manera correcta es compilar el soporte para ELF dentro del kernel, no como módulo. Es una cosa natural, ya que la mayoría de programas de hoy en día están compilados como ELF. Después de recompilar el kernel con este simple cambio, pude reiniciar sin ningún problema.

Entonces me fui al directorio /lib/modules y borré todos los módulos más antiguos que los recién compilados. Esto eliminó los mensajes sobre módulos incompatibles al arrancar. También edité el script de inicialización /etc/rc.d/rc.S para habilitar kerneld, el "daemon" que carga y descarga módulos automáticamente. Con kerneld no es necesario cargar y descargar los módulos del kernel a mano usando insmod y rmmod (auqne también se puede hacer). El comando lsmod lista todos los modules cargados actualmente por el kernel.

kerneld funcinaba perfectamente, cargando los módulos cuando se necesitaban y descargándolos cuando no se habían utilizado durante un rato. Tube que añadir la línea alias scsi_hostadapter ppa al fichero /etc/conf.modules para que el módulo de puerto paralelo ppa se cargara automáticamente cuando yo intentara montar un disco ZIP (/dev/sda). Esto lo tendría que cambiar si usase una tarjeta SCSI en lugar del adaptador del puerto paralelo.

Últimos detalles

Algunos pequeñas cosillas de configuración quedaban después de recompilar el nuevo kernel. Eran: configurar el acceso a dispositvos de almacenamiento externo (la disquetera, el CDROM y la unidad ZIP), soportar dos ratones a la vez, soportar el idioma ruso y configurar el controlador de ventanas fvwm2.

El script de instalación de Slackware había creado el directorio /mnt bajo el cual puso los subdirectorios /mnt/floppy y /mnt/cdrom para montar los sistemas de ficheros de los disquetes y del CDROM. Al principio decidí que tenerlos en un directorio separado no era tan conveniente, y creé los directorios /floppy y /cdrom en el directorio raíz. Pero luego me di cuenta que necesitaba más directorios para montar dispositivos con diferentes opciones, y en lugar de tenerlos todos en el directorio raíz, volví a crear el árbol /mnt.

También cambié las opciones de montado en /etc/fstab. Después de la instalación este fichero contenía opciones por defecto bastante razonables, pero no eran suficientes para mis necesidades. Primero, hice las líneas para la disquetera, el CDROM y el ZIP; tuve que deshabilitar la opción de montado automático y permitir a todos los usuarios montarlos (la opción user):

/dev/fd0   /mnt/floppy	vfat	user,noauto,noexec,nonumtail  0 0
/dev/sda4  /mnt/zip	vfat	user,noauto,noexec,nonumtail  0 0
/dev/hdc  /mnt/cdrom	iso9660	user,noauto,noexec	      0 0

Atención a la opción noexec para sistemas de ficheros DOS: hace que los ficheros de esta unidad no sean ejecutables, que probablemente sea algo razonable. La opción nonumtail previene la creación de nombres feos: el fichero longname.file se llamará longname.fil en lugar de longna~1.fil, si no hay conflictos de nombres. El sistema de ficheros vfat soporta nombres largos de manera compatible con DOS, al contrario que el viejo tipo msdos, por qué no usarlo, pues.

El paquete mtools me dio algunos problemas: o le das permisos de lectura/escritura a /dev/fd0 o solo el superuser puede leer y escribir al disquete. Poniéndole el bit setuid al fichero mtools no hizo nada. Decidí que montaría los dispositivos a mano.

La historia con el ratón fue relativamente sencilla porque ya la sufrí cuando configuraba mi anterior portátil. El portátil lleva un touchpad incorporado (que técnicamente es un ratón PS/2), y yo quería usar también un ratón externo conectado al puerto serie. Los dos ratones se pueden soportar simultáneamente usando el programa gpm ("general purpose mouse"). El programa sirve para dos cosas: primero, en cónsolas de texto habilitar el uso del ratón como puntero (en

Los dos ratones se pueden soportar simultáneamente usando el programa gpm ("general purpose mouse")

aplicaciones que lo soporten) así como proporcionar funciones de cortar y pegar; segundo, gpm puede unir dos ratones diferentes (que pueden ser cualesquiera, como bus mouse, PS/2, serie u otros) en un puntero lógico único. Todo lo que se necesita es una línea de comandos concreta. La sintaxis es un poco rara pero hay explicaciones claras y ejemplos en la página del manual (man gpm). El programa gpm se inicia en el script de inicialización /etc/rc.d/rc.local, ya que ya le había dicho a Slackware que lo instalé y activé. Modifiqué la línea del gpm en ese fichero para que quede así:

gpm -t ps2 -m /dev/psaux -2 -M -t mman -m /dev/cua0 -3 -R 

Esto se interpreta como: el primer ratón es del tipo PS/2 en el puerto auxiliar, tiene dos botones; el segundo ratón (-M) es del tipo [Logitech] MouseMan, conectado el puerto serie 1 (/dev/cua0), tiene tres botones y -R significa que ambos ratones deben estar disponibles para las sesiones de X como un solo ratón. (La opción -R no es necesaria si se usa la versión gpm 1.14 o posterior.) Después de modificar esta línea, maté y reinicié gpm (gpm -k; /etc/rc.d/rc.local) y entonces los dos ratones funcionaron inmediatamente y sin problemas. Podía incluso enchufar el ratón serie mientras ya estaba trabajando en X y voilá, funcionaba directamente. Estas cosas sin imposibles en el llamado sistema operativo "windows": siempre te dice que reinicies el ordenador para que el "nuevo hardware" funcione.

Lo siguiente que me ocupó fue instalar el soporte para caractéres Cirílicos. Tenía que ser capaz de leer, y ocasionalmente escribir, texto ruso. Instalé soporte para cirílico solo en X. Esto consiste en dos partes: conseguir las fuentes cirílicas y conseguir la distribución cirílica del teclado. Hay varias páginas en la red que explican todos los detalles de la "cirilización del Unix". Slackware proporciona un conjunto de fuentes KOI-8. El "Cyrillic How-To" hace referencia a la colección VakuFonts creada por Serge Vakulenko (vak@kiae.su). Se puede encontrar en la colección de cosas de cirílico para el X Window System. Me bajé dos paquetes que proporcionan fuentes idénticas en los códigos KOI-8 y CP-1251 (o "Windows"), desempaqueté los ficheros de fuentes (*.pcf.gz) en los subdirectorios koi8-r y x-cp1251 del directorio principal de fuentes de X window /usr/X11R6/lib/X11R6/fonts/ (que en mi sistema Slackware se accede más fácil por el link /etc/X11/fonts). Entonces instalé las fuentes añadiendo estos dos subdirectorios al "FontPath" en el fichero /etc/X11/XF86Config. Después de esto, reinicié X window y todas las fuentes estaban disponibles, por lo que pude configurar Netscape (usaba la versión 4.05) para usar automáticamente estas fuentes para los códigos correspondientes koi8-r y x-cp1251.

Ahora necestiba un driver de teclado ruso. Usé el programa xrus, que es simple y no intrusivo. Lo encontré en Moshkow's Library, the page on Cyrillization y después de modificar su fichero de recursos /etc/X11/app-defaults/Xrus y su disposición del teclado según mis conocimientos de la máquina de escribr rusa :) me sentí cómodo escribiendo en ruso.

El paso final era instalar algunos programas para convertir ficheros entre los dos códigos rusos. Usé un script hecho en casa muy básico que llamé 323. Puede convertir entre CP866 ("DOS" o "alternativo"), KOI-8, CP1251 ("Windows"), y códigos de Macintosh. Creé hard links a 323 llamados koi2win, alt2mac etc (ln 323 koi2win etc.) y el script automáticamente determina qué hacer basándose en su nombre. Usando este script y las fuentes instaladas uno puede leer la mayor parte de textos en ruso.

Todo estaba listo en X window system, excepto el controlador de ventanas fvwm2. Todos sus ajustes están controlados por un simple fichero de recursos ~/.fvwm2rc o (si este fichero no existe) por el fichero para todo el sistema /etc/X11/fvwm2/system.fvwm2rc. Vi que el fichero proporcionado por Slackware tenía muchas cosas comentadas que no eran muy útiles o no funcionaban. Las cosas básicas que yo quería del controlador de ventanas eran: mostrar algunos botones para llamar un pequeño número de programas muy útiles; responder al teclado y al ratón en operaciones con ventanas, como mover y mostrar ventanas; y mostar un menú con todas las aplicaciones de X window instaladas. Idealmente todo debería ser accesible desde el teclado sin usar el ratón.

Empezé con el fichero de recursos porporcionado y lo edité muchas veces, leyendo la larga y a veces densa página del manual (man fvwm2) para descubrir cómo se llamaban las diversas funciones, añadiendo cambios poco a poco. En particular, estaba interesado en hacer que las teclas de "Windows 95" sean útiles para algunas cosas. El resultado está aquí, con, espero, suficientes comentarios para ver cómo funciona.

Conexión vía módem a la GNU

El acceso por módem a mi proveedor local de red estuvo en marcha y funcionando en tan poco tiempo que me quedé alucinado. Después de leer los manuales de configuración de PPP, algo complicados y con aspecto antiguo, incluyendo la "Guía de Instalación", tenía la impresión que instalar PPP era un poco complicado. Sin embargo, probando al azar los comandos que empezaban con ppp descubrí que Slackware incluye un script llamado pppsetup que me preguntó las cosas correctas sobre mi módem y mi proveedor de PPP. No sabía una de las respuestas: si el "protocolo de autentificación" era "PAP", "CHAP", o "CHAP-Microsoft". Elegí (al azar) "CHAP" y seguí con la configuración. Pronto todo estuvo listo, y me dijo que usara dos comandos autoexplicativos, ppp-go y ppp-off para controlar la conexión PPP, y también había un texto detallado, /etc/ppp/pppsetup.txt, que describía todo lo que se le había hecho al sistema durante la ejecución de pppsetup. En este fichero, me decía que ejecutara ifconfig para ver si la conexión PPP se había establecido correctamente, y también me indicaba la existencia de los ficheros de log /var/log/messages y /var/log/debug en caso que tubiera problemas (ya que la opción de debug del fichero de opciones de PPP /etc/ppp/options estaba activada por defecto; más tarde la desactivé ya que el fichero de debug se estaba llenando con la información, ahora inútil, de los mensajes de pppd).

Todo parecía de color de rosa, pero cuando conecte el módem a la línea telefónica, el comando ppp-go no parecía crear una conexión. El fichero /var/log/debug contenía muchos mensajes; miré hacia el final del fichero y encontré un intercambio no exitoso entre el pppd y el host remoto. Uno de los mensajes recibidos del host remoto decía <auth pap>. Ajá, dije. Debería haber elegido autentificación "PAP" en lugar de "CHAP". Rehice el comando pppsetup y la conexión PPP estuvo funcionando en un momento. Como nota, decir que el comando pppscript contiene algunas funciones que hacen grep's de los ficheros de log del sistema e imprimen mensajes tales como "Parece que quieren PAP...", y cosas así, pero por alguna razón estas funciones están comentadas. ¿Existe alguna versión mejor de pppsetup?, ¿quizás su desarrollo no está finalizado?

A pesar de que ahora PPP funciona bien y puedo usar programas como fetchmail, ncftp, Pine, netscape y otros maravillos programas sin problemas, no estoy completamente satisfecho con la configuración. Me gustaría que el proceso de llamada sea más controlable y los mensajes de error que produzca, si los produce, sean visibles al usuario. En el caso en que la conexión se rompa por alguna razón, me gustaría que hubiera algún método para saberlo, sin entrar como root y mirar los logs del sistema. Quizás los Linux más comerciales vengan con utilidades para hacer conexiones PPP más amigables para el usuario (¿quizás gppp?), pero seguro que esas utilidades necesitan un montón de cosas oscuras para poderse instalar o no funcionan si no es en su ambiente nativo. Algún día instalaré una utilidad más amigable o aprenderé Perl/Tk y la escribiré yo mismo. O me cambiaré a RedHat, cuando su controlador de escritorio orientado a objetos GNOME esté maduro.

Otra cosilla del PPP es que el script ppp-go debe ser iniciado por el superuser. Al principio pensé poner llamada bajo demanda, pero el kernel, por alguna razón, no contenía una versión del driver PPP (2.3) que soportara esta función. Entonces escarbé entre los archivos de red y encontré un pequeño programa en C, "ppp para mortales", que básicamente llama a la función setuid(0) para hacerse root y entonces ejecuta el script ppp-go. La compilé y la instalé en el path con el bit de setuid a 1 (chmod 4755 ppp_for_mortals). Después de esto, pude ejecutar este programa como usuario para iniciar o parar la conexión PPP.

Apéndice: el Hardware