7.2 ROMs para arranque sin discos

Llegados a estas páginas habrá de comprenderse que al carecer de discos, los nodos diskless deben disponer de lo necesario para su arranque en otra computadora, y en el tipo de sistemas que aquí se detallan esta información estará organizada en un -o varios- nodos servidores.

Esta sección no cubre el procedimiento de configuración de los servicios, que debe haberse visto durante la lectura de la anterior. Aquí se trata la necesidad de aportar al cliente ciertos paquetes de información -en forma de roms- para que sea capaz de cumplir con su parte en el diálogo de comunicación que finalizará con su arranque. Cabe insistir una vez más que el cliente en ningún momento se percata de que no tiene un sistema operativo instalado en un disco local, la transparencia a este nivel la otorga el propio linux.

Haciendo memoria. El cliente -como cualquier otra computadora- arrancará su BIOS al ser alimentado. Tras la detección de memoria y también su tarjeta de red se producirá la interrupción de BIOS INT 19H que dirigirá su esfuerzo en encontrar información que le permita arrancar a través del nic instalado. En este momento es cuando el servidor debe estar atento para prestar la primera rom, correspondiente al servicio RPL^7.12.

La segunda rom es necesaria durante la puesta en marcha del tercer servcio, el TFTP. Se utilizará este protocolo para descargar y arrancar un kernel desdel servidor, pero este kernel debe estar modificado -no sirve directamente un fichero bzImage, resultado de una compilación con make bzImage-.

Arranque del cliente desde chip EPROM

Los pasos necesarios para este proceso son los siguientes:

• comprobar que la tarjeta de red dispone de socket para inserirle un chip; será el señal que confirma que soporta arranque por RPL.
• en el caso de no querer situar la rom de RPL en un servidor será necesario adquirir un chip bootp rom compatible con la tarjeta. Lo proporciona el fabricante.
• generar una imagen ROM válida con el modelo de tarjeta.
• quemar dicha imagen en el chip -si usamos esta opción- o situarla en el servidor y configurar el servicio.
• generar una tagged image del kenel para poder arrancarla con la ROM, situarla en el servidor y configurar el servicio.

Lo que tiene que entenderse en el tercer punto es que la rom contiene diferencias para cada tarjeta, o mejor dicho, para cada chipset de tarjeta de red. Así pues es aconsejable realizar pruebas con esta misma imagen grabada en un disquete, para no tener que sustituir diversas veces el contenido de nuestro chip (algo sin duda más engorroso que borrar y grabar un disquete).

Arranque del cliente desde disquete

El arranque realmente no difiere en exceso, puesto que podemos verlo simplemente como una diferente ubicación de las instrucciones necesarias -en disquete en vez de en chip o en el servidor- para arrancar nuestro nodo cliente.

En efecto, cabe elogiar el trabajo de la gente del proyecto Etherboot por poner a nuestro alcance un sistema tan práctico para hacer nuestras primeras configuraciones: poner la imagen en un disquete.

La ventaja que esto aporta es básicamente que es un proceso realizable en la mayoría de las computadoras, siempre que dispongan de conexión a internet y de disquetera. Con este sistema podemos:

• hacer nuestras configuraciones desde disquete y preparar una rom totalmente operativa para volcarla en memoria EPROM^7.13.

• o dejar nuestros nodos clientes con la disquetera y arrancarlos siempre desde disquete.

La opción más elegante es sin duda la primera, puesto que si realmente el cometido que nos ha hecho llegar aquí han sido los nodos minimalistas, ¿qué menos que prescindir de las disqueteras, su cable de alimentación y el de datos?

Generando imagen para RPL

Como no podía ser de otra manera la comunidad del software libre pone a nuestra disposición un sistema en extremo asequible e intuitivo para la generación de las susodichas imágenes rom.

Existen dos propuestas, ambas se encuentran en SourceForge:

• Etherboot^7.14, que se sirve de drivers insertados en la imagen.

• Netboot^7.15, que dispone los drivers en un paquete.

Explicaremos con más detalle cada una de estas propuestas, analizando también el benecifio que en cada caso puedan aportar a nuestro sistema.

I - ETHERBOOT

El proyecto Etherboot dispone de un apartado sobre documentación (en inglés, como es de suponer). Los procedimientos explicados a continuación pueden ampliarse en su web, aunque en esencia puede resumirse todo ello de la forma que sigue.

¿Cómo puedo obtener una imagen ROM?

• Marty Connor ha trabajado en una versión en linea para poder bajarnos la imagen para nuestro modelo específico de chipset. Puedes encontrarlo en su proyecto ROM-o-matic for Etherboot^7.16.
• o podemos compilar nosotros mismos la imagen.

El mecanismo que genera la imagen es el mismo, es decir, romomatic simplemente llama a la aplicación etherboot, con las opciones marcadas, a través de un script. Por esa razón -y pensando en simplificar siempre las cosas- aquí se aboradrá el caso desde romomatic. En caso de querer hacer las cosas por propia cuenta habrá que enterarse bien de los parámetros de la aplicación^7.17.

En rom-o-matic.net existen varias versiones, es recomendable utilizar la versión estable -production release-. Un hiperenlace lleva a la página donde hay que introducir:

1. las especificaciones del chipset,
2. el medio desde donde la imagen será leída -chip, disquete, imagen en servidor-,
3. y configuraciones opcionales -temporizadores, etc.-.

Finalmente pulsar Get ROM para terminar bajando la imagen. Las imágenes preparadas para disquete hay que copiarlas con el comando

cat eb-5.0.8-tu_nic.lzdsk > /dev/fd0

donde /dev/fd0 refiere a nuestra disquetera y eb-5.0.8-tu_nic.lzdsk es la eom.

En este proceso pueden surgirte las siguiente dudas, que como no, tienen su respuesta.

• ¿qué modelo de chipset tiene mi tarjeta?
• ¿está soportado por Etherboot?

El modelo de chipset viene especificado por un número que puede conseguirse de diferentes maneras. Si no aciertas a conseguirlo con la documentación que la tarjeta pueda llevar sería adecuado hacer uso de los comandos, como superusuario (root):

lspci

cat /proc/bus/pci/devices

Puedes encontrar un ejemplo de su salida en el apéndice referente a Salidas de comandos y ficheros. Sobre si está soportado, y para conseguir siempre resultados acorde con la versión vigente de Etherboot, debe consultarse el hiperenlace de la página de generación de imagenes de ROM-o-matic sobre los PCI IDs soportados.

II- NETBOOT

¿Quieres redactar este apartado? ¡Envíamelo! mikel@akamc2.net . GRACIAS

Generando la rom para tagged image

La información contenida en una imagen de kernel normal -tipo bzImage- no es suficiente para que pueda cargarse por red. Pero esto no supone ningún problema, el usuario dispone de las herramientas mknbi que permiten taggear estos ficheros para hacerlos capaces de ello.

Así pues el resultado de aplicar las modificaciones de mknbi-linux al fichero bzImage resultado de la compilación de las fuentes de linux en el nodo que queramos arrancar por red, se llama tagged image. A efectos de usuario no supone ninguna diferencia con una imagen sin modificar.

Los paquetes necesarios para proceder de esta manera contienen unas aplicaciones llamadasmknbi-$<$so$>$ donde so refiere al sistema operativo que queramos arrancar. Nos centraremos en la utilidad mknbi-linux.

¿Qué necesita mknbi para funcionar? Evidentemente los parámetros obligados son el nombre de la imagen a modificar y el nombre de la iamgen de salida. Una posible llamada podría ser

mknbi-linux -format=nbi -ip=rom -output=/tftpboot/vmlinuz-metrakilate

-rootdir=/tftpboot/metrakilate /usr/src/linux/arch/i386/boot/bzImage

Una vez más se enfatiza en el hecho que para un pleno conocimiento de la herramientas será más útil consultar los manuales que incorpora, o la documentación que se dispone en su web.

Como se ve es sencillo de utilizar. Con un poco de soltura también se pueden hacer menús que gestionen la carga de uno u otro kernel con pantallas de menús tipo ncurses mediante mknbi-mgl y un lenguaje de programación semejante a Pascal, lo que es una opción bastante profesional para entornos de producción.

Sobre la aplicación cabe decir que es necesario pasarle la ruta nfsroot -correspondiente al parámetro rootdir- que indica de donde importar la raíz /. En el caso de no pasarse este parámetro existe una cosntante dentro de /usr/src/linux/fs/nfs/nfsroot.c que indica de donde será cargado el raíz. Por defecto es /tftpboot/$<$direccion_IP$>$.