7.3 Live Linux CD! Funcionando desde cdrom

Un Live Linux cdrom es un disco cdrom que contiene un sistema operativo Linux completo y por consiguiente un sistema de ficheros. Los Live Linux CDROM arrancan directamente desde un dispositivo lector cdrom. Simplemente tendremos que configurar la BIOS de la computadora para que intente arrancar primero desde cdrom.

Generalmente el orden para el arranque en la BIOS es: disquetera, disco duro y CDROM. Hay otras posibilidades, como puede ser el arranque por red, tal y como se explica también en el segundo apartado de este mismo capítulo (Nodos sin discos).

Para acceder a las opciones de la BIOS de nuestra computadora simplemente tendremos que pulsar la tecla DEL (o SUPR según nuestro teclado indique) en el momento en que se proceda al chequeo de la memoria, breves instantes después de poner en marcha cualquier PC.

En la red podemos encontrar proyectos bien consolidados que consiguen dar una alta funcionalidad a sistemas a partir de un linux embebido en un cdrom. Entre estas posibilidades contamos actualmente con el disco SuSE Live-eval, que proporciona una demo para la distribución alemana SuSE, o la distribución Knoppix^7.18. Google proporciona, como no, una referencia sobre las distribuciones live más extendidas en Google Live Linux ^7.19.

Así pues, ahora que se ha puesto en conocimiento del lector la posibilidad de arrancar un sistema linux almacenado en cdrom, puede surgir la primera pregunta: ¿nos será posible guardar nuestros documentos o cambios en este sistema? Evidentemente NO en el propio cdrom, pero como veremos existen multitud de alternativas que linux nos brinda con un fácil manejo.

En primer lugar cabe señalar que ejecutar un sistema operativo desde cdrom será tanto más ameno cuanto más rápido sea el dispositivo lector. Actualmente se han llegado a las 72x^7.20 en dispositivos que alcanzan a leer varias pistas simultáneamente (y es que esto de paralelizar los procedimientos cada vez es más una realidad) y esto se traduce en casi 11 mega-octetos por segundo. No obstante, cualquier reproductor de medianas prestaciones seguirá dándonos unos resultados más que aceptables.

En respuesta a si esta solución de arranque aporta algún tipo de beneficio extra, podemos referirnos básicamente al ahorro en material informático. Si sólo necesitamos el cdrom para poder realizar las funciones que nuestras necesidades requieren (navegar por la red, trabajar con un sistema de archivos remoto, etc...) nuestro terminal podrá carecer de disco duro y disquetera. Esto también implica, a su vez, un gran ahorro en tareas de mantenimiento de los equipos, puesto que cualquier actualización puede quemarse en nuevos cds (¡o borrarlos y reescribirlos!) y ningún usuario podrá modificar el sistema que hayamos generado.

Es importante pues que el sistema mínimo para arrancar desde cdrom contenga el hardware necesario para un arranque sin discos además del lector de discos compactos.

En resumidas cuentas, este sistema de arranque nos puede proporcionar ventajas en varios frentes:

• crear un CD de instalación.
• tener el sistema operativo en cdrom y utilizar los discos duros para otros fines.
• tener un método de fácil actualización de sistemas, usando discos regrabables (CD-RW).

La idea, mirando al futuro de los sistemas informáticos, es poder contar con una computadora sin discos duros: utilizar el cdrom para el sistema operativo, un disco en memoria RAM para /tmp y un sistema de ficheros remoto NFS para lo demás.

7.3.1 Consideraciones previas

Es posible llegar a poner nuestra distribución favorita de manera que arranque desde cdrom, como veremos no supone un gran esfuerzo. Esto puede aportarnos las ventajas de configurar el kernel a nuesta manera, así como los módulos cargables y el entorno gráfico.

Para nuestro documento, y teniendo en cuenta que estamos sobrellevando todo esto mirando a la clusterización con openMosix, podremos llegar a poner en este CD un kernel con el soporte adecuado para él, y así poder incluir a nuestro cluster cualquier PC que tengamos conectado a la red, simplemente indicándole que arranque desde el cdrom.

Como puede deducirse a partir de lo visto hasta ahora, y para dejar claro que este sistema no va en detrimento de ningún recurso (sino al contrario) ni hace perder funcionalidades a los nodos, se indica que desde esta distribución podremos montar las particiones que tengamos en los discos locales de cada nodo, y así pues seguir con nuestras tareas mientras hemos convertido el PC en miembro de un cluster openMosix. Evidentemente podremos escribir en estas particiones montadas siempre que tengamos permiso para hacerlo.

En este documento se asume que el lector tiene conocimiento de utilidades como cdrecord para quemar cdroms o mkisofs para generar un sistema de ficheros ISO. No obstante, con los parámetros aquí utilizados debería ser suficiente para llegar a nuestra meta.

7.3.2 Dispositivos ramdisk en linux

Como ya hemos explicado, será necesario tener los conocimientos precisos para poder trabajar con /tmp en RAM para poder disponer de un lugar donde nuestro sistema sea capaz de almacenar sus archivos temporales. Crear estos dispositivos y trabajar con ellos en linux es trivial. A continuación se intentará dar una visión global de este método volátil de almacenaje.

Antes de proceder, comprueba que estás actuando como administrador (root) de tu sistema.

QUÉ ES UN RAMDISK

Consideraremos un dispositivo en RAM cualquier porción de memoria que hayamos dispuesto para usar como una partición más en nuestro sistema de ficheros. Podremos verlos como discos duros virtuales.

¿Por qué puede interesarnos trabajar con estos dispositivos? De todos debe ser sabido que la memoria de nuestra computadora está dispuesta mediante una jerarquía en cuanto a la velocidad de acceso (parámetro directamente proporcional a su coste por octeto). Así pues, el acceso a memoria principal (RAM) será varias veces más rápido que el acceso a memoria secundaria (discos duros) y varias veces más lento que cualquier memoria cache. Si disponemos los ficheros que más habitualmente usaremos en dispositivos RAM -ramdisks-, podemos llegar a aumentar considerablemente el potencial de nuestra computadora -método ampliamente utilizado en grandes servidores web-.
Evidentemente y para el caso concreto que nos atañe, este dispositivo nos servirá como una unidad de almacenaje temporal para que nuestro sistema pueda trabajar localmente con sus ficheros temporales (valga la redundancia).

COMO USAR UN RAMDISK

Su uso y configuración es altamente sencillo con linux: formatear tal dispositivo y montarlo en nuestro árbol de ficheros. Para ver todos los dispositivos ram con los que cuenta nuestro sistema solo tenemos que ejecutar:

ls -la /dev/ram*

No obstante, estos dispositivos se encuentran sin formato. Como se ha indicado, deberemos formatearlos y disponerlos en el árbol. Así el proceso con el primer dispositivo RAM /dev/ram0 sería:

• crear un directorio donde montar el dispositivo

  
  
  mkdir -p /tmp/ramdisk0

• generar su sistema de archivos (i.e. formatearlo)

  
  
  mkfs -t $<$ext2, ext3,...$>$ /dev/ram0

• montar este sistema de ficheros en el árbol de directorios

  
  
  mount /dev/ram0 /tmp/ramdisk0

Ahora podremos trabajar con él de forma usual; podremos percatarnos que los movimientos de datos entre este tipo de dispositivos son más rápidos. Es importante remarcar que estos discos estan en memoria y por tanto al rearrancar la computadora PERDEREMOS los datos que les hubieramos grabado.

Para comprobar que el montaje de las unidades ha sido correcto, podemos consultar el fichero /etc/mtab o ejecutar el comando df para ver la relación de espacios libres y usados. Ambas salidas puedes encontrarlas en el apéndice Salidas de comandos y ficheros.

CAMBIAR EL TAMA~NO DE LOS RAMDISKS

Si hemos intentado generar un sistema de ficheros ReiserFS quizás nos hayamos topado con la desagadable sorpresa de no disponer de suficiente espacio para poder generar el jounal requerido. Los ramdisks vienen con un tamaño máximo, parámetro que evidentemente se puede modificar.

Hay 2 maneras de hacerlo. Veámoslas:

• editar el fichero /usr/src/linux/block/rd.c y cambiar el valor de la variable
  int rd_size = 4096; /*Size of the ramdisks */
  por el valor el quilo-octetos deseado. Esta opción implica recompilar el kernel y rearrancar la máquina.
• la solución fácil es editar /etc/lilo.conf y annexar una nueva linea ramdisk=$<$N$>$ en la partición de arranque de linux para obtener un tamaño de N quilo-octetos. Luego deberemos ejecutar el comando lilo para actualizar los cambios.

MONTAR DIRECTORIOS EN PARTICIONES RAMDISK

Para terminar se da un método fácil con el que podremos montar alguno de nuestros directorios en memoria. Esto es precisamente lo que utilizaremos para montar el /tmp en ramdisk en el proceso de arranque, para que podamos escribir en él con nuestro live linux cdrom.

Las instrucciones son éstas:

• guardar una copia del directorio que queramos montar en memoria

  
  
  mv /tmp /tmp_real

• crear un directorio con el nombre que linux espera

  
  
  mkdir /tmp

• escribir los siguientes comandos para crear el FS y montarlo

  
  
  /sbin/mkfs -t ext2 /dev/ram2

  mount /dev/ram2 /tmp

• hacer la copia de contenidos desde disco a memoria

  
  
  tar -C /tmp_real -c . | tar -C /tmp -x

• para comprobar que la cosa funciona podemos ver el fichero /etc/mtab .

Estas lineas podremos utilizarlas igualmente en scripts para que nuestro linux haga estas operaciones, por ejemplo, al arranque. Esta técnica nos permitirá poder arrancar desde rom y normalmente se escriben en los ficheros del directorio /etc/rc.d/.
Los contenidos en cada distribución linux puede cambiar levemente. Es questión de investigar un poco para saber el orden en como se cargan. Quizás el fichero que más pueda ayudarnos en esta tarea sea, dentro de tal directorio, rc.sysinit.

7.3.3 Modificaciones a linux

Ahora ya se han expuesto las herramientas necesarias para poder generar un cdrom arrancable, a falta de un método ordenado. Éste consistirá en crear una partición de repuesto en el disco duro para hacer pruebas, antes de desechar inutilmente cdroms que no den el resultado esperado. Se podrá arrancar desde la partición correspondiente aunque con la peculiaridad de montarse como de sólo lectura (read only) con el fin que funcione como una memoria rom. Una vez testeada la prueba final, podremos pasar la partición a cdrom.

Todo ello se irá viendo en esta sección; el esquema sobre el que basaremos la metodología podría quedar así:

• conectar un disco duro y una grabadora de cdroms a la computadora que luego desearemos arrancar.
• particionar el disco de manera que dejemos al menos una partición (test) del tamaño del cdrom que vamos a usar (usualmente 700MB) y otra (principal) para realizar una instalación normal de Linux, desde donde generaremos la imagen arrancable y quemaremos el cdrom.
• se requerirán pues dos instalaciones de nuestro linux: una en la partición que contendrá lo que luego volcaremos al cdrom, y otra con soporte para quemar cdroms. Opcionalmente pueden copiarse en test los directorios que permitan arrancarlo, desde la instalación hecha en la partición principal; esto nos ahorrará hacer dos instalaciones.
• en principal montaremos test. En este ejemplo se usará la ruta absoluta /test, teniendo en cuenta que principal está montada en / .
• en el caso de que el kernel nos venga sin estas opciones (rara vez ocurre) arrancaremos test y re-compilaremos el kernel con soporte de isofs (el sistema de ficheros iso9660 es el estándar en cdroms) y soporte para cdrom, incluidos y NO como módulos.
• /tmp se montará en un ramdisk y apuntaremos /var hacia /tmp/var, teniendo en cuenta que estamos hablando de la partición montada en /test. Estos dos directorios son los que linux requiere como de lectura y escritura para mantener su coherencia. Configuraremos los ficheros necesarios para ajustarse a esta nueva situación del sistema.
• para el arranque del kernel hace falta echar mano de un disquete arrancable y configurarlo para utilizar el cdrom como dispositivo root (/). Ya se verá más detalladamente.
• finalmente quemaremos un cdrom con cdrecord.

CAMBIOS EN LA ESTRUCTURA DE DIRECTORIOS

Para empezar con los cambios en la partición test deberemos tener claro lo que hay que hacer, esto es, ser capaces de entender el proceso y no tanto de aplicar ciertas modificaciones a ciertos ficheros obviando lo que ello pueda significar. Este último método sin duda acortaría notablemente la duración del capítulo, no obstante y como Vd. querido lector ya sabrá, las estrucutras de directorios y nombres de los ficheros que contienen pueden sufrir variaciones entre distribuciones (y entre versiones de las mismas).

Suponiendo que se ha comprendido el funcionamiento de los ramdisk y que se tiene cierta soltura con lilo para arrancar sistemas linux, empezaremos a moldear los ficheros para que sean capaces de mantener funcionando nuestro equipo aun estando, o almenos en parte, en un dispositivo rom.

Quede claro pues que se modificará la estructura de archivos de la partición test para que pueda arrancarse con los permisos necesarios en una unidad de sólo lectura, como es un cdrom. Las rutas que se dan suponen que se está trabajando desde test. El esquema de las modificaciones que le aplicaremos es el siguiente:

1. Apuntar /var a /tmp/var . El objetivo del enlace puede no existir aún, pero se generará en el arranque gracias a un script. De momento lo veremos como un enlace roto.

   
   
   ln -s /tmp/var /var

   /var será otro directorio en el que será necesario poder escribir. Se construye esta estructura -apuntándolo hacia /tmp/var- aunque evidentemente podríamos generar otro ramdisk y montar var en él. Esto son decisiones de diseño.

2. Configurar el runlevel a 1. Bastará editar el fichero /etc/inittab y cambiar la linea

   id:$<$N$>$:initdefault: donde N será seguramente 3 ó 5

   por

   id:1:initdefault:

   Dando un repaso rápido a los runlevels, podemos verlos como diferentes niveles de arranque del linux en nuestro equipo. El modo 1 es el modo monousuario (ingl. single user mode), el modo 3 es el modo multiusuario completo con red (ingl. full multiuser with network) y el 5 es el modo multiusuario completo con red y gestor de escritorio (ingl. full multiuser with network and xdm). Hay 6 niveles pero en los arranques normales de linux se utilizan básicamente el 3 y el 5. Trasladar linux a runlevel 1 comportará que no se requiera login ni contraseña para ejecutar el shell.

   ¿Por qué es necesario trabajar con runlevel 1? Un sistema multiusuario necesita poder guardar información sobre los errores del servidor X-window de cada usuario que lo utilice, guardar información de los comandos de la consola y toda una retahíla de información que debe poder escribirse. En sistemas live, donde se depende de un dispositivo mucho más lento que un disco duro, sin memoria virtual (swap) y donde necesitamos la memoria primaria para poder cargar directorios para escritura, es mucho más cómodo trabajar en monousuario.

3. Borrar (o comentar con # al inicio) en el archivo /etc/fstab cualquier referencia a dispositivos de memoria virtual swap. Estas lineas, en discos duros IDE, se muestran como algo parecido a:

    /dev/hd<X>    swap      swap     pri=42     0 0
   

   El otro cambio que se efectuará en fstab es el dispositivo para montar / . En principio será la partición donde esté localizada test pero al trasladar los cambios al cdrom deberemos indicar aquí hda, hdb, hdc o hdd según donde tengamos conectado el lector. Esto sería, en un caso concreto, pasar de:

     /dev/hdb3    /    reiserfs   defaults     1 1
     /dev/hdc     /    iso9660    defaults     1 1
   

   Puede ser una buena idea escribir ambas líneas y comentar la segunda, de cara a recordar que más tarde deberemos pasar el comentario a la primera linea para poder arrancar correctamente. Puede observarse que el sistema de ficheros se adaptará al nuevo dispositivo rom, así que independientemente del formato de nuestra unidad en disco duro (ext2, ext3, xfs, reiserfs...) el cdrom se quemará con el estándar iso9660. Ya se ha advertido anteriormente que es importante tener soporte para él en el mismo kernel.

4. Aumentar el tamaño de los ramdisks, añadiendo en el fichero lilo.conf

     ramdisk = 35000
   

   dentro de la entrada que se corresponda con el arranque de la partición test. No olvidemos ejecutar el comando lilo para actualizar los cambios.

   Este parámetro solo tendrá efecto para el arranque de la partición desde disco duro, más tarde se detallará dónde debe incluirse esta linea para que tenga efecto en el arranque live.

5. Enlazar mtab. Este fichero se actualiza cada vez que se monta o desmonta un dispositivo, por lo tanto debemos poder modificarlo aún estando en el lugar donde linux lo buscará (en /etc). ¿Cómo hacer esto? Convirtiendo mtab en un enlace simbólico hacia /proc/mounts, fichero al cual empezaremos actualizándole las fechas de acceso

   
   
   touch /proc/mounts

   rm -rf /etc/mtab

   ln -s /proc/mounts /etc/mtab

   
   
   En algunos scripts aparecen las lineas

    # Clear mtab
    >/etc/mtab
   

   para reinicializar el fichero en cuestión. Si este cambio se aplica tras haber montado nuestros dispositivos en memoria, puede darse el caso de que nuestro equipo no los vea, algo que se traduce en una inconsistencia mediana o grave. Lo mejor será comentarlo (añadiendo # al inicio de la linea).

   Es importante trabajar desde test para generar los enlaces, puesto que si creamos los enlaces con rutas desde principal (como /test/var o ./tmp/var) la partición test no los reconocería correctamente puesto que ella, al arrancar, tendrá /var montado en /tmp/var y no en ./tmp/var (partiendo de /etc o de /test).

6. Convertir la unidad en acceso de sólo lectura es fácil puesto que en estos scripts de iniciación de remonta / para hacerla de lectura y escritura. Las lineas que se corresponden a esta operación deben ser algo parecido a

   # Remount the root filesystem read-write.
   state=`awk '/(^\/dev\/root| \/ )/ { print $4 }' /proc/mounts`
   [ "$state" != "rw" ] && \
     action $"Remounting root FS in read-write mode: " mount -n -o remount,rw /
   

   que debería sustituirse por

   # Remount the root filesystem read-write.
   state=`awk '/(^\/dev\/root| \/ )/ { print $4 }' /proc/mounts`
   [ "$state" != "rw" ] && \
     action $"Remounting root FS in read-only mode: " mount -n -o remount,ro /
   

   igualmente debería anularse cualquier referencia a memoria virtual (swap). Como puede apreciarse en el siguiente ejemplo, la linea se ha comentado para que no sea ejecutada.

   # Start up swapping.
   # action $"Activating swap partitions: " swapon -a -e
   

   Por regla general en estos scripts no hay ninguna referencia más a dispositivo de lectura y escritura. No obstante estaría bien tomar paciencia y repasarlos de arriba a abajo. Generalmente estan muy bien comentados -en inglés- ahorrándonos muchos dolores de cabeza.

7. Finalmente tendrá que generarse el ramdisk y su árbol de directorios para que pueda guardar todas las entradas en /tmp y /var que el sistema requiera^7.21. Podemos editar /etc/rc.sysinit o cualquier script que venga con nuestra distribución y al que se invoque en el arranque.

   Las siguientes lineas deberán incluirse almenos tras configurar el PATH, i.e. allá donde linux irá a buscar los ficheros binarios mkdir y mkfs (entre otros) necesarios apra crear directorios y sistemas de archivo, respectivamente). Esta linea puede aparecer como

     # Set the path
     PATH=/bin:/sbin:/usr/bin:/usr/sbin
     export PATH
   

   Una buena forma de asegurarnos de no cambiar los permisos del ramdisk y mantener la coherencia de mtab es incluir estas lineas directamente a continuación de remontar / como sólo lectura.

   1. crearemos el dispositivo en memoria y le daremos formato

      action "Making ram0 " /sbin/mkfs.ext3  /dev/ram0
      action "Mounting ram0" mount /dev/ram0 /tmp -o defaults,rw
      

   2. crearemos el árbol de directorios

      action "Making /tmp/etc" mkdir /tmp/etc
      action "Making /tmp/var" mkdir /tmp/var
      action "Making /tmp/var/log" mkdir -p /tmp/var/log
      action "Making /tmp/var/run" mkdir -p /tmp/var/run
      action "Making /tmp/var/lock" mkdir -p /tmp/var/lock
      action "Making /var/lock/subsys" mkdir -p /var/lock/subsys
      action "Making /tmp/var/lib" mkdir -p /tmp/var/lib
      action "Making /tmp/var/spool" mkdir -p /tmp/var/spool
      action "Making /tmp/var/spool/mqueue" mkdir -p /tmp/var/spool/mqueue
      

   3. cambiaremos los permisos para poder escribir en ellos

      action "Chmod 777 /tmp " chmod 777 /tmp
      action "Chmod +t /tmp" chmod +t /tmp
      

   4. haremos un nuevo dispositivo ramdisk y le copiaremos el contenido de /dev

      echo "mkdir /tmp/dev" mkdir -p /tmp/dev
      echo "Making ram1 " /sbin/mkfs.ext2  /dev/ram1
      echo "Mounting ram1" mount /dev/ram1 /tmp/dev
      echo "cp -a /dev/* /tmp/dev/" cp -a /dev/* /tmp/dev/ > /dev/null
      echo "umounting /tmp/dev" umount /tmp/dev
      echo "remounting /tmp/dev to /dev" mount /dev/ram1 /dev
      

Tras esto test debería arrancar sin mayores problemas. Es normal que se nos quede colgada en algunos de los muchos ensayos que vamos a hacer hasta llegar a este resultado. No obstante debe avanzarse siguiendo una lógica y no suponiendo que tenemos algo que no lo hace funcionar. Algunos scripts necesitarán llegar a cierta estructura de árbol (en /var o /tmp) y en caso de que no lo hayamos generado en el dispositivo en RAM nos devolverá un error. Simplemente añadiendo y/o modificando las líneas del punto b) para creación de directorios podremos arreglar esto.

¿Por qué no se ha hablado de /proc? Este directorio contiene información sobre lso procesos que corren en nuestro equipo, pero ya por defecto se monta en memoria. Por esta razón -y no por otra- no deberemos encargarnos de él.

ARRANCANDO UN KERNEL CON UNA IMAGEN DE DISQUETE

Para proceder con estos, los últimos pasos para obtener el cdrom, es mejor reiniciar el sistema y trabajar desde principal (siempre teniendo test en /test).

Para generar disquetes arrancables existen varios métodos. Quizá el más simple y efectivo sea obtenerlo directamente del cdrom de alguna distribución. Generalmente aparecen con nombres como boot.img o bootdisk y siempre tienen un tamaño de 1,4 mega-octetos. De forma alternativa podremos generarlo nosotros mismos.

• hacer una copia del kernel

  cp /boot/vmlinuz-$<$version_del_kernel$>$ /tmp/vmlinuz

• hacer la copia arrancable del cdrom en /dev/$<$dispositivo_cdrom$>$

  rdev /tmp/vmlinuz /dev/$<$dispositivo_cdrom$>$

  ramsize /tmp/vmlinuz 20000

• formatear un disquete y copiar el kernel

  mkfs -t ext2 /dev/fd0

  dd if=/tmp/vmlinuz of=/dev/fd0

En el caso de que se disponga de la imagen de un disquete arrancable, deberemos modificar ciertos parámetros. Para hacerlo deberemos montar esa imagen:

mount $<$fichero_imagen$>$ $<$directorio_de_montaje$>$ -o loop -t vfat

En $<$directorio_de_montaje$>$ debería aparecernos almenos: una imagen binaria del kernel de linux (vmlinuz), algunos ficheros binarios para los menús de pantalla y los ficheros que consideraremos importantes, ldlinux.sys y syslinux.cfg. Deberemos editar el segundo para personalizarlo a nuestro sistema. Básicamente deberá contener la etiqueta del arranque y el nombre de la imagen, por ejemplo:

default linux

       label linux
       kernel vmlinuz
       root=/dev/<dispositivo_cdrom>
       ramdisk=35000

Si estamos familiarizados con LiLO no nos será difícil configurar este fichero. La otra cosa importante es sustituir vmlinuz por la imagen que arranque test (y su fichero initrd en caso de que exista; ambos los encontraremos en /test/boot/). En el apéndice Salidas de comandos y ficheros podrás ver un caso concreto de este archivo^7.22. Ahora desmontaremos la imagen.

umount $<$directorio_de_montaje$>$

Y copiaremos esta imagen de disquete arrancable al directorio /test. El kernel embebido aquí será el que arrancará el sistema.

Un testeo interesante antes de quemar el cdrom es probar si la imagen de disquete que hemos creado funciona. La manera rápida y eficaz de hacerlo es copiar dicha imagen con el mismo comando dado para copiar el kernel aunque indicando el fichero adecuado a if, así dd if=bootdisk of=/dev/fd0 . Podemos arrancar la computadora y si este arranque parece funcionar (¡no tendrá sistema de ficheros!), probaremos con el cdrom.

AHORRANDO UNA SEGUNDA INSTALACIÓN. COPIA DE CONTENIDOS

Una variante de este esquema podría darse cuando no hayamos cumplido un proceso de instalación en test. Tendremos que tener en cuenta que podremos aprovechar la mayor parte de los directorios de la partición principal (siempre y cuanto quepan en el directorio /test). En el árbol de directorios, excepto /usr, el contenido de los demás directorios no será crítico. En /test podremos disponer la estructura copiando los directorios desde principal y arreglando los ficheros necesarios en /etc .

Para generar los directorios en test, por ahora vacía, podríamos ejecutar:

cd /test

mkdir root

mkdir mnt

mkdir proc

mkdir tmp

mkdir home

mkdir misc

mkdir opt

mkdir dev

E iniciamos la copia de contenidos con rsync. Alternativamente podríamos usar el comando cp -a.

rsync -a /dev/* dev

mkdir lib

rsync -a /lib/* lib

mkdir bin

rsync -a /bin/* bin

mkdir sbin

rsync -a /sbin/* sbin

mkdir usr

mkdir etc

rsync -a /etc/* etc

mkdir boot

rsync -a /boot/* boot

7.3.4 Creando el cdrom

Antes de empezar con el proceso de quemado es necesario recordar que hay que modificar el fichero /test/etc/fstab para indicarle a linux que el dispositivo root ahora no será la partición test sino el cdrom (con iso9660).

Para disponer en un cdrom todos los contenidos que hasta ahora hemos modificado seguiremos los siguientes pasos:

• crear la imagen iso9660 llamada boot.iso (situados en el directorio donde queramos generarla)

  mkisofs -R -b boot.img -c boot.catalog -o boot.iso /test

• verificar la imagen iso, montándola en algun directorio

  mount boot.iso $<$directorio_de_montaje$>$ -o loop -t iso9660

• quemar el CD

  cdrecord -v speed=$<$velocidad$>$ dev=$<$ruta_del_grabador$>$ boot.iso

• verificar el arranque desde cdrom, re-arrancando la computadora.

7.3.5 Últimos detalles

Puede ser interesante, desde el punto de vista práctico, mostrar una pantalla antes de empezar con el arranque del kernel, para poder elegir las opciones con las que va a hacerlo. Esto es modo gráfico, tamaño de los ramdisks, etc...

Por el momento el espacio disponible en un disquete no nos permite poder embeber en él varios kernels de tamaño tradicional. No obstante si se trabaja con sistemas con pocos requerimientos se podrán arrancar varias imágenes vmlinuz. El fichero syslinux.cfg se maneja como el lilo.conf así que no debería darnos más problemas. En el apéndice Salidas de comandos y ficheros se adjunta un ejemplo.

Para mostrar un menú podemos añadir, a la cabecera de syslinux.cfg, la linea

   display boot.msg

donde boot.msg será la pantalla a mostrar. Este fichero podemos editarlo con un editor de texto llano, aunque contiene algunos bytes en binario que deberemos respetar. Igualmente podremos llamar otros menús a partir de éste, con las teclas de función. Estas configuraciones también irán a la cabecera de syslinux.cfg^7.23.

Las posibilidades que brinda este cargador pueden embellecerse usando los 16 colores que cualquier targeta VGA soporta. A continuación se da un ejemplo de un menú que mostraría por pantalla, en cada color, el número hexadecimal que lo codifica.

^L
Ejemplo de colores para el mensaje de arranque desde un disquete botable:^O07
         ^O01 azul claro=1 ^O07
         ^O02 verde=2 ^O07
         ^O03 azul claro=3 ^O07
         ^O04 rojo oscuro=4 ^O07
         ^O05 purpura=5 ^O07
         ^O06 marron=6 ^O07
         ^O07 gris=7 ^O07
         ^O08 verde oscuro=8 ^O07
         ^O09 azul=9 ^O07
         ^O0a verde claro=A ^O07
         ^O0b azul claro=B ^O07
         ^O0c rojo=C ^O07
         ^O0d lila=D ^O07
         ^O0e amarillo=E ^O07
         ^O0f negrita=F ^O07

La estructura de estos ficheros es:

• ^L
  

  limpia la pantalla. Es binario así que algun editor puede mostrarlo distinto a como aquí se muestra (con emacs). Para asegurar que se está tomando el carácter correcto lo mejor es hacerse con un fichero ya existente en cualquier liveCd y copiarlo.
• los colores se codifican con la secuencia

  ^O0x
  

  donde x es un dígito hexadecimal (del 1 al F); y los saltos de linea son

  ^O07
  

El carácter con el que empiezan los código hexadecimales no es el acento circunflejo, así que si probamos de escribir el texto anterior tal cual no funcionará. Como se ha descrito, lo mejor es tomar ficheros ya existentes y copiar dichos códigos.

Para terminar con este apartado cabe decir que SuSE no ha reparado en esfuerzos hasta llegar a conseguir mostrar una inmejorable imagen de gecko (el camaleón verde que les sirve de logotipo) en nuestro sistema. Su gfxboot permite dispone las opciones como un menú a todo color. Para más detalles mejor consultar su syslinux.cfg .