[[TranslatedPages]] [[TOC(Heading=Índice)]] = Añadir módulos de red al cliente OpenGnSys = Esta receta sirve para poder incluir módulos de red del Kernel del cliente !OpenGnSys y poder realizar correctamente la conexión al servidor. Con estas modificaciones se creará un nuevo cliente !OpenGnSys personalizado que puede adaptarse al hardware que no fuese reconocido durante arranque del cliente normal. '''Nota:''' Los ejemplos que describen este procesos se basan en la adaptación del arranque para ordenadores Apple iMac 21.5 con tarjeta de red Broadcom BCM57766, que no es reconocida por el cliente !OpenGnSys 1.0.5 basado en Kernel 3.8. == Identificar la tarjera de red del equipo == Debemos averiguar el modelo de la interfaz de red (NIC) de un ordenador que no ha sido reconocida por el cliente PXE de !OpenGnSys. En el caso de que ese equipo tenga GNU/Linux instalado, ajecutar: {{{ lspci | grep Ethernet }}} En el ejemplo, el dato obtenido en un iMac 21.5 es: {{{ 03:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM57766 Gigabit Ethernet PCIe (rev 01) }}} == Requisitos previos para reconstruir el cliente == Será necesario disponer de: * Ordenador o máquina virtual con Ubuntu Server que tenga exactamente la misma versión del kernel de nuestro cliente !OpenGnSys (en el caso del pendrive de arranque de los iMac, debe usarse Ubuntu Server 13.04 de 32 bits con kernel 3.8.0-19-generic). * Tener instalado los paquetes necesarios para compilar módulos, ejecutando {{{ sudo apt-get install -y linux-headers-$(uname -r) dkms build-essential }}} '''Nota:''' la orden "{{{uname -r}}}" se utiliza para conocer la versión exacta del kernel que se está utilizando. == Descargar código fuente de los drivers == Existen 2 posibilidades principales para compilar el módulo. === 1) Usar como base el código fuente del kernel === Si el problema del driver de red se soluciona en una revisión posterior del kernel, puede instalarse paquete del código fuente para usarlo como base para compilar el módulo. Debe ejecutarse: {{{ sudo apt-get install linux-source-VersiónKernel }}} En el caso del driver {{{tg3}}} para tarjetas Broadcom, el problema se soluciona en las últimas revisiones del kernel 3.8 y se puede instalar el paquete {{{linux-source-3.8.0}}}. '''Nota:''' tener en cuenta que esta solución requiere varios cientos de MB de almacenamiento, para descargar todo el código fuente del kernel y luego compilar el módulo necesario. === 2) Descargar el código fuente específico === Descargar de la página web del fabricante el código fuente específico para el driver requerido. '''Nota:''' se desaconseja utilizar esta opción para crear el módulo {{{tg3}}}, ya que la página web de Broadcom ofrece un código fuente para el driver que da errores de compilación con la versión 3.8 del kernel. == Compilar módulo con DKMS == El método más adecuado para compilar módulos independientes para el kenrel de Linux es utilizar DKMS, que utiliza como base los paquetes de código predefinidos para el núcleo actual. Los pasos a seguir son los siguientes: 1. Crear el directorio para el código fuente del módulo (en el caso del driver de red para iMac, el módulo es {{{tg3}}} con versión {{{3.128}}}): {{{ sudo mkdir /usr/src/Módulo-Versión }}} 2. Copiar o descomprimir en ese directorio el código fuente del módulo. 3. Crear en el directorio anterior el fichero {{{dkms.conf}}} para configuración de DKMS, con el formato: {{{ #!sh PACKAGE_NAME="Módulo" PACKAGE_VERSION="Versión" BUILT_MODULE_NAME[0]="Módulo" DEST_MODULE_LOCATION[0]=/CaminoInstalaciónMódulo AUTOINSTALL="yes" }}} El camino de instalación suele estar bajo {{{/kernel}}}, aunque también podría estar bajo {{{/updates}}} o {{{/extra}}} (para el driver {{{tg3}}}, el ''Camino'' es {{{/kernel/drivers/net/ethernet/broadcom}}}). 4. En algunos casos puede ser necesario "retocar" alguno de estos ficheros del directorio: {{{Makefile}}} o {{{modules-order}}}, para compilar solo el módulo requerido. 5. Compilar el módulo: {{{ sudo dkms build -m Módulo -v Versión }}} Si no hay errores, el módulo generado estará en el fichero {{{/var/lib/dkms/Módulo/Versión/VersiónKernel/Arquitectura/module/Módulo.ko}}}. == Reconstruir el cliente == El siguiente paso es reconstruir el fichero Initrd del cliente !OpenGnSys incluyendo el nuevo módulo generado. 1. Solo si usamos un lápiz USB con el Initrd, montar su sistema de archivos. 2. Crear un directorio temporal y descomprimir el Initrd del cliente !OpenGnSys: {{{ sudo mkdir /tmp/initrd cd /tmp/initrd sudo gzip -dc CaminoInitrd/oginitrd.img | cpio -im }}} 3. Copiar el fichero del módulo al lugar adecuado: {{{ sudo cp -va /var/lib/dkms/Módulo/Versión/VersiónKernel/Arquitectura/module/Módulo.ko lib/modules/VersiónKernel/CaminoInstalaciónMódulo }}} '''Nota:''' Atención al camino relativo donde copiar el módulo generado. 4. Reconstruir el Initrd: {{{ sudo find . | cpio -H newc -oa | gzip -9c >CaminoInitrd/oginitrd.img }}} 5. Puede borrarse el directorio temporal del Initrd y, en su caso, desmontar el lápiz USB. == Parámetros de arranque == Por último, deben retocarse los ficheros de arranque PXE para todos los equipos que deben cargar el driver específico, añadiendo el valor adecuado en la opción {{{ognetmodule}}}. '''Nota:''' en el caso de los iMac, estos equipos no pueden realizar el arranque por PXE, así que debe usarse un lápiz USB con un cargador GRUB que realice la carga inicial; por lo tanto, en vez de modificar el fichero correspondiente PXE, debe editarse de igual modo el fichero {{{grub.cfg}}} con la configuración de GRUB. Para modificar el arranque PXE realizar los siguientes pasos: 1. Aunque pueden editarse los ficheros de individualmente, la forma más adecuada de trabajar es crear una plantilla PXE que será asociada a los equipos que la requieran. Para crear una nueva plantilla PXE, debe copiarse a partir de una plantilla base, ejecutando: {{{ cd /opt/opengnsys/tftpboot/menu.lst/templates sudo cp -va PlantillaBase PlantillaNueva }}} '''Nota:''' Tener muy en cuenta el modo de trabajo de la plantilla base, bien usuario normal o bien administrador. 2. Editar el fichero PXE o la plantilla para incluir el parámetro {{{ognetmodule}}}, modificando la línea {{{kernel}}}: {{{ kernel ... ognetmodule=Módulo ... }}} '''Notas:''' * Si se modifica una plantilla PXE, esta línea debe terminar obligatoriamente con la cadena {{{INFOHOST}}}. * Si se usa un lápiz USB con GRUB en vez de PXE, la línea a modificar empieza por la palabra reservada {{{linux}}} en vez de {{{kernel}}}, pero la modificación es simialr. == Posibles problemas de carga del módulo == Se han localizado algunos problemas potenciales en la carga del nuevo módulo generado, por lo que esta sección presenta algunas soluciones conocidas. === Dependencia con otros módulos === Si el módulo generado tiene dependencias con otros módules que deben cargarse previamente, puede ser necesario retocar el proceso de arranque del cliente para cargar correctamente todos estos módulos. Para ello debe editarse usarse el proceso para retocar el Initrd del cliente y editar el fichero {{{scripts/ogfunctions}}} y modificar la función {{{ogLoadNetModule}}},- sustituyendo la línea completa que ejecuta la orden {{{insmod}}} por la siguiente: {{{ modprobe ${ognetmodule} }}} === Initrd y SquashFS con distinta versión de Kernel === El proceso completo de arranque de !OpenGnSys se compone de una fase inicial que carga los ficheros del Kernel Linux y su Initrd asociado (que contiene los módulos básicos para conectarse con el servidor) y un segundo sistema de ficheros SquashFS servido por la red con una distribución más completa para gestionar el cliente. Es importante tener en cuenta que puede que el módulo del Kernel que está en el Initrd puede no coincidir con el correspondiente al del 2º sistema de ficheros que se mezcla con SquashFS. En el caso de querer operar con un módulo actualizado tras finalizar el arranque del cliente, el fichero generado también tendría que copiarse en el fichero {{{ogclient.sqfs}}}, pero ésto no será necesario en la mayoría de los casos, puesto que el módulo se carga al principio del proceso de arranque.