Linux From Scrach (Parte 2 - Configurando el sistema)

Seguimos creando nuestra propia distribución GNU/Linux con LFS como he prometido.

En esta parte me he extendido bastante mas, ya que los pasos a seguir son muy importantes, y el fallo en alguno de ellos, podría conllevar a empezar desde cero.

Configuraremos un buen entorno de trabajo creando dos nuevos archivos de inicio para el shell bash. Mientras está conectado como usuario lfs, introducimos el siguiente comando para crear un nuevo .bash_profile

cat > ~/.bash_profile << "EOF"
exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
EOF

Cuando se inicia sesión como usuario lfs, el shell inicial suele ser un shell de inicio de sesión que lee el /etc/profile del sistema (probablemente contenga algunas configuraciones y variables de entorno) y luego el .bash_profile. El comando exec env -i.../bin/bash en el archivo .bash_profile reemplaza el shell en ejecución con uno nuevo por un entorno completamente vacío, excepto por las variables  HOME, TERM, y PS1.
Esto asegura que no haya riesgos indeseados y potencialmente peligrosos. Las variables de entorno del sistema, se filtran al entorno de compilación. La técnica utilizada aquí logra el objetivo de garantizar un entorno limpio.
La nueva instancia del shell, es un shell que no es de inicio de sesión, ya que no leerá los archivos /etc/profile o .bash_profile, sino que leerá el archivo .bashrc en su lugar. Por lo que vamos a crear el archivo .bashrc ahora:

cat > ~/.bashrc << "EOF"
set +h
umask 022
LFS=/mnt/lfs
LC_ALL=POSIX
LFS_TGT=$(uname -m)-lfs-linux-gnu
PATH=/tools/bin:/bin:/usr/bin
export LFS LC_ALL LFS_TGT PATH
EOF

Finalmente, para tener el entorno completamente preparado para construir las herramientas temporales, obtendremos el perfil de usuario recién creado, gracias a las siguiente línea de instrucción:

source ~/.bash_profile

Muchas personas quisieran saber de antemano aproximadamente cuánto tiempo lleva compilar e instalar cada paquete.
Debido a que Linux From Scratch se puede construir en muchos sistemas diferentes, es imposible proporcionar estimaciones de tiempo precisas, ya que depende de la RAM instalada, tipos de discos duros, núcleos del procesador, etc...
El paquete más grande (Glibc) tardará aproximadamente 20 minutos en los sistemas más rápidos, pero podría tomar hasta: ¡tres días en sistemas más lentos! En lugar de proporcionar los tiempos reales, se usará la medida de la Unidad de construcción estándar (SBU).
La medida SBU funciona de la siguiente manera. El primer paquete que se compilará de este libro es Binutils. El tiempo que lleva compilar de este paquete es lo que se conocerá como la Unidad de construcción estándar o SBU. Todos los demás tiempos de compilación se expresarán en relación a éste como referencia.
Para muchos sistemas modernos con múltiples procesadores (o núcleos), el tiempo de compilación de un paquete se puede reducir realizando una "creación paralela" configurando una variable de entorno o diciéndole al programa make cuántos procesadores están disponibles. Por ejemplo, un Intel Core2Duo puede admitir dos procesos simultáneos con:

export MAKEFLAGS='-j 2'

 o especificando cada vez que ejecutemos la instrucción make:

make -j2

Hay dos pasos en la construcción de este sistema mínimo:

1. Construir una nueva cadena de herramientas independiente del host
   (compilador, ensamblador, enlazador, bibliotecas y algunas utilidades útiles). 
2. Usar esta cadena de herramientas para construir las otras herramientas esenciales. (Por lo que es imperativo no saltarse ningún paso, y que no haya ocurrido ningún problema en el paso anterior).

Antes de continuar, tenga en cuenta el nombre de la plataforma de trabajo. Una forma simple de determinar el nombre del triplete objetivo es ejecutar el script config.guess que viene con el origen de muchos paquetes. Desempaquete las fuentes de Binutils y ejecute el script: ./config.guess y observe el resultado. Por ejemplo, para un procesador Intel de 32 bits, la salida será i686-pc-linux-gnu. En un sistema de 64 bits será x86_64-pc-linux-gnu.

También tendremos que tener en cuenta el nombre del enlazador dinámico de la plataforma, a menudo denominado cargador dinámico (no debe confundirse con el enlazador estándar ld que forma parte de Binutils). El enlazador dinámico provisto por Glibc encuentra y carga las bibliotecas compartidas que necesita un programa, prepara el programa para ejecutarlo y luego lo ejecuta. El nombre del enlazador dinámico para una máquina Intel de 32 bits será ld-linux.so.2 (ld-linux-x86-64.so.2 para sistemas de 64 bits). Una manera segura de determinar el nombre del enlazador dinámico es inspeccionar un binario aleatorio desde el sistema host ejecutando: readelf -l | intérprete grep y tomando nota de la salida. La referencia autorizada que cubre todas las plataformas está en el archivo shlib-versions en la raíz del árbol de fuentes de Glibc.

Ajustar el nombre de la plataforma de trabajo, cambiando el campo "proveedor" en el enlazdor dinámico de trabajo por medio de la variable LFS_TGT, así nos aseguramos que la primera compilación de Binutils y GCC produzca un enlazador cruzado (cross-linker) y un compilador cruzado (cross-compiler) compatible.
 
En lugar de producir binarios para otra arquitectura, el enlazador cruzado y el compilador cruzado, producirán binarios compatibles con el hardware actual.

• Las bibliotecas temporales se compilan de forma cruzada. Porque un compilador cruzado por su naturaleza no puede depender de nada de su sistema host, este método elimina la contaminación potencial del sistema objetivo, al disminuir la posibilidad de que los encabezados o bibliotecas del host se incorporen a las nuevas herramientas. La compilación cruzada también permite la posibilidad de compilar bibliotecas de 32 bits y de 64 bits en hardware de 64 bits.
• La manipulación cuidadosa de la fuente GCC le dice al compilador qué enlace dinámico objetivo se usará.

Binutils se instala primero porque las ejecuciones de configuración de GCC y Glibc, realizan varias pruebas de características en el ensamblador y el enlazador para determinar qué características del software habilitar o deshabilitar. Esto es más importante de lo que uno podría darse cuenta primero. Un GCC o Glibc configurado incorrectamente puede resultar en una cadena de herramientas sutilmente rota, donde el impacto de tal rotura puede no aparecer hasta casi el final de la construcción de una distribución completa (como me ha ocurrido a mi en ocasiones anteriores).  
Por lo general, un fallo en la serie de pruebas resaltará este error antes de realizar demasiado trabajo adicional, así que realizaremos pruebas para detectar y corregir antes de continuar con el siguiente paso.

Binutils instala su ensamblador y vinculador en dos ubicaciones, /tools/bin y /tools/$ LFS_TGT/bin. Las herramientas en una ubicación están vinculadas entre sí. Una faceta importante del enlazador es su orden de búsqueda de la biblioteca. Información detallada se puede obtener de ld pasándole el indicador --verbose. Por ejemplo, un ld --verbose | grep SEARCH ilustrará las rutas de búsqueda actuales y su orden. Muestra qué archivos están vinculados por ld compilando un programa ficticio y pasando el modificador --verbose al enlazador. 
Por ejemplo, gcc dummy.c -Wl, - verbose 2> & 1 | grep succeeded mostrará todos los archivos abiertos con éxito durante el enlace.
El siguiente paquete instalado es GCC. Un ejemplo de lo que se puede ver durante su ejecución de configuración es:

checking what assembler to use... /tools/i686-lfs-linux-gnu/bin/as
checking what linker to use... /tools/i686-lfs-linux-gnu/bin/ld
Varios de los paquetes están parcheados antes de la compilación, pero solo cuando el parche es necesario para evitar un problema. A menudo se necesita un parche tanto en este capítulo como en el siguiente, pero a veces solo en uno u otro.
Por lo tanto, no se preocupe si faltan instrucciones para un parche descargado. También se pueden encontrar mensajes de advertencia sobre desplazamiento al aplicar un parche. No se preocupe de estas advertencias, pues el parche se aplicó con éxito.
• Durante la compilación de la mayoría de los paquetes, habrá varias advertencias que se desplazarán por la pantalla. Estos son normales y pueden ser ignorados de manera segura. Estas advertencias son las que parecen: advertencias sobre obsolescencia, pero no son inválidas, usando la sintaxis C o C ++. Los estándares C cambian con bastante frecuencia, y algunos paquetes aún usan el estándar anterior. Esto no es un problema, pero provoca la advertencia.
• Compruebe una última vez que la variable de entorno LFS está configurada correctamente:

echo $LFS

Para volver a enfatizar el proceso de compilación:

1. Coloque todas las fuentes y parches en un directorio al que se pueda acceder desde el entorno chroot como /mnt/lfs/sources/. No coloque las fuentes en /mnt/lfs/tools/.
2. Cambie al directorio de fuentes.
3. Para cada paquete: 

• Usando el programa tar, extrae el paquete que se construirá. Asegúrese de ser el usuario lfs al extraer el paquete (siempre y cuando no se diga lo contrario).
• Cambie al directorio creado cuando se extrajo el paquete. 
• Siga las instrucciones del libro para construir el paquete. 
• Cambiar de nuevo al directorio de fuentes (/mnt/lfs/sources). 
• Elimine el directorio de origen extraído a menos que se indique lo contrario.

Muchas personas querrán saber por que su equipo tarda X minutos en configurar/compilar/instalar un paquete, o simplemente se desesperan porque piensan que ha entrado en un bucle infinito, y que el equipo se ha vuelto loco. Para resolver esa pequeña gran duda, usaremos el SBU, que ahora explicamos.

El paquete que mas "grande" es el Glibc y toma unos 20 minutos.
...¡si unos 20 minutazos, has leido bien!)
Eso en sistemas modernos y actuales, pero puede llegar hasta 3 dias en equipos antiguos.
Así que para tener una referencia de tiempo estimada, usaremos el SBU.

La medida SBU funciona de la siguiente manera: El primer paquete que se compilará es Binutils. El tiempo que lleva compilar este paquete es lo que se conocerá como la Unidad de Construcción Estándar o SBU (1 SBU). Todos los demás tiempos de compilación se expresarán en relación con este momento. Si cuando hayamos terminado de compilar este paquete han tardado 10 minutos, entonces tendremos la referencia, que 1 SBU, son 20 minutos), y así sabremos el tiempo aproximado que tardará en compilar un paquete que tarda 4.5 SBU (45 minutos, minuto mas minuto menos).
  
Aunque también. tenemos un atajo para los que tenemos un equipo moderno, con varios procesadores, o núcleos. Y es que podemos usar una construcción en paralelo (parallel make). Que no es otra; que usar todos los procesadores o núcleos, para que se repartan el trabajo y así usar todo el potencial posible para realizar nuestro trabajo en mucho menos tiempo. Aunque existe algún paquete que falla, esperemos que algún programador resuelva ese fallo.

Para ello podemos enviar este comando como una variable en nuestro sistema, y se "quedará grabado" para todas las compilaciones que realizemos:

export MAKEFLAGS='-j 8'

 o usarlo cada vez que compilemos:

make -j8

Este comando le comunica al sistema, que use 8 núcleos del sistema. En vuestro caso, debéis informaros cuantos tenéis. No pongas más de los que tienes, porque fallará.

Cuando se utilizan varios procesadores de esta manera, las unidades de SBU variarán incluso más de lo normal. En algunos casos, el paso make simplemente fallará. Analizar el resultado del proceso de compilación también será más difícil porque las líneas de los diferentes procesos se intercalarán. Si se encuentra con un problema con un paso de compilación, vuelva a una compilación de procesador único para analizar correctamente los mensajes de error.

En la próxima publicación,

empezaremos a configurar,
compilar e instalar los paquetes.
 EMPIEZA LO BUENO!