\newpage
\pagestyle{empty}
\begin{latexonly}
\ifpdf
 \begin{figure}[htbp]
 \includegraphics[bb = -300 230 0 0, scale=.9]{./TuXes/linux_embedded.jpg}
 \end{figure}
 \vspace{5in}
\else
 \begin{figure}
       \scalebox{0.8}{\includegraphics[-320,720][0,0]{./TuXes/linux_embedded}}
 \end{figure}
\fi
\hfill\line(1,0){400}
\end{latexonly}
\topmargin 1in
\section{ROMs para arranque sin discos}
\begin{latexonly}
\line(1,0){400}
\newpage
\end{latexonly}
\topmargin 0in
\pagestyle{fancy}
%========================cita===============================================
\begin{latexonly}
\hspace{1in}\textcolor{blue_omosix}{{\em There is only one satisfying way to boot a computer.}}

\hspace{4in}\textcolor{blue_omosix}{{\em J. H. Goldfuss }}
\vspace{0.5in}

\end{latexonly}
%===========================================================================
Llegados a estas p\'aginas habr\'a de comprenderse que al carecer de discos,
los nodos {\em diskless} deben disponer de lo necesario para su arranque en
otra computadora, y en el tipo de sistemas que aqu\'\i\ se detallan esta informaci\'on
estar\'a organizada en un -o varios- nodos servidores.

Esta secci\'on no cubre el procedimiento de configuraci\'on de los servicios,
que debe haberse visto durante la lectura de la anterior. Aqu\'\i\ se trata la
necesidad de aportar al cliente ciertos paquetes de informaci\'on -en forma de
roms- para que sea capaz de cumplir con su parte en el di\'alogo de comunicaci\'on que finalizar\'a con su arranque.
Cabe insistir una vez m\'as que el cliente en ning\'un 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.

\vspace{.2in}
Haciendo memoria. El cliente -como cualquier otra computadora- arrancar\'a su BIOS
al ser alimentado. Tras la detecci\'on de memoria y tambi\'en su tarjeta de
red se producir\'a la interrupci\'on de BIOS {\tt INT 19H} que dirigir\'a su
esfuerzo en encontrar informaci\'on que le permita arrancar a trav\'es del
nic instalado. En este momento es cuando el servidor debe estar atento para prestar la
{\bf primera rom}, correspondiente al servicio RPL\footnote{Si el nic dispone
  de socket para chip EPROM se podr\'a colocar esta rom en \'el, alibiando al
  servidor del servicio RPL.}.

La {\bf segunda rom} es necesaria durante la puesta en marcha del tercer
servcio, el TFTP. Se utilizar\'a este protocolo para descargar y arrancar un kernel
desdel servidor, pero este kernel debe estar modificado -no sirve directamente
un fichero {\tt bzImage}, resultado de una compilaci\'on con {\tt make bzImage}-.
%------------------------------------------------------
\subsection*{Arranque del cliente desde chip EPROM}
Los pasos necesarios para este proceso son los siguientes:
\begin{itemize}
  \item comprobar que la tarjeta de red dispone de socket para inserirle
  un chip; ser\'a el se\~{n}al que confirma que soporta arranque por RPL.
  \item en el caso de no querer situar la rom de RPL en un servidor ser\'a necesario adquirir un chip {\em bootp rom} compatible con la tarjeta. Lo proporciona el fabricante.
  \item generar una imagen ROM v\'alida con el modelo de tarjeta.
  \item quemar dicha imagen en el chip -si usamos esta opci\'on- o situarla en
  el servidor y configurar el servicio.
  \item generar una {\em tagged image} del kenel para poder arrancarla con la
  ROM, situarla en el servidor y configurar el servicio.
\end{itemize}

Lo que tiene que entenderse en el tercer punto es que la rom contiene
diferencias para cada tarjeta, o mejor dicho, para cada {\em chipset} de
tarjeta de red. As\'\i\ 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\'as engorroso que borrar y grabar
un disquete).

%------------------------------------------------------
\subsection*{Arranque del cliente desde disquete}
El arranque realmente no difiere en exceso, puesto que podemos verlo
simplemente como una diferente ubicaci\'on 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 {\bf Etherboot}
por poner a nuestro alcance un sistema tan pr\'actico para hacer nuestras
primeras configuraciones: poner la imagen en un disquete.

La ventaja que esto aporta es b\'asicamente que es un proceso realizable en la
mayor\'\i a de las computadoras, siempre que dispongan de conexi\'on a
internet y de disquetera. Con este sistema podemos:
\begin{itemize}
  \item hacer nuestras configuraciones desde disquete y preparar una rom
  totalmente operativa para volcarla en memoria EPROM\footnote{Si trabajamos
  con imagenes rom en el servidor podremos prescindir de disquetes, puesto que
  entorpecer\'\i a y ralentizar\'\i a el proceso. para cargar la nueva configuraci\'on solo ser\'\i a
  necesario matar al demonio {\tt rpld} y volverlo a iniciar}.

  \item o dejar nuestros nodos clientes con la disquetera y arrancarlos siempre desde disquete.
\end{itemize}

La opci\'on m\'as elegante es sin duda la primera, puesto que si realmente el cometido
que nos ha hecho llegar aqu\'\i\ han sido los nodos minimalistas, ?`qu\'e
menos que prescindir de las disqueteras, su cable de alimentaci\'on y el de
datos?

%------------------------------------------------------
\subsection*{Generando imagen para RPL}
Como no pod\'\i a ser de otra manera la comunidad del software libre pone a
nuestra disposici\'on un sistema en extremo asequible e intuitivo para la
generaci\'on de las susodichas im\'agenes rom.

Existen dos propuestas, ambas se encuentran en SourceForge:
\begin{itemize}
  \item Etherboot\footnote{{\tt
  \htmladdnormallink{http://www.etherboot.org/}{http://www.etherboot.org/}}},
  que se sirve de drivers insertados en la imagen.

  \item Netboot\footnote{{\tt
  \htmladdnormallink{http://netboot.sourceforge.net/}{http://netboot.sourceforge.net/}}},
  que dispone los drivers en un paquete.

\end{itemize}

Explicaremos con m\'as detalle cada una de estas propuestas, analizando tambi\'en el benecifio que en cada caso puedan aportar a nuestro sistema.

\vspace{.2in}
\hspace{0.3in}{\Large\bf\sc i - Etherboot}

\vspace{.1in}
\footnotesize El proyecto Etherboot dispone de un apartado sobre
documentaci\'on (en ingl\'es, como es de suponer). Los procedimientos
explicados a continuaci\'on pueden ampliarse en su web, aunque en esencia
puede resumirse todo ello de la forma que sigue.

\vspace{.1in}

\normalsize
?`C\'omo puedo obtener una imagen ROM?
\begin{itemize}
  \item Marty Connor ha trabajado en una versi\'on en linea para poder
  bajarnos la imagen para nuestro modelo espec\'\i fico de {\em
  chipset}. Puedes encontrarlo en su proyecto ROM-o-matic for
  Etherboot\footnote{\htmladdnormallink{http://rom-o-matic.net/}{http://rom-o-matic.net/}}.
   \item o podemos compilar nosotros mismos la imagen.
\end{itemize}

El mecanismo que genera la imagen es el mismo, es decir, romomatic simplemente
llama a la aplicaci\'on etherboot, con las opciones marcadas, a trav\'es
de un {\em script}. Por esa raz\'on -y pensando en simplificar siempre las
cosas- aqu\'\i\ se aboradr\'a el caso desde {\em romomatic}. En caso de querer
hacer las cosas por propia cuenta habr\'a que enterarse bien de los
par\'ametros de la aplicaci\'on\footnote{\htmladdnormallink{http://etherboot.sourceforge.net/doc/html/userman-3.html}{http://etherboot.sourceforge.net/doc/html/userman-3.html}}.

 En {\em rom-o-matic.net} existen varias versiones, es recomendable
utilizar la versi\'on estable -{\em production release}-. Un hiperenlace
lleva a la p\'agina donde hay que introducir:
\begin{enumerate}
  \item las especificaciones del chipset,
  \item el medio desde donde la imagen ser\'a le\'\i da -chip, disquete,
  imagen en servidor-,
  \item y configuraciones opcionales -{\em temporizadores, etc.}-.
\end{enumerate}

Finalmente pulsar {\tt Get ROM} para terminar bajando la imagen.
Las im\'agenes preparadas para disquete hay que copiarlas con el comando

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt cat eb-5.0.8-tu\_nic.lzdsk > /dev/fd0}}

\vspace{.1in}
donde {\tt /dev/fd0} refiere a nuestra disquetera y {\tt eb-5.0.8-tu\_nic.lzdsk} es la eom.

\vspace{.2in}
En este proceso pueden surgirte las siguiente dudas, que como no, tienen su respuesta.
\begin{itemize}
  \item ?`qu\'e modelo de {\em chipset} tiene mi tarjeta?
  \item ?`est\'a soportado por Etherboot?
\end{itemize}

El modelo de {\em chipset} viene especificado por un n\'umero que puede
conseguirse de diferentes maneras. Si no aciertas a conseguirlo con la
documentaci\'on que la tarjeta pueda llevar ser\'\i a adecuado hacer uso de
los comandos, como superusuario ({\em root}):

\vspace{.1in}
\hspace{1in}\colorbox{gray}{{\tt lspci}}

\hspace{1in}\colorbox{gray}{{\tt cat /proc/bus/pci/devices}}

\vspace{.1in}
Puedes encontrar un ejemplo de su salida en el ap\'endice referente a {\em Salidas de comandos y ficheros}.
Sobre si est\'a soportado, y para conseguir siempre resultados acorde con la
versi\'on vigente de Etherboot, debe consultarse el hiperenlace de la p\'agina
de generaci\'on de imagenes de ROM-o-matic sobre los PCI IDs soportados.

\vspace{.2in}
\hspace{0.3in}\underline{{\Large\bf\sc ii- Netboot}}

\vspace{.1in}
\normalsize
\textcolor{red}{?`Quieres redactar este apartado? !`Env\'\i amelo!
  mikel@akamc2.net . GRACIAS}
%------------------------------------------------------
\subsection*{Generando la rom para {\em tagged image}}
La informaci\'on contenida en una imagen de kernel {\em normal} -tipo {\tt
  bzImage}- no es suficiente para que pueda cargarse por red.
Pero esto no supone ning\'un problema, el usuario dispone de las herramientas
  {\tt mknbi} que permiten {\em taggear} estos ficheros para hacerlos capaces
  de ello.

As\'\i\ pues el resultado de aplicar las modificaciones de {\tt mknbi-linux}
al fichero {\tt bzImage} resultado de la compilaci\'on de las fuentes de linux
en el nodo que queramos arrancar por red, se llama {\em tagged image}. A
efectos de usuario no supone ninguna diferencia con una imagen sin modificar.

\vspace{.1in}
Los paquetes necesarios para proceder de esta manera contienen unas
aplicaciones llamadas{\tt mknbi-$<$so$>$} donde {\em so} refiere al sistema
operativo que queramos arrancar. Nos centraremos en la utilidad {\tt
  mknbi-linux}.

?`Qu\'e necesita {\tt mknbi} para funcionar? Evidentemente los par\'ametros obligados son el nombre de la imagen a modificar y el nombre de la iamgen de salida. Una posible llamada podr\'\i a ser

\vspace{.1in}
\hspace{.5in}\colorbox{gray}{\tt mknbi-linux --format=nbi --ip=rom  --output=/tftpboot/vmlinuz-metrakilate}

\hspace{.5in}\colorbox{gray}{\tt --rootdir=/tftpboot/metrakilate /usr/src/linux/arch/i386/boot/bzImage}

\vspace{.1in}
Una vez m\'as se enfatiza en el hecho que para un pleno conocimiento de la
herramientas ser\'a m\'as \'util consultar los manuales que incorpora, o la
documentaci\'on que se dispone en su web.

Como se ve es sencillo de utilizar. Con un poco de soltura tambi\'en se pueden hacer men\'us que
gestionen la carga de uno u otro kernel con pantallas de men\'us tipo {\em
  ncurses} mediante {\tt mknbi-mgl} y un lenguaje de programaci\'on semejante
a Pascal, lo que es una opci\'on bastante profesional para entornos de
producci\'on.

Sobre la aplicaci\'on cabe decir que es necesario pasarle la ruta {\tt
  nfsroot} -correspondiente al par\'ametro {\tt rootdir}- que indica de donde
  importar la ra\'\i z {\em /}. En el caso de no
pasarse este par\'ametro existe una cosntante dentro de {\em
  /usr/src/linux/fs/nfs/nfsroot.c} que indica de donde ser\'a cargado el
ra\'\i z. Por defecto es {\em /tftpboot/$<$direccion\_IP$>$}.


