La wiki de TempWin

Esta página es de solo lectura. Puedes ver la fuente pero no puedes cambiarla. Pregunta a tu administrador si crees que esto es incorrecto.
====== 101.2 Boot the system ======

Pertenece a [[informatica:certificaciones:lpic:lpic-1:101_system_architecture|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

===== La secuencia de arranque de Linux =====

==== Conociendo un poco la máquina ====

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.

<WRAP center round info 60%>
Un Sistema Operativo (SO) es el software que hace el enlace entre el usuario y el Hardware.
</WRAP>

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).

==== Pasos para el arranque ====

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//.

<WRAP center round info 60%>
En caso de elegir Windows, el gestor de arranque cargará otro gestor de arranque (chainloader) que será el que finalmente cargue Windows
</WRAP>

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):

<code>
ps -ef | more
</code>

  * ''/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:

<code>
cat /proc/1/stat
</code>

Devolverá algo como:

<code>
1 (systemd) S 0 1 1 0 -1 ....
</code>

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

===== Proceso init =====

**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.
==== SysV ====

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

<WRAP center round info 60%>
CentOS 6 es un sistema con SysV puro
</WRAP>

**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.

<WRAP center round important 60%>
Nunca establecer como runlevel por defecto el 0 ni el 6
</WRAP>


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''

<WRAP center round todo 60%>
Incluir ejemplo con el conteido del fichero ''/etc/inittab'' de un sistema que use SysV
</WRAP>

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/''

<WRAP center round todo 60%>
Mostrar un ejemplo de la salida de ''ls -l'' en el directorio ''/etc/init.d/''
</WRAP>

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

<WRAP center round todo 60%>
Ejemplo de ejecución de ''runlevel''
</WRAP>

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.

<WRAP center round info 60%>
SVR4 fue la versión más popular de SVR así como la fuente de varias características comunes del sistema operativo Unix, como el script ''/etc/init.d''
</WRAP>

==== Systemd ====

**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:

  * **service**: servicios del sistema. Demonios que pueden ser iniciados, detenidos, reiniciados o recargados.
  * **target**: 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''.

<WRAP center round info 60%>
Las units por defecto son las **service**. Esto quiere decir que no es necesario indicar la extensión de la unit a la hora de usarla: ''systemctl start httpd'' (es igual que ''systemctl start httpd.service'')
</WRAP>

Para saber si un sistema tiene Systemd, mirando los procesos que están en ejecución, el que tenga el PID 1 será systemd:

<code>
[tempwin@box ~]$ ps -ef
UID          PID    PPID  C STIME TTY          TIME CMD
root           1       0  0 09:56 ?        00:00:01 /sbin/init
</code>

<WRAP center round important 60%>
Ojo, como se ve en el ejemplo anterior, ''/sbin/init'' podría ser un enlace a ''/usr/lib/systemd/systemd'' indicando que se trata de SystemD. También podríamos consultar el fichero ''/proc/1/stat''
</WRAP>

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.

^  Systemd     ^    SysV     ^
|   systemd    |    init     |
|   Targets    |  Runlevels  |
|   Units      |  Scripts    |

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 árbol de jerarquías de un determinado grupo de control de Linux (los procesos que tiene cada unidad que está en funcionamiento).

<WRAP center round todo 60%>
Poner ejemplo de lo anterior
</WRAP>

===== Comandos útiles =====

==== dmesg ====

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

<WRAP center round todo 60%>
Poner ejemplo de salida de ''dmesg''
</WRAP>

<WRAP center round info 60%>
Con la llegada de Systemd, se puede usar ''journalctl''
</WRAP>

==== journalctl ====

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.

<WRAP center round todo 60%>
Poner ejemplo de la salida del comando anterior.
</WRAP>

Los logs se siguen registrando en ''/var/log/'' (los sistemas siguen usando ''rsyslog''), 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:

<code>
journalctl --list-boots
</code>

Si solo queremos ver los logs del arranque actual:

<code>
journalctl -b
</code>

Para acceder a cierto arranque pasado:

<code>
journalctl -b -X
</code>

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

Filtrar por programa:

<code>
journalctl _COMM=NetworkManager
</code>

O por la ruta del ejecutable:

<code>
journalctl /usr/bin/NetworkManager
</code>

Incluso por el PID del proceso:

<code>
journalctl _PID=1234
</code>

Por **servicios**:

<code>
journalctl -u dbus.service
</code>

Filtrar por **fechas**:

<code>
journalctl --since 'yesterday' --until=9:30
</code>

<code>
journalctl --since '30 min ago' -u sshd.service
</code>

<code>
journalctl --since=00:00 --until=12:00
</code>

<code>
journalctl -u sshd.service --since='2022-01-01 00:00' --until='2022-01-10 00:00'
</code>

Por **errores**:

<code>
journalctl -p err
</code>

Últimos mensajes con explicación:

<code>
journalctl -xe
</code>

Los mensajes se clasifican en función de su prioridad en 8 niveles diferentes:

  * //emerg//: 0
  * //alert//: 1
  * //crit//: 2
  * //err//: 3
  * //warning//: 4
  * //notice//: 5
  * //info//: 6
  * //debug//: 7

=== Configuración ===

La configuación de journal se hace en ''/etc/systemd/journald.conf''.

Por defecto, el límite del tamaño del log del journal es el 10 % del tamaño del sistema de archivos. Por ejemplo, si ''/var/log/journal'' está alojado en una partición raíz de 50 GB, esto permitiría almacenar hasta 5 GB de datos en journal. La opción para rotar el log es ''SystemMaxUse=50M''

=== Persistencia ===

En los Red Hat, por defecto, los logs del journal no se almacenan. Solo existen en tiempo de ejecución en ''/run/log/journal''. Para hacerlo persistente a los reinicios:

Creamos el fichero que contendrá los logs:

<code>
mkdir -p /var/log/journal
</code>

Creamos un sistema de ficheros:

<code>
systemd-tmpfiles --create --prefix /var/log/journal
</code>

Damos permisos adecuados:

<code>
chown root:systemd-journal /var/log/journal
</code>

<code>
chmod 2775 /var/log/journal
</code>

Reiniciamos ''journald'' para aplicar los cambios:

<code>
systemctl restart systemd-journald
</code>

<WRAP center round info 60%>
Aunque no esté configurada la persistencia de los logs de journald, seguimos teniendo los generados por rsyslog (''/var/log/'')
</WRAP>