Linux From Scratch (Parte 7 - Preparación de sistemas de archivos de kernel virtual)

Varios sistemas de archivos exportados por el kernel se usan para comunicarse desde y hacia el kernel mismo. Estos sistemas de archivos son virtuales, porque no se usa espacio en disco para ellos. El contenido de los sistemas de archivos residen en la memoria.


Comenzamos por crear directorios en los que se montarán los sistemas de archivos:


sudo mkdir -pv $LFS/{dev,proc,sys,run}
Creando Nodos de Dispositivo Iniciales
Cuando el kernel inicia el sistema, requiere la presencia de unos pocos nodos del dispositivo, en particular la consola y los dispositivos nulos. Los nodos del dispositivo deben crearse en el disco duro para que estén disponibles antes de que se haya iniciado udevd, y adicionalmente cuando Linux se inicie con init=/bin/bash. 
Cree los dispositivos ejecutando los siguientes comandos:
sudo mknod -m 600 $LFS/dev/console c 5 1
sudo mknod -m 666 $LFS/dev/null c 1 3

Montaje y llenado de /dev
El método recomendado para completar el directorio / dev con dispositivos es montar un sistema de archivos virtual (como tmpfs) en el directorio / dev, y permitir que los dispositivos se creen dinámicamente en ese sistema de archivos virtual a medida que se detectan o se accede a ellos. La creación del dispositivo generalmente se realiza durante el proceso de arranque por parte de Udev. Como este nuevo sistema aún no tiene Udev y aún no se ha iniciado, es necesario montar y poblar / dev manualmente. Esto se logra uniendo el directorio / dev del sistema host. Un montaje de enlace es un tipo especial de soporte que le permite crear un espejo de un directorio o punto de montaje en alguna otra ubicación.  
Usaremos el siguiente comando para lograr esto:
sudo mount -v --bind /dev $LFS/dev

Montaje de sistemas de archivos de kernel virtual
Ahora montamos los sistemas de archivos de kernel virtual restantes:
mount -vt devpts devpts $LFS/dev/pts -o gid=5,mode=620
mount -vt proc proc $LFS/proc
mount -vt sysfs sysfs $LFS/sys
mount -vt tmpfs tmpfs $LFS/run
En algunos sistemas host, /dev/shm es un enlace simbólico a /run/shm. El /run tmpfs se montó en el paso anterior, por lo que en este caso solo se debe crear un directorio.
if [ -h $LFS/dev/shm ]; then
  mkdir -pv $LFS/$(readlink $LFS/dev/shm)
fi 

Ahora vamos a explicar el funcionamiento del sistema, por lo que no debemos escribir las instrucciones hasta que no se especifique que ha terminado la explicación.


Gestión de paquetes
Un administrador de paquetes permite rastrear la instalación de archivos, lo que facilita la eliminación y actualización de paquetes. Además de los archivos binarios y de biblioteca, un administrador de paquetes se encargará de la instalación de los archivos de configuración. Antes de preguntar: 
NO, esta sección no hablará ni recomendará ningún administrador de paquetes en particular. Lo que proporciona es un resumen de las técnicas más populares y cómo funcionan. El administrador de paquetes perfecto para usted puede estar entre estas técnicas o puede ser una combinación de dos o más de estas técnicas. Esta sección menciona brevemente los problemas que pueden surgir al actualizar paquetes.

Problemas de actualización
Un administrador de paquetes facilita la actualización a versiones más nuevas cuando se lanzan.
Aquí hay algunos puntos que debe tener en cuenta al actualizar paquetes, especialmente en un sistema en ejecución.
  • Si Glibc necesita actualizarse a una versión más nueva, (por ejemplo, de glibc-2.19 a glibc-2.20), es más seguro reconstruir LFS. Aunque es posible que pueda reconstruir todos los paquetes en su orden de dependencia, no lo recomendamos.
  • Si se actualiza un paquete que contiene una biblioteca compartida, y si el nombre de la biblioteca cambia, entonces todos los paquetes dinámicamente vinculados a la biblioteca deben recompilarse para vincularse con la biblioteca más nueva. (Tenga en cuenta que no existe una correlación entre la versión del paquete y el nombre de la biblioteca). Por ejemplo, considere un paquete foo-1.2.3 que instala una biblioteca compartida con el nombre libfoo.so.1. Supongamos que actualiza el paquete a una versión más nueva foo-1.2.4 que instala una biblioteca compartida con el nombre libfoo.so.2. 
    En este caso, todos los paquetes que están dinámicamente vinculados a libfoo.so.1 deben recompilarse para vincularlos con libfoo.so.2. Tenga en cuenta que no debe eliminar las bibliotecas anteriores hasta que se vuelvan a compilar los paquetes dependientes.
     
Técnicas de gestión de paquetes
Las siguientes son algunas técnicas comunes de administración de paquetes. Antes de tomar una decisión sobre un administrador de paquetes, investigue las diversas técnicas, particularmente los inconvenientes del esquema particular.

Instalar en directorios separado
Esta es una administración de paquetes simplista que no necesita ningún paquete adicional para administrar las instalaciones. Cada paquete está instalado en un directorio separado. Por ejemplo, el paquete foo-1.1 se instala en /usr/pkg/foo-1.1 y se crea un enlace simbólico de / usr / pkg / foo a /usr/pkg/foo-1.1. Al instalar una nueva versión de foo-1.2, se instala en /usr/pkg/foo-1.2 y el enlace simbólico anterior se reemplaza por un enlace simbólico a la nueva versión.

Las variables de entorno como PATH, LD_LIBRARY_PATH, MANPATH, INFOPATH y CPPFLAGS deben expandirse para incluir / usr / pkg / foo. Para más de unos pocos paquetes, este esquema se vuelve inmanejable.

Gestión de paquetes de estilo Symlink 
Esta es una variación de la técnica de gestión de paquetes anterior. Cada paquete se instala de forma similar al esquema anterior. Pero en lugar de hacer el enlace simbólico, cada archivo se enlaza simbólicamente a la jerarquía / usr. Esto elimina la necesidad de expandir las variables de entorno. Aunque los enlaces simbólicos pueden ser creados por el usuario para automatizar la creación, muchos administradores de paquetes se han escrito utilizando este enfoque. Algunos de los populares incluyen Stow, Epkg, Graft y Depot.

La instalación necesita ser falsificada, para que el paquete piense que está instalada en /usr aunque en realidad está instalada en la jerarquía /usr/pkg. Instalar de esta manera no suele ser una tarea trivial. Por ejemplo, considere que está instalando un paquete libfoo-1.1. Las siguientes instrucciones pueden no instalar el paquete correctamente:

./configure --prefix=/usr/pkg/libfoo/1.1
make
make install
 
La instalación funcionará, pero los paquetes dependientes pueden no vincularse con libfoo como es de esperar. Si compila un paquete que enlaza con libfoo, puede observar que está vinculado a /usr/pkg/libfoo/1.1/lib/libfoo.so.1 en lugar de /usr/lib/libfoo.so.1 como era de esperar . El enfoque correcto es usar la estrategia DESTDIR para falsificar la instalación del paquete. Este enfoque funciona de la siguiente manera:

 
./configure --prefix=/usr
make
make DESTDIR=/usr/pkg/libfoo/1.1 install

La mayoría de los paquetes respaldan este enfoque, pero hay algunos que no lo hacen. Para los paquetes no conformes, puede que necesite instalar el paquete manualmente, o puede encontrar que es más fácil instalar algunos paquetes problemáticos en /opt.

Basado en marca de tiempo
En esta técnica, un archivo tiene marca de tiempo antes de la instalación del paquete. Después de la instalación, un simple uso del comando find con las opciones adecuadas puede generar un registro de todos los archivos instalados después de que se creó el archivo de marca de tiempo. Un administrador de paquetes escrito con este enfoque es install-log. 

Aunque este esquema tiene la ventaja de ser simple, tiene dos inconvenientes. Si, durante la instalación, los archivos se instalan con cualquier marca de tiempo que no sea la hora actual, el administrador del paquete no rastreará esos archivos. Además, este esquema solo se puede usar cuando se instala un paquete a la vez. Los registros no son confiables si se están instalando dos paquetes en dos consolas diferentes.

Rastreo de secuencias de comandos de instalación
En este enfoque, los comandos que realizan los scripts de instalación se registran. Hay dos técnicas que uno puede usar:

  • La variable de entorno LD_PRELOAD se puede configurar para que apunte a una biblioteca que se precargará antes de la instalación. Durante la instalación, esta biblioteca realiza un seguimiento de los paquetes que se instalan adjuntándose a varios ejecutables, como cp, install, mv, y rastreando las llamadas al sistema que modifican el sistema de archivos. Para que este enfoque funcione, todos los ejecutables deben vincularse dinámicamente sin el bit suid o sgid. La carga previa de la biblioteca puede causar algunos efectos secundarios no deseados durante la instalación. Por lo tanto, se recomienda que uno realice algunas pruebas para asegurarse de que el administrador del paquete no rompa nada y registre todos los archivos apropiados.
  • La segunda técnica es usar strace, que registra todas las llamadas al sistema realizadas durante la ejecución de los scripts de instalación. 
Creando paquetes de archivos
En este esquema, la instalación del paquete se falsifica en un árbol separado como se describe en la administración de paquetes de estilo de enlace simbólico. Después de la instalación, se crea un archivo de paquete utilizando los archivos instalados. Este archivo se usa para instalar el paquete en la máquina local o incluso se puede usar para instalar el paquete en otras máquinas.

Este enfoque es utilizado por la mayoría de los gerentes de paquetes que se encuentran en las distribuciones comerciales. Los ejemplos de gestores de paquetes que siguen este enfoque son RPM (que, dicho sea de paso, es requerido por la Especificación Base de Linux), pkg-utils, apt de Debian y el sistema Portage de Gentoo. Una sugerencia que describe cómo adoptar este estilo de gestión de paquetes para sistemas LFS se encuentra en http://www.linuxfromscratch.org/hints/downloads/files/fakeroot.txt.

La creación de archivos de paquete que incluyen información de dependencia es compleja y está más allá del alcance de LFS.

Slackware usa un sistema basado en tar para archivos de paquetes. Este sistema deliberadamente no maneja las dependencias del paquete como hacen los administradores de paquetes más complejos. Para obtener más información sobre la administración de paquetes de Slackware, consulte http://www.slackbook.org/html/package-management.html.  

Gestión basada en el usuario 
Este esquema, exclusivo de LFS, fue diseñado por Matthias Benkmann y está disponible en el Proyecto Sugerencias. En este esquema, cada paquete se instala como un usuario separado en las ubicaciones estándar. Los archivos que pertenecen a un paquete se identifican fácilmente al verificar la identificación del usuario. Las características y deficiencias de este enfoque son demasiado complejas para describirlas en esta sección. Para más detalles, consulte la sugerencia en http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt. 

Implementando LFS en múltiples sistemas 
Una de las ventajas de un sistema LFS es que no hay archivos que dependan de la posición de los archivos en un sistema de disco. Clonar una construcción LFS a otra computadora con la misma arquitectura que el sistema base es tan simple como usar tar en la partición LFS que contiene el directorio raíz (alrededor de 250MB descomprimido para una compilación LFS base), copiar ese archivo a través de transferencia de red o CD- ROM al nuevo sistema y expandiéndolo. A partir de ese punto, habrá que cambiar algunos archivos de configuración. Los archivos de configuración que pueden necesitar actualización incluyen: /etc/hosts, /etc/fstab, /etc/passwd, /etc/group, /etc/shadow, /etc/ld.so.conf, /etc/sysconfig/rc.site, /etc/sysconfig/network, y /etc/sysconfig/ifconfig.eth0. 

Es posible que sea necesario crear un núcleo personalizado para el nuevo sistema, según las diferencias en el hardware del sistema y la configuración original del kernel.

NOTA: Ha habido algunos informes de problemas al copiar entre arquitecturas similares pero no idénticas. Por ejemplo, el conjunto de instrucciones para un sistema Intel no es idéntico a un procesador AMD y las versiones posteriores de algunos procesadores pueden tener instrucciones que no están disponibles en versiones anteriores.

Y con esto ya hemos terminado con la teoría. En la siguiente publicación empezaremos a trabajar creando el entorno chroot

Disculpad si esta publicación ha sido demasiado teórica, pero creo que era necesario explicar el funcionamiento interno del sistema.

Entradas populares de este blog

Acerca de los mensajes de tipo... "Por favor no agreges a este usuario es un virus!"

Temas oficiales para Windows XP

Activar tema Negro (gris oscuro) en Microsoft Office 2016