\newpage
%===========================================================================
%       x.20 > Live Linux CD
%===========================================================================
\pagestyle{empty}
\begin{latexonly}
\ifpdf
 \begin{figure}[htbp]
       \includegraphics[bb = -200 220 0 0, scale=1]{./TuXes/tux-cd.png}
 \end{figure}
 \vspace{5in}
\else
 \begin{figure}
       \scalebox{.85}{\includegraphics[-270,680][0,0]{./TuXes/tux-cd}}
 \end{figure}
\fi
\hfill\line(1,0){400}
\end{latexonly}
\topmargin 1in
\section{ {\em Live Linux CD!} Funcionando desde cdrom}
\begin{latexonly}
\line(1,0){400}
\newpage
\end{latexonly}
\topmargin 0in
\pagestyle{fancy}
%========================cita===============================================
\begin{latexonly}
\hspace{1in}\textcolor{blue_omosix}{{\em Being busy does not always mean real work.}}

\hspace{1in}\textcolor{blue_omosix}{{\em The object of all work is production or accomplishment}}

\hspace{1in}\textcolor{blue_omosix}{{\em and to either of these ends there must be forethought, system, planning, intelligence}}

\hspace{1in}\textcolor{blue_omosix}{{\em  and honest purpose, as well as perspiration.}}

\hspace{1in}\textcolor{blue_omosix}{{\em Seeming to do is not doing.}}

\hspace{4in}\textcolor{blue_omosix}{{\em Thomas A. Edison}}
\vspace{0.5in}

\end{latexonly}
%===========================================================================
Un {\em Live Linux cdrom} es un disco cdrom que contiene un
sistema operativo Linux completo y por consiguiente un sistema de ficheros. Los {\em 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\'en
en el segundo apartado de este mismo cap\'\i tulo ({\em Nodos sin discos}).

Para acceder a las opciones de la BIOS de nuestra computadora
simplemente tendremos que pulsar
la tecla {\tt DEL} (o {\tt SUPR} seg\'un nuestro teclado indique) en el
momento en que 
se proceda al chequeo de la memoria, breves instantes despu\'es 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 {\em SuSE Live-eval}, que proporciona
una demo para la distribuci\'on alemana 
SuSE, o la distribuci\'on Knoppix\footnote{{\tt \htmladdnormallink{
http://www.knopper.net/knoppix}{http://www.knopper.net/knoppix}}}.
Google proporciona, como no, una referencia sobre las
distribuciones {\em live} m\'as extendidas en {\em Google Live Linux}
\footnote{{\tt \htmladdnormallink{http://directory.google.com/Top/Computers/Software/Operating\_Systems/Linux/Distributions/Live\_CD/?tc=1}{http://directory.google.com/Top/Computers/Software/Operating_Systems/Linux/Distributions/Live_CD/?tc=1}}}.

As\'\i\ 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\'a 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\'acil manejo.

En primer lugar cabe se\~{n}alar que ejecutar un sistema
operativo desde cdrom ser\'a
tanto m\'as ameno cuanto m\'as r\'apido sea el dispositivo lector.
Actualmente se han llegado a las 72x\footnote{{\tt \htmladdnormallink{http://www.kenwoodtech.com/72x\_atapi.html}{http://www.kenwoodtech.com/72x_atapi.html}}}
 en dispositivos
que alcanzan a leer varias pistas simult\'aneamente (y es que
esto de paralelizar los
procedimientos cada vez es m\'as una realidad) y esto se traduce en casi
11 mega-octetos por segundo.
No obstante, cualquier reproductor de medianas prestaciones seguir\'a
d\'andonos unos resultados
m\'as que aceptables.

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

Es importante pues que el sistema m\'\i nimo para arrancar
desde cdrom contenga el hardware
necesario para un arranque sin discos adem\'as del 
lector de discos compactos.

En resumidas cuentas, este sistema de arranque nos
puede proporcionar ventajas en varios frentes:
\begin{itemize}
 \item crear un CD de instalaci\'on.
 \item tener el sistema operativo en cdrom y utilizar los discos duros
 para otros fines.
 \item tener un m\'etodo de f\'acil actualizaci\'on de sistemas,
 usando discos regrabables (CD-RW).
\end{itemize}

La idea, mirando al futuro de los sistemas inform\'aticos, es poder
contar con una computadora sin discos duros: utilizar el cdrom para el
sistema operativo, un disco en memoria RAM para {\em /tmp} y un sistema
de ficheros remoto NFS para lo dem\'as.
%------------------------------------------------------------------
\subsection{Consideraciones previas}
Es posible llegar a poner nuestra distribuci\'on 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\'\i\ como los m\'odulos
cargables y el entorno gr\'afico.

Para nuestro documento, y teniendo en cuenta que estamos sobrellevando
todo esto mirando a la
clusterizaci\'on con openMosix, podremos llegar a poner en este CD un
kernel con el soporte
adecuado para \'el, y as\'\i\ poder incluir a nuestro cluster cualquier
PC que tengamos
conectado a la red, simplemente indic\'andole 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\'un recurso (sino al
contrario) ni hace perder funcionalidades a los nodos, se indica que desde esta
distribuci\'on podremos
montar las particiones que tengamos en los discos locales de cada nodo, y as\'\i\
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 {\em cdrecord} para quemar cdroms o {\em mkisofs} para
generar un sistema de ficheros ISO. No obstante, con los par\'ametros
aqu\'\i\ utilizados deber\'\i a ser suficiente para llegar a nuestra
meta.
%------------------------------------------------------------------
\subsection{Dispositivos {\em ramdisk} en linux}
Como ya hemos explicado, ser\'a necesario tener los
conocimientos precisos para poder trabajar con {\em /tmp} en RAM para
poder disponer de un {\em lugar} donde nuestro
sistema sea capaz de almacenar sus archivos temporales. Crear estos
dispositivos y trabajar con ellos en linux es trivial. A
continuaci\'on se intentar\'a dar una visi\'on global de este m\'etodo
vol\'atil de almacenaje.

Antes de proceder, comprueba que est\'as actuando como administrador
(root) de tu sistema.

\vspace{.2in}
\hspace{.3in}{\bf\sc Qu\'e es un Ramdisk}

\vspace{.1in}
Consideraremos un dispositivo en RAM cualquier porci\'on de memoria que hayamos dispuesto para usar como
una partici\'on m\'as en nuestro sistema de ficheros. Podremos verlos
como discos duros virtuales.

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

\vspace{.2in}
\hspace{.3in}{\bf\sc Como usar un Ramdisk}

\vspace{.1in}
Su uso y configuraci\'on es altamente sencillo con
linux: formatear tal dispositivo y montarlo en nuestro \'arbol de
ficheros. Para ver todos los dispositivos ram con los que cuenta nuestro
sistema solo tenemos que ejecutar:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt ls -la /dev/ram*}}

\vspace{.1in}
No obstante, estos dispositivos se encuentran sin formato. Como se ha
indicado, deberemos formatearlos y disponerlos en el \'arbol. As\'\i\
el proceso con el primer dispositivo RAM {\em /dev/ram0} ser\'\i a:
\begin{itemize}
  \item crear un directorio donde montar el dispositivo

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt mkdir -p /tmp/ramdisk0}}

  \item generar su sistema de archivos (i.e. formatearlo)

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt mkfs -t $<$ext2, ext3,...$>$
  /dev/ram0}}

  \item montar este sistema de ficheros en el \'arbol de directorios

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt mount /dev/ram0 /tmp/ramdisk0}}
\end{itemize}

Ahora podremos trabajar con \'el de forma usual; podremos percatarnos
que los movimientos de datos entre este tipo de dispositivos son
m\'as r\'apidos. Es importante remarcar que {\bf 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 {\em /etc/mtab} o ejecutar el
comando {\tt df} para ver la relaci\'on de espacios
libres y usados. Ambas salidas puedes encontrarlas en el ap\'endice {\em
Salidas de comandos y ficheros}.

\vspace{.2in}
\hspace{.3in}{\bf\sc Cambiar el tama\~{n}o de los Ramdisks}

\vspace{.1in}
Si hemos intentado generar un sistema de ficheros
ReiserFS quiz\'as nos hayamos topado con la desagadable sorpresa de no
disponer de suficiente espacio para poder generar el {\em jounal}
requerido. Los ramdisks vienen con un tama\~{n}o m\'aximo, par\'ametro
que evidentemente se puede modificar.

Hay 2 maneras de hacerlo. Ve\'amoslas:
\begin{itemize}
  \item editar el fichero {\em /usr/src/linux/block/rd.c} y cambiar el
  valor de la variable\\
  {\tt int rd\_size = 4096; /*Size of the ramdisks  */}\\
  por el valor el quilo-octetos deseado. Esta opci\'on implica recompilar
  el kernel y rearrancar la m\'aquina.
  \item la soluci\'on f\'acil es editar {\em /etc/lilo.conf} y annexar una nueva linea {\tt ramdisk=$<$N$>$}
  en la partici\'on de arranque de linux para obtener un tama\~{n}o de
  {\em N} quilo-octetos. Luego deberemos ejecutar el comando {\tt lilo} para
  actualizar los cambios.
\end{itemize}

\vspace{.2in}
\hspace{.3in}{\bf\sc Montar directorios en particiones Ramdisk}

\vspace{.1in}
Para terminar se da un m\'etodo f\'acil con el que
podremos montar alguno de nuestros directorios en memoria. Esto es precisamente lo que utilizaremos para montar el {\em
/tmp} en ramdisk en el proceso de arranque, para que podamos escribir en \'el con nuestro
{\em live linux cdrom}.

Las instrucciones son \'estas:
\begin{itemize}
   \item guardar una copia del directorio que queramos montar en
   memoria

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt mv /tmp /tmp\_real}}

   \item crear un directorio con el nombre que linux espera

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt mkdir /tmp}}

   \item escribir los siguientes comandos para crear el FS y montarlo

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt /sbin/mkfs -t ext2 /dev/ram2}}

\hspace{1in}\colorbox{gray}{{\tt mount /dev/ram2 /tmp}}

   \item hacer la copia de contenidos desde disco a memoria

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt tar -C /tmp\_real -c . | tar -C /tmp -x}}

   \item para comprobar que la cosa funciona
   podemos ver el fichero {\em /etc/mtab} .
\end{itemize}

Estas lineas podremos utilizarlas igualmente en {\em scripts} para que nuestro linux haga estas operaciones, por ejemplo, al arranque.
Esta t\'ecnica nos permitir\'a poder arrancar desde rom y normalmente se escriben en los ficheros del directorio {\em /etc/rc.d/}.\\
Los contenidos en cada distribuci\'on linux puede cambiar levemente. Es questi\'on de investigar un poco para saber el orden en como se cargan. 
Quiz\'as el fichero que m\'as pueda ayudarnos en esta tarea sea, dentro de tal directorio, {\em rc.sysinit}.
%------------------------------------------------------------------
\subsection{Modificaciones a linux}
Ahora ya se han expuesto las herramientas necesarias
para poder generar un cdrom arrancable, a falta de un m\'etodo
ordenado. \'Este consistir\'a en crear una partici\'on de repuesto en
el disco duro para hacer pruebas, antes de desechar inutilmente
cdroms que no den el resultado esperado. Se podr\'a arrancar desde
la partici\'on correspondiente aunque con la peculiaridad de montarse como de s\'olo
lectura ({\em read only}) con el fin que funcione como una memoria
rom. Una vez testeada la prueba final, podremos pasar la partici\'on a cdrom.

Todo ello se ir\'a viendo en esta secci\'on; el esquema sobre el que
basaremos la metodolog\'\i a podr\'\i a quedar as\'\i :
\begin{itemize}
 \item conectar un disco duro y una grabadora de cdroms a la computadora que
luego desearemos arrancar.
 \item particionar el disco de manera que dejemos al menos una
partici\'on ({\tt test}) del tama\~{n}o del cdrom que vamos a usar
(usualmente 700MB) y otra  ({\tt principal}) para realizar una instalaci\'on {\em normal}
de Linux, desde donde 
generaremos la imagen arrancable y quemaremos el cdrom.
 \item se requerir\'an pues dos instalaciones de nuestro linux: una en la partici\'on
que contendr\'a lo que luego volcaremos al cdrom, y otra con soporte para
quemar cdroms. Opcionalmente pueden copiarse en {\tt test} los
directorios que permitan arrancarlo, desde la instalaci\'on hecha en la partici\'on
principal; esto nos ahorrar\'a hacer dos instalaciones.
 \item en {\tt principal} montaremos {\tt test}. En este
ejemplo se usar\'a la ruta absoluta {\em /test}, teniendo en cuenta que
{\tt principal} est\'a montada en {\em /} .
 \item en el caso de que el kernel nos venga sin estas
opciones (rara vez ocurre) arrancaremos {\tt test} y re-compilaremos el
kernel con soporte de {\em isofs} (el sistema de ficheros iso9660 es el est\'andar en
cdroms) y soporte para cdrom, incluidos y NO como m\'odulos. 
 \item {\em /tmp} se montar\'a  en un {\em ramdisk}  y
 apuntaremos {\em /var} hacia {\em /tmp/var}, teniendo en cuenta que
 estamos hablando de la partici\'on montada en {\em /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\'on del sistema.
 \item para el arranque del kernel hace falta echar mano de un disquete arrancable y configurarlo para
 utilizar el cdrom como dispositivo {\tt root (/)}. Ya se ver\'a m\'as detalladamente.
 \item finalmente quemaremos un cdrom con {\em cdrecord}.
\end{itemize}

\vspace{.2in}
\hspace{.3in}{\bf\sc Cambios en la estructura de directorios}

\vspace{.1in}
Para empezar con los cambios en la partici\'on {\tt 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 \'ultimo m\'etodo sin duda acortar\'\i a
notablemente la duraci\'on del cap\'\i tulo, no obstante y como Vd. querido
lector ya sabr\'a, 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 {\em ramdisk} y que
se tiene cierta soltura con {\tt 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\'a la estructura de archivos de la partici\'on {\tt test} para que pueda arrancarse con los permisos necesarios en una unidad de s\'olo lectura, como es un cdrom. Las rutas que se dan suponen que se est\'a trabajando desde {\tt test}. El esquema de las modificaciones que le aplicaremos es el siguiente:
\begin{enumerate}
  \item Apuntar {\em /var} a {\em /tmp/var} . El objetivo del enlace puede no existir a\'un, pero se generar\'a en el arranque gracias a un {\em script}. De momento lo veremos como un enlace roto.

\vspace{.1in}
\colorbox{gray}{{\tt ln -s /tmp/var /var}}

{\em /var} ser\'a otro directorio en el que ser\'a necesario poder escribir. Se construye esta estructura -apunt\'andolo hacia {\em /tmp/var}- aunque evidentemente podr\'\i amos generar otro {\em ramdisk} y montar {\/var} en \'el. Esto son decisiones de dise\~{n}o.

  \item Configurar el {\em runlevel} a 1. Bastar\'a editar el fichero
  {\em /etc/inittab} y cambiar la linea

{\tt id:$<$N$>$:initdefault:}  donde {\em N} ser\'a seguramente 3 \'o 5

por

{\tt id:1:initdefault:}

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

{\bf ?`Por qu\'e es necesario trabajar con runlevel 1?} Un sistema
multiusuario necesita poder guardar informaci\'on sobre los errores
del servidor X-window de cada usuario que lo utilice, guardar
informaci\'on de los comandos de la consola y toda una retah\'\i la de
informaci\'on que debe poder escribirse. En sistemas {\em live}, donde
se depende de un dispositivo mucho m\'as lento que un disco duro, sin
memoria virtual ({\em swap}) y donde necesitamos la memoria primaria para poder cargar directorios para
escritura, es mucho m\'as c\'omodo trabajar en monousuario.

  \item Borrar (o comentar con {\tt \#} al inicio) en el archivo {\em /etc/fstab} cualquier
  referencia a dispositivos de memoria virtual {\em swap}. Estas lineas, en discos duros IDE, se muestran como algo parecido a:
\begin{verbatim}
 /dev/hd<X>    swap      swap     pri=42     0 0
\end{verbatim}
 El otro cambio que se efectuar\'a en {\em fstab} es el dispositivo
 para montar {\em /} . En principio ser\'a la partici\'on donde est\'e
 localizada {\tt test} pero al trasladar los cambios al cdrom
 deberemos indicar aqu\'\i\ {\tt hda, hdb, hdc} o {\tt hdd} seg\'un
 donde tengamos conectado el lector. Esto ser\'\i a, en un caso concreto, pasar de:
\begin{verbatim}
  /dev/hdb3    /    reiserfs   defaults     1 1
  /dev/hdc     /    iso9660    defaults     1 1
\end{verbatim}
Puede ser una buena idea escribir ambas l\'\i neas y comentar la
segunda, de cara a recordar que m\'as tarde deberemos pasar el
comentario a la primera linea para poder arrancar correctamente. Puede
observarse que el sistema de ficheros se adaptar\'a al nuevo
dispositivo rom, as\'\i\ que independientemente del formato de nuestra
unidad en disco duro (ext2, ext3, xfs, reiserfs...) el cdrom se quemar\'a con el est\'andar iso9660. Ya se ha advertido anteriormente que es importante tener soporte para \'el en el mismo kernel.

  \item Aumentar el tama\~{n}o de los {\em ramdisks}, a\~{n}adiendo en
  el fichero {\em lilo.conf}
\begin{verbatim}
  ramdisk = 35000
\end{verbatim}
dentro de la entrada que se corresponda con el arranque de la
partici\'on {\tt test}. No olvidemos ejecutar el comando {\tt lilo} para actualizar los cambios.

Este par\'ametro solo tendr\'a efecto para el arranque de la
partici\'on desde disco duro, m\'as tarde se detallar\'a d\'onde debe
incluirse esta linea para que tenga efecto en el arranque {\em live}.

\item Enlazar {\em mtab}. Este fichero se actualiza cada vez que se monta o desmonta un dispositivo, por lo tanto debemos poder modificarlo a\'un estando en el lugar donde linux lo buscar\'a (en {\em /etc}). ?`C\'omo hacer esto? Convirtiendo {\em mtab} en un enlace simb\'olico hacia {\em /proc/mounts}, fichero al cual empezaremos actualiz\'andole las fechas de acceso

\vspace{.1in}
\hspace{.3in}\colorbox{gray}{{\tt touch /proc/mounts}}

\hspace{.3in}\colorbox{gray}{{\tt rm -rf /etc/mtab}}

\hspace{.3in}\colorbox{gray}{{\tt ln -s /proc/mounts /etc/mtab}}

\vspace{.1in}
En algunos {\em scripts} aparecen las lineas

\begin{verbatim}
 # Clear mtab
 >/etc/mtab
\end{verbatim}

para reinicializar el fichero en cuesti\'on. 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\'a comentarlo (a\~{n}adiendo \# al inicio de la linea).

Es importante trabajar desde {\tt test} para generar los enlaces, puesto que si creamos los enlaces con rutas desde {\tt principal} (como {\em /test/var} o  {\em ./tmp/var}) la partici\'on {\tt test} no los reconocer\'\i a correctamente puesto que ella, al arrancar, tendr\'a {\em /var} montado en {\em /tmp/var} y no en {\em ./tmp/var} (partiendo de {\em /etc} o de {\em /test}).

  \item Convertir la unidad en acceso de s\'olo lectura es f\'acil puesto que en estos {\em scripts} de iniciaci\'on de remonta {\em /} para hacerla de lectura y escritura. Las lineas que se corresponden a esta operaci\'on deben ser algo parecido a

\begin{verbatim}
# 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 /
\end{verbatim}

que deber\'\i a sustituirse por

\begin{verbatim}
# 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 /
\end{verbatim}

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

\begin{verbatim}
# Start up swapping.
# action $"Activating swap partitions: " swapon -a -e
\end{verbatim}

Por regla general en estos {\em scripts} no hay ninguna referencia m\'as a
dispositivo de lectura y escritura. No obstante estar\'\i a bien tomar
paciencia y repasarlos de arriba a abajo. Generalmente estan muy bien
comentados -en ingl\'es- ahorr\'andonos muchos dolores de cabeza.


 \item Finalmente tendr\'a que generarse el {\em ramdisk} y su \'arbol de
 directorios para que pueda guardar todas las entradas en {\em /tmp} y {\em
 /var} que el sistema requiera\footnote{estos requerimientos los aportan las
 inicializaciones de los propios {\em scripts} de inicio.}. Podemos editar
 {\em /etc/rc.sysinit} o cualquier script que venga con nuestra distribuci\'on
 y al que se invoque en el arranque. 

Las siguientes lineas deber\'an incluirse almenos tras configurar el PATH, i.e. all\'a donde linux ir\'a a buscar los ficheros binarios {\tt mkdir} y {\tt mkfs} (entre otros) necesarios apra crear directorios y sistemas de archivo, respectivamente). Esta linea puede aparecer como
\begin{verbatim}
  # Set the path
  PATH=/bin:/sbin:/usr/bin:/usr/sbin
  export PATH
\end{verbatim}

Una buena forma de asegurarnos de no cambiar los permisos del {\em ramdisk} y mantener la coherencia de {\em mtab} es incluir estas lineas directamente a continuaci\'on de remontar {\em /} como s\'olo lectura.

   \begin{enumerate}
     \item crearemos el dispositivo en memoria y le daremos formato
\begin{verbatim}
action "Making ram0 " /sbin/mkfs.ext3  /dev/ram0
action "Mounting ram0" mount /dev/ram0 /tmp -o defaults,rw
\end{verbatim}

     \item crearemos el \'arbol de directorios
\begin{verbatim}
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
\end{verbatim}

    \item cambiaremos los permisos para poder escribir en ellos
\begin{verbatim}
action "Chmod 777 /tmp " chmod 777 /tmp
action "Chmod +t /tmp" chmod +t /tmp
\end{verbatim}

   \item haremos un nuevo dispositivo {\em ramdisk} y le copiaremos el contenido de {\em /dev}
\begin{verbatim}
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
\end{verbatim}

   \end{enumerate}
\end{enumerate}

Tras esto {\tt test} deber\'\i 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\'ogica y
no suponiendo que {\em tenemos algo que no lo hace funcionar}. Algunos {\em
  scripts} necesitar\'an llegar a cierta estructura de \'arbol (en {\em /var}
o {\em /tmp}) y en caso de que no lo hayamos generado en el dispositivo en RAM
nos devolver\'a un error. Simplemente a\~{n}adiendo y/o modificando las l\'\i neas del punto {\em b)} para creaci\'on de directorios podremos arreglar esto.

?`Por qu\'e no se ha hablado de {\em /proc}? Este
directorio contiene informaci\'on sobre lso procesos que corren en
nuestro equipo, pero ya por defecto se monta en memoria. Por esta
raz\'on -y no por otra- no deberemos encargarnos de \'el.

\vspace{.2in}
\hspace{.3in}{\bf\sc Arrancando un kernel con una imagen de disquete}

\vspace{.1in}
Para proceder con estos, los \'ultimos pasos para obtener el cdrom, es mejor reiniciar el sistema y trabajar desde {\tt principal} (siempre teniendo {\tt test} en {\em /test}). 

Para generar disquetes arrancables existen varios
m\'etodos. Quiz\'a el m\'as simple y efectivo sea obtenerlo
directamente del cdrom de alguna distribuci\'on. Generalmente aparecen
con nombres como {\em boot.img} o {\em bootdisk} y siempre tienen un
tama\~{n}o de 1,4 mega-octetos. De forma alternativa podremos
generarlo nosotros mismos.


\begin{itemize}
  \item hacer una copia del kernel

\hspace{1in}\colorbox{gray}{{\tt cp /boot/vmlinuz-$<$version\_del\_kernel$>$ /tmp/vmlinuz}}

  \item hacer la copia arrancable del cdrom en {\em /dev/$<$dispositivo\_cdrom$>$}

\hspace{1in}\colorbox{gray}{{\tt rdev /tmp/vmlinuz
/dev/$<$dispositivo\_cdrom$>$}}

\hspace{1in}\colorbox{gray}{{\tt ramsize /tmp/vmlinuz 20000}}

 \item formatear un disquete y copiar el kernel

\hspace{1in}\colorbox{gray}{{\tt mkfs -t ext2 /dev/fd0}}

\hspace{1in}\colorbox{gray}{{\tt dd if=/tmp/vmlinuz of=/dev/fd0}}
\end{itemize}

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

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt mount $<$fichero\_imagen$>$ $<$directorio\_de\_montaje$>$ -o loop -t vfat}}

\vspace{.1in}
En {\em $<$directorio\_de\_montaje$>$} deber\'\i a aparecernos
 almenos:
 una imagen binaria del kernel de linux ({\tt vmlinuz}), algunos
 ficheros binarios para los men\'us de pantalla y los ficheros que consideraremos importantes, {\tt ldlinux.sys} y
{\tt syslinux.cfg}. Deberemos editar el segundo para personalizarlo a
nuestro sistema. B\'asicamente deber\'a contener la etiqueta del
arranque y el nombre de la imagen, por ejemplo:
\begin{verbatim}
default linux

       label linux
       kernel vmlinuz
       root=/dev/<dispositivo_cdrom>
       ramdisk=35000
\end{verbatim}

Si estamos familiarizados con LiLO no nos ser\'a dif\'\i cil
configurar este fichero. La otra cosa importante es sustituir {\tt
vmlinuz} por la imagen que arranque  {\tt test} (y su fichero {\em initrd} en caso de que exista; ambos los encontraremos en
{\em /test/boot/}). En el ap\'endice {\em Salidas de
comandos y ficheros} podr\'as ver un caso concreto de este archivo\footnote{
cabe se\~{n}alar que pararlas pruebas en la partici\'on {\tt test}
deberemos indicar a la etiqueta {\tt root=} la partici\'on correcta.}. Ahora desmontaremos la imagen.

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt umount $<$directorio\_de\_montaje$>$}}

\vspace{.1in}
Y copiaremos esta imagen de disquete arrancable al directorio {\em
/test}. El kernel embebido aqu\'\i\ ser\'a el que arrancar\'a el sistema.

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

\hspace{.3in}\underline{AHORRANDO UNA SEGUNDA INSTALACI\'ON. COPIA DE CONTENIDOS}

Una variante de este esquema podr\'\i a darse cuando no hayamos cumplido
un proceso de instalaci\'on en {\tt test}. Tendremos que tener en
cuenta que podremos aprovechar la mayor parte de los directorios de la
partici\'on {\tt principal} (siempre y cuanto quepan en el directorio
{\em /test}). En el \'arbol de directorios, excepto {\em /usr}, el contenido de los dem\'as directorios no ser\'a cr\'\i tico. En 
{\em /test} podremos disponer la estructura copiando los directorios
desde {\tt principal} y arreglando los ficheros necesarios en {\em
/etc} .

Para generar los directorios en {\tt test}, por ahora vac\'\i a, podr\'\i amos ejecutar:

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt cd /test}}

\hspace{1in}\colorbox{gray}{{\tt mkdir root}}

\hspace{1in}\colorbox{gray}{{\tt mkdir mnt}}

\hspace{1in}\colorbox{gray}{{\tt mkdir proc}}

\hspace{1in}\colorbox{gray}{{\tt mkdir tmp}}

\hspace{1in}\colorbox{gray}{{\tt mkdir home}}

\hspace{1in}\colorbox{gray}{{\tt mkdir misc}}

\hspace{1in}\colorbox{gray}{{\tt mkdir opt}}

\hspace{1in}\colorbox{gray}{{\tt mkdir dev}}

\vspace{.1in}
E iniciamos la copia de contenidos con {\tt rsync}. Alternativamente podr\'\i amos usar el comando
{\tt cp -a}.

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt rsync -a /dev/* dev}}

\hspace{1in}\colorbox{gray}{{\tt mkdir lib}}

\hspace{1in}\colorbox{gray}{{\tt rsync -a /lib/* lib}}

\hspace{1in}\colorbox{gray}{{\tt mkdir bin}}

\hspace{1in}\colorbox{gray}{{\tt rsync -a /bin/* bin}}

\hspace{1in}\colorbox{gray}{{\tt mkdir sbin}}

\hspace{1in}\colorbox{gray}{{\tt rsync -a /sbin/* sbin}}

\hspace{1in}\colorbox{gray}{{\tt mkdir usr}}

\hspace{1in}\colorbox{gray}{{\tt mkdir etc}}

\hspace{1in}\colorbox{gray}{{\tt rsync -a /etc/* etc}}

\hspace{1in}\colorbox{gray}{{\tt mkdir boot}}

\hspace{1in}\colorbox{gray}{{\tt rsync -a /boot/* boot}}
%------------------------------------------------------------------
\subsection{Creando el cdrom}
Antes de empezar con el proceso de quemado es necesario
recordar que hay que modificar el fichero {\em /test/etc/fstab} para
indicarle a linux que el dispositivo root ahora no ser\'a la
partici\'on {\tt test} sino el cdrom (con iso9660).

Para disponer en un cdrom todos los contenidos que hasta ahora hemos modificado seguiremos los siguientes pasos:
\begin{itemize}
  \item crear la imagen iso9660 llamada boot.iso (situados en el directorio donde
  queramos generarla)

\hspace{.3in}\colorbox{gray}{{\tt mkisofs -R -b boot.img -c
boot.catalog -o boot.iso /test}}

  \item verificar la imagen iso, mont\'andola en algun directorio

\hspace{.3in}\colorbox{gray}{{\tt mount boot.iso $<$directorio\_de\_montaje$>$ -o loop -t iso9660}}

  \item quemar el CD

\hspace{.3in}\colorbox{gray}{{\tt cdrecord -v speed=$<$velocidad$>$ dev=$<$ruta\_del\_grabador$>$ boot.iso}}

  \item verificar el arranque desde cdrom, re-arrancando la computadora.
\end{itemize}

\subsection{\'Ultimos detalles}
Puede ser interesante, desde el punto de vista pr\'actico, 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\'afico, tama\~{n}o de los ramdisks, {\em etc...}

Por el momento el espacio disponible en un disquete no nos permite
poder embeber en \'el varios kernels de tama\~{n}o tradicional. No
obstante si se trabaja con sistemas con pocos requerimientos se
podr\'an arrancar varias im\'agenes {\tt vmlinuz}. El fichero {\em
syslinux.cfg} se maneja como el {\em lilo.conf} as\'\i\ que no
deber\'\i a darnos m\'as problemas. En el ap\'endice {\em Salidas de
comandos y ficheros} se adjunta un ejemplo.

Para mostrar un men\'u podemos a\~{n}adir, a la cabecera de {\em syslinux.cfg}, la linea
\begin{verbatim}
   display boot.msg
\end{verbatim}
donde {\em boot.msg} ser\'a 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\'us a partir de \'este, con las teclas de funci\'on. Estas configuraciones tambi\'en ir\'an a la cabecera de {\em syslinux.cfg}\footnote{en el ap\'endice {\em Salidas de comandos y ficheros} podeos ver un ejemplo del fichero completo.}.

Las posibilidades que brinda este cargador pueden embellecerse usando los 16 colores que cualquier targeta VGA soporta. A continuaci\'on se da un ejemplo de un men\'u que mostrar\'\i a por pantalla, en cada color, el n\'umero hexadecimal que lo codifica.
\begin{verbatim}
^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
\end{verbatim}
La estructura de estos ficheros es:
\begin{itemize}
  \item \begin{verbatim}^L \end{verbatim} limpia la pantalla. Es binario as\'\i\ que algun editor puede mostrarlo distinto a como aqu\'\i\ se muestra (con {\tt emacs}). Para asegurar que se est\'a tomando el car\'acter correcto lo mejor es hacerse con un fichero ya existente en cualquier liveCd y copiarlo.
   \item los colores se codifican con la secuencia
 \begin{verbatim}^O0x \end{verbatim}
donde {\tt x} es un d\'\i gito hexadecimal (del 1 al F); y los saltos de linea son
 \begin{verbatim}^O07 \end{verbatim}
\end{itemize}
El car\'acter con el que empiezan los c\'odigo hexadecimales no es el acento circunflejo, as\'\i\ que si probamos de escribir el texto anterior tal cual no funcionar\'a. Como se ha descrito, lo mejor es tomar ficheros ya existentes y copiar dichos c\'odigos.

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\'on verde que les sirve de logotipo) en nuestro sistema. Su {\tt gfxboot} permite dispone las opciones como un men\'u a todo color. Para m\'as detalles mejor consultar su {\em syslinux.cfg} .
