Pertenece a LPI Topic 101: System Architecture

• Weight: 3
• Description: Candidates should be able to guide the system through the booting process.
• Key Knowledge Areas:
  • Provide common commands to the boot loader and options to the kernel at boot time.
  • Demonstrate knowledge of the boot sequence from BIOS/UEFI to boot completion.
  • Understanding of SysVinit and systemd.
  • Awareness of Upstart.
  • Check boot events in the log files.
• The following is a partial list of the used files, terms and utilities:
  • dmesg
  • journalctl
  • BIOS
  • UEFI
  • bootloader
  • kernel
  • initramfs
  • init
  • SysVinit
  • Systemd

Al encender eléctricamente un ordenador, aparecen en pantalla una serie de cosas antes de que arranque el sistema operativo. Obviamente, debe haber algo que haga de intermediario antes de que llegue a arrancar el sistema operativo.

La mayoría de dispositivos Hardware contienen un firmware, que gestiona el arranque de la máquina, previo a la carga del SO:

• En sistemas antiguos el firmware es BIOS (Basic Input/Output System)
• En sistemas modernos se llama UEFI (Unified Extensible Firmware Interface)

Este firmware está en un chip de la placa base.

La BIOS (Basic Input Output System) es un software de interfaz entre el hardware y el software a un nivel muy básico. Proporciona el conjunto de las instrucciones básicas utilizadas por el sistema operativo. Provee el nivel de interfaz más bajo a los drivers y periféricos.

La BIOS está presente en una memoria EEPROM (Electrical Erasable Programmable ReadOnly Memory) del ordenador. Cuando se enciende el ordenador, o tras un reseteado, se manda una señal llamada al microprocesador. Éste activa entonces la ejecución de la BIOS.

Creada en 1975 (IBM)

UEFI (o EFI en sus primeras versiones), cumple las mismas funciones que BIOS pero con considerables mejoras:

• Soporta integración teclado / ratón
• Reconoce dispositivos de más de 2 TB (GPT)
• Soporta 32 o 64 bits
• Crea una partición propia donde almacena drivers para acelerar la carga del sistema
• Soporte de red
• Opciones de seguridad (Secure Boot)
• Soporta extensiones de terceros
• Puede funcionar en modo Legacy (como si fuese una BIOS clásica).

Debemos tener en cuenta cuatro pasos importantes:

• Arranque de Hardware. Se llama la BIOS o UEFI.
• Bootloader. Encargado de arrancar el sistema operativo que corresponda.
• Kernel (en caso de sistemas Linux).
• Arranque de procesos del sistema. El kernel, una vez cargado, se encarga de arrancar el resto de procesos necesarios.es

BIOS o UEFI es el primer programa en ejecutarse. Se ejecuta desde la ROM y tiene su propio “SO independendiente”.

Posteriormente se ejecuta un POST que realiza un test independiente de hardware para poder arrancar, además de buscar el dispositivo de almacenamiento que servirá como sistema de arranque.

La BIOS lee y ejecuta el primer sector físico del soporte físico de inicio. Suele tratarse de los 512 primeros bytes del primer disco duro (el MBR) o de la partición activa (la PBR)

Desde el MBR/PBR se lanza el bootloader (como GRUB). En el caso de BIOS, el bootloader está en el MBR, pero en sistemas UEFI estará en una partición. El bootloader se encargará de cargar el kernel del SO con el initial-ramdisk.

El kernel se encuentra en /boot/vmlinuz*

A partir de aquí se monta el Initial Ramdisk (initrd) y se cargan los modulos disponibles.

El initrd es desmontado y el Sistema de Archivos Linux es montado

El Kernel ejecuta el proceso principal del sistema, que depende del sistema de gestión de procesos que utilice:

• Sistema clásico: SysV → init
• Sistema moderno: Systemd → systemd

Este proceso principal es el que se encargará de arrancar el resto de procesos necesarios antes de permitir que iniciemos sesión.

Si estamos en una máquina Linux y queremos saber si usa SysV o Systemd, buscamos cuál es el primer proceso (PID = 1):

ps -ef | more

• /sbin/init: SysV
• /usr/lib/systemd/systemd: Systemd

Como Systemd aún mantiene compatibilidad con SysV, nos puede aparecer igualmente /sbin/init. Para asegurarnos de que es un sistema con Systemd:

cat /proc/1/stat

Devolverá algo como:

1 (systemd) S 0 1 1 0 -1 ....

Si disponemos del comando systemctl también es otra buena pista.

INIT es el primer proceso en ejecutarse después de la carga del kernel de linux e implementa dos modelos bajo los cuales puede trabajar:

• SysV
• BDS

Estos modelos son arrancados por un programa (script) de arranque que establece cómo deben inicializarse los diferentes servicios, programas o registros que sean necesarios para que el sistema funcione como el administrador lo requiere.

Al arrancar el kernel el proceso init, este arranca los procesos correspondientes al runlevel por defecto del sistema

Runlevels, niveles init o de ejecución corresponde al estado en el cual se encuentra Unix/Linux una vez arrancado. Init controla este estado. Cada estado dispone de su propia configuración (o por inittab, o por scripts llamados initscripts). Por ejemplo, se puede utilizar un nivel de ejecución para arrancar Unix en modo monousuario, en multiusuario, con o sin red, con o sin modo gráfico.

El administrador puede personalizar todos los niveles.

Runlevels (Niveles de ejecución) son usados para personalizar la forma en la que el SO arranca.

El Runlevel nos indica qué servicios son iniciados automáticamente.

Cada runlevel tiene un identificador asociado (0-6, S)

En el modo clásico UNIX, los runlevels:

• 0: Parada del sistema
• 1, S: Modo single-user. No inicia servicios de red. Como si fuese el modo a prueba de fallos de Windows. El modo S se activa si ha ocurrido algo al arrancar y el sistema automáticamente entra en modo rescate.
• 2: Multi-user sin NFS (igual que el 3, pero sin red)
• 3: Full multi-user (sin entorno gráfico)
• 4: No suele ser relevante y no se usa
• 5: Multiuser con X11 (entorno gráfico).
• 6: Reinicio del Sistema

Normalmente un equipo estará en el modo 3 o 5.

En sistemas Debian/Ubuntu (si incluyen servidor gráfico por defecto):

• 0: Parada del sistema
• 1, S: Modo single-user. No inicia servicios de red.
• 2: Multi-user con X11
• 3: Multi-user con X11
• 4: Multi-user con X11
• 5: Multiuser con X11.
• 6: Reinicio del Sistema

El runlevel por defecto se especifica en el fichero /etc/inittab

Si queremos modificar el runlevel por defecto, lo modificamos en ese fichero, guardamos y reiniciamos.

El SO carga los servicios según el runlevel ejecutando los scripts existentes /etc/rcX.d/ dónde X es el identificador del runlevel (X = 0-6). Estos scripts pueden empezar por:

• K (kill): identificador de parada del servicio
• S (start): identificador para que inicie el servicio

Ejemplos de scripts:

• K36mysqld
• K61nfs-rdma
• S08iptables
• S55sshd

El orden en que se ejecutarán cada uno de los scripts viene determinado por el número que hay a continuación de K y S (K36mysqld se ejecutará antes que K61nfs-rdma). Primero se ejecutan los scripts de parada (K)y luego los de inicio (S)

Realmente, dichos scripts son enlaces simbólicos a los reales ubicados en /etc/init.d/

Lo normal es que desde /etc/init.d/ se creen enlaces simbólicos porque nos permite hacer una gestión más cómoda y segura de los runlevels. Hace más difícil que borremos el script original de cierto runlevel, por ejemplo. De esta manera, solo tendremos que añadir o quitar los enlaces simbólicos de los directorios /etc/rcX.d/ correspondientes

El comando runlevel nos muestra el runlevel actual

En la salida veremos un primer dato que indica el anterior nivel de ejecución en que estaba la máquina (N, none, si estaba apagada) y el actual.

Systemd es el nuevo estándar para la gestión de servicios en Linux.

Intenta ir más alla de las funciones de SysV, que solo comprendían la gestión de servicios, intentando abarcar la gestión de otros elementos del sistema operativo, como la gestión de puntos de montaje, swaps, programación de tareas, gestión de dispositivos, etc.

• Capacidades de paralelización agresiva usando socket: systemd crea de una misma vez todos los sockets para todos los demonios acelerando así el arranque completo e iniciar más procesos en paralelo. En un segundo paso systemd ejecutará a la vez todos los demonios.
• Activación D-Bus para iniciar servicios: Utilizando la activación D-Bus, un servicio puede ser iniciado la primera vez que es accedido.
• Seguimiento de procesos utilizando Linux cgroups: cgroup también llamados grupos de control, es una característica del kernel para crear límites, políticas e incluso explicar el uso de los recursos de ciertos grupos de procesos. cgroup asocia un conjunto de tareas con un conjunto de parámetros, para uno o más subsistemas,

proporcionando un control de servicios y tareas, así como todos sus futuros ‘hijos’ en grupos jerárquico. Un subsistema es un módulo resultado de la agrupación de diversas tareas con el fin de mantener un mejor control sobre estas de forma particular.

Esta intención de “canibalizar” las competencias de otros elementos del sistema le ha granjeado una gran oposición en la comunidad, pero su adopción por parte de las grandes distribuciones (Debian y Red Hat) ha hecho que todas las demás decidan implantarlo poco a poco.

Actualmente las últimas versiones de las distros lo incorporan en un proceso de convivencia con SysV

Systemd utiliza unidades o units como elemento mínimo de configuración. Se podría asimilar a los scripts de arranque en SysV.

Existen diferentes tipos de units:

• Services: servicios del sistema. Demonios que pueden ser iniciados, detenidos, reiniciados o recargados.
• Targets: agrupacion de lógica de units. Referencia a otras unidades que pueden ser controladas conjuntamente, com multi-user.target que básicamente desempeña el papel de nivel de ejecución 3 en el sistema clásico SysV.
• Device: dispositivos (con Udev)
• Mount/Automount: Punto de montaje.
• Socket: generan un socket de red.
• Path: monitorización de rutas
• Wants: dependencias de otras units.
• Swap: para trabajar con memoria virtual.
• Timer: programación de tareas
• Slice: conjunto de servicios por funciones

Cada unidad es un archivo de configuración con la nomenclatura nombre-unidad.extension. La extensión indica el tipo de unidad. Por ejemplo, samba.service.

Haciendo un símil entre systemd y SysV, el proceso fundamental es init que consulta el nivel de ejecución y cada nivel de ejecución ejecuta los scripts correspondientes. En Systemd el proceso fundamental es systemd que mira el target por defecto y ejecuta las unidades correspondientes a ese target.

Rutas de los archivos de configuración de las units:

• /lib/systemd/system: directorio base de units
• /etc/systemd/system: máxima prioridad
• /run/systemd/system: Amplía o modifica la base (volátil)
• /etc/systemd/system/<name.unit>.d/*.conf: Ampliación de configuraciones para una unidad
• /etc/systemd/system/<name.unit>.wants/*.conf: Requisitos para arrancar una unidad

El archivo de configuración original debe quedar en /lib/systemd/system y las modificaciones en /etc/systemd/system, que tiene prioridad sobre el anterior directorio. Es una buena práctica para no perder nunca el fichero original (como hacíamos con los enlaces simbólicos en SysV).

A diferencia de SysV, en Systemd los servicios se arrancan en paralelo. De tal manera que si un servicio tiene una dependencia de otro y este último no ha arrancado, espera, llama al otro, lo arranca y finalmente arranca el primer servicio. Estas dependencias se definen en los directorios /etc/systemd/system/<name.unit>.wants/*.conf

Una herramienta interesante de Systemd es systemd-cgls que muestra recursivamente el contenido del árlbol de jerarquías de un determinado grupo de control de Linux (los procesos que tiene cada unidad que está en funcionamiento).

Se utiliza para mostrar o controlar el buffer del anillo del kernel. En este buffer se recoge todo lo que detecta el sistema desde el arranque

En sistemas con Systemd, existe otra herramienta para mostrar el buffer del anillo del kernel, podemos ver todos los elementos que han sido cargados en la memoria. Con journalctl -k mostramos solo la información del kernel.

Los logs se siguen registrando en /var/log/, pero el journal de Systemd lo guarda en un binario en /run/log/journal

Por defecto, los Red Hat no tienen un journal que persista en el sistema tras los reinicios. Debian, en cambio, sí lo tiene permanente por defecto. Para saber si journal es persistente o no, podemos buscar la existencia del directorio /var/log/journal

Para ver la lista de los arranques:

journalctl --list-boots

Si solo queremos ver los logs del arranque actual:

journalctl -b

Para acceder a cierto arranque pasado:

journalctl -b -X

Donde X es el identificar de los arranques que podemos ver con journalctl --list-boots