Mostrando entradas con la etiqueta instalación. Mostrar todas las entradas
Mostrando entradas con la etiqueta instalación. Mostrar todas las entradas

5 de abril de 2010

Gentoo: Domesticando a la criatura (2/2)

conjuntoEntradas() {
  Gentoo: Domesticando a la criatura (2/2)
}

Configurando el kernel

Este es uno de los puntos clave el proceso de instalación y dónde parece que estemos en el punto más clave de la domesticación.
Aunque el kernel va a ser el centro de nuestro de sistema, ya que el funcionamiento básico del sistema y el resto de parte del sistema depende de éste, para mí no es el único, ya que el resto de configuraciones del proceso de instalación comentadas en el post 1, de esta serie, son de vital importancia a la hora de compilar y optimizar las múltiples herramientas que día día vamos ir metiendo le a la criatura y vamos a usarlas con cierta regularidad. No obstante el kernel coge mayor relevancia cuando nos encontramos configurándolo para una máquina con una función específica como podría ser un servidor con un rol determinado, pero en mi caso actual, es para una máquina de trabajo, así que lo que necesito son las herramientas que voy a ir necesitando para poder trabajar, experimentar y hacer el capullo el día a día.

Dejando de lado mis creencias, me leo el capítulo del handbook dedicado a la configuración del kernel, claro está ignorando la alternativa de utilizar genkernel.
Antes de contaros mis aventuras entre el enorme mundo de las opciones del kernel, quiero hacer especial mención a la frase: "Manually configuring a kernel is often seen as the most difficult procedure a Linux user ever has to perform. Nothing is less true -- after configuring a couple of kernels you don't even remember that it was difficult ;)", y solo indicar que el tío que ha escrito esto tiene mucha razón, después de mi primera configuración ahora me cuesta bastante poco reconfigurarlo para amoldarlo a mis necesidades.
Bueno vamos al lío, hacemos lo que dicen las instrucciones, es decir compilamos el menú de configuración y una vez dentro de él activamos, como buenos niños, lo que nos indican que es básico para que nuestro sistema, por lo menos, arranque. Posteriormente empecé a mirar casi de una en una las múltiples opciones que se pueden activar o modularizar o desactivar y por supuesto activando las en el caso que vea que carguen algún driver de mi hardware.
A lo largo de mi andadura por el mundo de las opciones del kernel, me veo obligado a, cuando no sé de que puñetas me estaban hablando, documentarme un poco para no ignorar esa opción a la ligera y entre esto y algunos aspectos de redes que ya sé de que iban a raíz de documentarme cuando configuré los trunks en las empresa y descartando las opciones que hacen referencia a hardware muy concreto, por ejemplo de sistemas embedidos, no me costo mucho más de una tarde y media, enteras, en hacer mi primera configuración después de varios años de haber tocado esta distribución y no haber vuelto a jugar, desde entonces, con un kernel de Linux.

Bueno finalmente configuré mi kernel y aprendí varias cosas, entre ellas:
  • Pinceladas de ciertos aspectos de la arquitectura de un sistema Linux actual, a raíz de documentarme con ciertas opciones que de un inicio no tenía ni p... idea de que iban.
  • El gran número de opciones que tiene el kernel 2.6 de Linux y gracias a ellas poder optimizar tu sistema según tus necesidades.
  • Mientras lo configuraba me tuve que enterar de que implicaciones tenía modularizar o activar directamente, para tomar la mejor decisión; sobre este hecho leía que habían detractores de cada una de las opciones, unos dicen que mejor modularizar porque así tu Kernel ocupa menos memoria RAM y por otra parte los detractores de modularizar dicen que cargando los módulos al no estar contiguos en el espacio en memoria ocupado por el kernel (cargado durante el inicio del sistema) los accesos son más lentos, así que yo he decidido activar todo lo que quiero que siempre esté cargado porque a estas alturas con la de RAM que les metemos a los sistemas no me va de que el kernel ocupe unos cuantos kilobytes más y modularizar lo que voy a usar de manera esporádica así solo cargo cuando lo necesite no siempre. ¿de cual sois vosotros detractores?
Hasta la próxima enfermos.

6 de marzo de 2010

Instalando Marvell Yukon Ethernet Controller en Ubuntu

Después de un tiempo sin poder dedicarme a dejar bien configurado mi Netbook el cual ya compré hace algún tiempo, finalmente me he decidido dedicarle un rato, hoy mismo, para dejar funcionando la tarjeta ethernet integrada en el sistema operativo que le puse desde el primer momento que lo tuve, que es concretamente un Ubuntu 9.10 Netbook remix. Si ya sé que alguno podéis llegar a pensar que como es que no lo hice desde un primer momento, pues esto se reduce a básicamente 3 aspectos:
  1. Falta de preferencia de mi tiempo libre para dedicarle a esto.
  2. El aspecto 1 se debe a que la tarjeta Wireless Broadcom si que fue detectada en la instalación base.
  3. El aspecto 2 queda justificado por los 2 objetivos por el cual lo compré, que fueron tener menos pereza en cargar un ordenador a cuestas y para que en los momentos de mayor pasividad no me diera tanta pereza estar delante de un ordenador; este último objetivo implícitamente requiere el uso de la wireless, ya que en esos momentos es cuando necesito estar en el sofa o en la cama, por lo que los cables me sobran, además debido a esto inicialmente no me día cuenta que el sistema operativo no la había detectado.
Bueno ya no me enrollo más y paso a explicar la aventurita de instalar el driver, que me ha llevado un rato algo largo, pero como siempre a parte de ahora tener la tarjeta ethenet funcionando me ha llevado a aprender, como siempre, alguna cosa más.

Buscando el dispositivo
He empezado buscando el fabricante del dispositivo que lleva el Netbook porque aunque alguno de vosotros penséis que como es que no podía saberlo, pues básicamente se debe a que cuando compré el Netbook no miré concretamente que tarjeta ethernet llevaba.
Esto fue fácil de solucionar buscando en la Web de HP el modelo y viendo con que hardware se comercializaba; esta vez ha sido fácil ya que en el caso de la ethernet solo habían utilizado un fabricante y modelo, concretamente se trata de una Marvell Yukon Gigabit Ethernet.

Buscando el driver
Aunque parezca una parida, resulta que encontrar el driver apropiado para linux no lo ha sido tanto, por tres motivos:
  1. En los repositorios de paquestes de Ubuntu no hay o no he encontrado un driver; por lo que se jodió la instalación más fácil y rápida a la que podía optar.
  2. HP no ofrece drivers para linux para este Netbook.
  3. Resulta que los drivers te los puedes descargar de dos lugares, de SysKonnect y de Marvell, siendo distintos.
Bueno, así que me descargo los dos el SysKonnect y el de Marvell.

Analizando los drivers
Una vez descargados, que en el caso de Marvell he descagado el que indica para kernels de la versión 2.6 pero con una coletilla que pone "Fedora", les he echado un vistazo rápido y ya he visto que el de Marvell es de una versión superior, concretamente la 10.84.3.3 frente a la 10.70.1.3 de SysKonnect.

Después he leído detalladamente el README del driver de Marvell y ver que cumplía con todos los requisitos de instalación, he visto que hay dos modos de instalación, uno llamado "Modo de Instalación" y otro "Modo de Generación de Parche"; por lo que he leído más adelante en mi caso lo que quiero es instalarlo no parchear un kernel para que luego el driver quede integrado en las fuentes de este y pueda ser distribuido con este driver añadido.

Una vez ya he tenido claro el proceso de instalación he decidido echarle un ojo al README del drivers de SysKonnect y con un simple vistazo vemos que son iguales; así que dando se esta divergencia, claro está que he optado primero por probar con el de Marvell que es de versión superior.

Instalando los drivers
La primera prueba
Lo primero que he probado es lo más sencillo que uno puede hacer, que es ejecutar las instrucciones y ver si todo funciona y no se genera ningún problema.

Como el resultado no ha sido satisfactorio, he hecho lo mismo con de SysKonnect y el resultado ha sido el mismo, así que va a tocar mirar los errores generados.

Chequeando los errores
En ese momento he empezado a mirar si los errores eran parecidos en un driver y en el otro y efectivamente lo eran así que me quedo con el Marvell definitivamente, ya que es de versión superior como ya he comentado anteriormente.

El primer error que me ha aparecido al lanzar la instalación

$ sudo ./install.sh

parecía que era un problema del código del script de instalación, pero después de buscar un poco google, he encontrado en un post, que se soluciona fácilmente cambiando el intérprete de comandos indicado en el script de "#!bin/sh" a "#!bin/bash" y el error que daba de que la sintaxis era incorrecta para un "(" después de la declaración de la primera función del fichero "functions", incluido con los ficheros de instalación, se solucionaba.

Una vez solucionado este pequeño mal entendido he vuelto a ejecutar la instalación y me he encontrado con un error que indicaba que no encontraba las fuentes del kernel, ya que lo que va a hacer es recompilar el driver para el kernel que se esté usando. He empezado mirando el synaptics y he visto que si tenía instalado las fuentes del kernel (los headers) así que algo pasa que no los encuentra.
A raíz de eso, he mirado un poco más específicamente y he visto que lo que necesita es generar un link en /usr/src llamado linux que apunté a los headers del kernel que estas corriendo, por lo que manos a la obra:

$ sudo ln -s /usr/src/linux-headers-2.6.31.19 /usr/src/linux

Después de esto, volvemos a probar y el resultado es que nada que continua fallando, indicando que o que las fuentes están corruptas o que no coinciden con la versión del kernel que se está ejecutando, así que ejecuto el siguiente comando para ver que versión estoy ejecutando y poder comparar a que versión de las fuentes he creado el link

$ uname -r
2.6.31-19-generic

Así que la he cagado de dos posibilidades que habían (ya sabía que estaba utilizando la 2.6.31-19, por lo que los headers de versiones anteriores los había descartado), he linkado con la que no era ,así que he cambiado el link

$ sudo rm /usr/src/linux
$ sudo ln -s /usr/src/linux-headers-2.6.31.19-generic /usr/src/linux

De nuevo he vuelto a ejecutar y otro vez ha fallado, viendo que estaba sucediendo he visto que ahora lo que no ecuentra es las fuentes del kernel pero esta vez accediendo desde "/lib/modules/2.6.31-19-generic/source", así que viendo que hay en ese directorio, veo que "source" no existe y ¿porque no?, pues no lo sabía pero después de ver que haya en ese directorio he visto que había un link llamado "build" que apuntaba a "/usr/src/linux-headers-2.6.31-19-generic", así que he decidido probar de linkar "source" al mismo lugar

$ sudo ln -s /usr/src/linux-headers-2.6.31.19-generic /lib/modules/2.6.31-19-generic/source

Y de nuevo he vuelto a probar y esta vez sí, se ha compilado, instalado y cargado el módulo en el kernel.

Conclusiones
Con todo esto he aprendido a que tampoco están difícil compilar e instalar un dirver para linux si el script esta bien hecho, solo tienes que tener un compilador (lo más habitual es el gcc), las fuentes del kernel que estas ejecutando y los links correctos a los directorios donde se encuentran las fuentes.
Por cierto el módulo se llama sk98lin, por si alguien en algún momento se necesita descargarlo o cargarlo manualmente.

Hasta la próxima enfermos.

6 de febrero de 2010

Gentoo: Domesticando a la criatura (1/2)

conjuntoEntradas() {
  Gentoo: Domesticando a la criatura (1/2)
}


Después de meteros el rollo, en el post anterior, de como empecé mis aventuras con la distribución Gentoo, voy a contar, como ya anticipé, las aventuras que voy viviendo con mi retorno.

La instalación base
Después de descargar el live CD y quemarlo (aquí no doy explicaciones, ya que sería ridículo), empecé la instalación de la criatura en mi máquina.

Enciendo la maquina, meto el CD y arranco desde él. Una vez ya se ha cargado el Linux del live CD empiezo a seguir los pasos que se especifican en el handbook.Voy haciendo lo que pone y a la vez entendiendo lo que voy haciendo, es decir nada de ejecutar instrucciones una tras otra sin saber que puñetas hacen, y entonces me topo con el primer punto que me toca documentar me un poco para conseguir una criatura bien domesticada.
Configurando los flags del GCC

Leo el párrafo del handbook y la breve explicación de unos cuantos de los flags ya me empieza a despertar las ansias de saber más de cada uno de ellos y de los valores que se les pueden dar por tal de domesticar la criatura a mí máquina y así conseguir que todo el software que compile, que es la mayoría del que se instala desde el portage de Gentoo, esté lo más optimizado para mi propia máquina.
Para ello voy a la documentación del propio gcc y veo que hay mucho que leer, como no dispongo de tanto tiempo, y el objetivo actual no es conseguir ser el un gurú del gcc, leo con especial atención el capítulo dedicado a los flags de optimización para la arquitectura i386 y x86-64, a la que pertenece mi máquina.
Después de leerme el capítulo, y con la intención de domesticar la criatura lo mejor posible decido indicar al compilador que lo que compile lo haga exclusivamente para mi arquitectura (-mtune=native) además de activar otros flags y darles el mismo valor que el handbook recomienda.
Configurando los USE flags

Después de tener al domador configurado (el gcc) toca configurar los USE flags. Los USE flags son un conjunto, bueno mejor dicho un enorme conjunto, de flags que se activan o se desactivan asignando los a la variable de entorno USE, bueno concretamente también hay otros ficheros de configuración donde indicarlos pero en la fase de instalación podemos ignorarlos y dejarlos para cuando ya estemos en la fase de afinamiento del sistema.
Estos flags son utilizados por el portage de Gentoo para especificar la configuración, funciones adicionales y/o librerías concretas a utilizar por parte de las funcionalidades del paquete a instalar.
Hay USE flags genéricos, es decir que indican lo mismo para los distintos paquetes que los soportan y otros que en función del paquete se producen resultados algo distintos. A raíz de esto y del gran número de flags que hay es difícil desde la instalación inicial activar y desactivar todos los que realmente deseamos ya que revisar todos los flags de todos los paquetes básicos que el sistema necesita puede ser un tarea bastante tediosa, además cuando activas ciertos flags se añaden nuevos paquetes que a su vez pueden tener flags los cuales no habían aparecido en la lista de paquetes a instalar que anteriormente teníamos.
Por mi parte considero que la mejor opción es revisar por encima los flags que hay, especialmente los genéricos o los que veamos que puedan influir en el core del SO y posteriormente ya afinaremos activando y desactivando los flags a medida que vayamos instalando nuevos paquetes, y en el caso que se active alguno que no se había activado el portage ya nos indicará que tiene que recompilar el paquete.
Para concluir, solo indicar que hay flags excluyentes, es decir que si se activa uno otro tiene que estar desactivado o sin indicar (entonces es como desactivado pero no se está indicando de manera forzosa) y también se puede dar el caso que al activar ciertos flags sea necesario recompilar ciertos paquetes que a raíz de esto se provoque una dependencia cíclica entre ciertos paquetes, teniendo que resolverla manualmente debido a que el sistema del portage (comando emerge) no puede resolverlo de manera autónoma, así que nos va a tocar recompilar individualmente uno de los paquetes activando y desactivando de manera temporal los flags que provocan la dependencia cíclica.

Hasta la próxima enfermos.