Arch boot process (Español)

Esta traducción de Arch boot process fue revisada el 2021-02-14. Si existen cambios puede actualizarla o avisar al equipo de traducción.

Para arrancar Arch Linux es necesario configurar un cargador de arranque compatible con Linux. Este se encarga de cargar el kernel y el initramfs antes de iniciar el proceso de arranque. El procedimiento difiere considerablemente entre los sistemas BIOS y UEFI.

Tipos de firmware

El firmware es el primer programa que se ejecuta cuando se enciende el sistema.

Tip

Los términos BIOS y UEFI suelen utilizarse para referirse al firmware.
No confundir con Linux firmware.

UEFI

UEFI tiene soporte para leer tanto la tabla de particiones como los sistemas de archivos. UEFI no ejecuta ningún código de arranque desde el Master Boot Record (MBR) exista o no, en su lugar el arranque depende de las entradas de arranque en la NVRAM.

La especificación UEFI exige el soporte para los sistemas de archivos FAT12, FAT16, y FAT32 (véase Especificación UEFI versión 2.7, sección 13.3.1.1), pero cualquier proveedor puede añadir opcionalmente soporte para sistemas de archivos adicionales; por ejemplo, HFS+ o APFS en algunos firmware de Apple. Las implementaciones UEFI también son compatibles con ISO 9660 para discos ópticos.

UEFI lanza aplicaciones EFI, p. ej., cargadores de arranque, gestores de arranque, intérprete de órdenes UEFI, etc. Estas aplicaciones generalmente se almacenan como archivos en la partición del sistema EFI. Cada proveedor puede almacenar sus archivos en la partición del sistema EFI dentro del directorio /EFI/nombre_proveedor. Las aplicaciones se pueden iniciar añadiendo una entrada de arranque a la NVRAM o desde el intérprete de órdenes UEFI.

La especificación UEFI es compatible con el arranque de BIOS heredado mediante su Compatibility Support Module (CSM). Si CSM está activado en el UEFI, el UEFI generará entradas de arranque CSM para todas las unidades. Si se elige una entrada CSM desde la que se iniciará, el CSM de UEFI intentará iniciarse desde el código de arranque MBR de la unidad.

Nota Intel está eliminando gradualmente el soporte para CSM; depender de esta característica podría no ser factible en el futuro.[1]

BIOS

Un BIOS o sistema básico de entrada-salida se almacena, en la mayoría de los casos, en una memoria flash de la propia placa base y es independiente del almacenamiento del sistema. Creado originalmente para el IBM PC con el fin de gestionar la inicialización del hardware y el proceso de arranque, ha sido sustituido progresivamente desde 2010 por UEFI, que no presenta las mismas limitaciones técnicas.

Inicialización del sistema

Una vez encendido el sistema, se ejecuta la autoprueba de encendido (POST). Véase también Modern CPUs have a backstage cast de Hugo Landau.

Bajo UEFI

Después del POST, UEFI inicializa el hardware requerido para el arranque (disco, controladores de teclado, etc).
El firmware lee las entradas de arranque en la NVRAM para determinar qué aplicación EFI se lanzará y desde dónde (por ejemplo, desde qué disco y partición).
- Una entrada de arranque podría simplemente ser un disco. En este caso, el firmware busca una partición del sistema EFI en ese disco e intenta encontrar una aplicación EFI en la ruta de arranque alternativa (fallback) \EFI\BOOT\BOOTX64.EFI (BOOTIA32.EFI en sistemas con UEFI IA32 (32 bits)). Así es como funcionan los medios extraíbles de arranque UEFI.
El firmware lanza la aplicación EFI.
- Podría tratarse de un cargador de arranque o del propio kernel de Arch usando EFISTUB.
- Podría ser alguna otra aplicación EFI, como un intérprete de órdenes UEFI o un gestor de arranque como systemd-boot o rEFInd.

Si el inicio seguro está habilitado, el proceso de arranque verificará la autenticidad de la firma del binario EFI.

Nota Algunos sistemas UEFI solo pueden arrancar desde la ruta de arranque alternativa (fallback).

Arranque múltiple en UEFI

Como cada sistema operativo o proveedor puede mantener sus propios archivos en la partición del sistema EFI sin interferir con los demás, el arranque múltiple mediante UEFI se reduce a ejecutar la aplicación EFI correspondiente al cargador de arranque del sistema operativo que se quiere iniciar. Esto elimina la necesidad de recurrir a los mecanismos de carga en cadena de un cargador de arranque para cargar otro sistema operativo.

Véase también Arranque dual con Windows.

Bajo BIOS

Después del POST, el BIOS inicializa el hardware requerido para el arranque (disco, controladores de teclado, etc).
El BIOS ejecuta los primeros 440 bytes (el área del código de arranque del MBR) del primer disco según el orden de arranque configurado en el BIOS.
La primera etapa del cargador de arranque, contenida en el código de arranque del MBR, ejecuta la segunda etapa (si existe) desde una de las siguientes ubicaciones:
- los sectores del disco inmediatamente posteriores al MBR, es decir, el espacio conocido como post-MBR gap (solo en discos con tabla de particiones MBR),
- el volume boot record (VBR) de una partición o de un disco sin particiones,
- una partición de arranque de BIOS específica de GRUB en discos con tabla de particiones GPT (se utiliza en lugar del post-MBR gap, que no existe en GPT).
Se inicia el cargador de arranque.
El cargador de arranque carga un sistema operativo, ya sea mediante carga en cadena o cargando directamente el kernel del sistema operativo.

Cargador de arranque

Un cargador de arranque es un programa iniciado por el firmware (UEFI o BIOS). Es responsable de cargar el kernel con los parámetros del kernel especificados y cualquier imagen externa de initramfs.

Un gestor de arranque presenta un menú con opciones de arranque o proporciona alguna otra forma de controlar el proceso de arranque, es decir, simplemente ejecuta otros ejecutables EFI.

En el caso de UEFI, el propio kernel puede iniciarse directamente por medio de EFI boot stub. Aun así, un cargador de arranque o un gestor de arranque independiente puede utilizarse para editar los parámetros del kernel antes de arrancar.

Los sistemas con UEFI AI32 de 32-bits requieren un cargador de arranque compatible con el modo de arranque mixto.

Advertencia Para poder arrancar Arch con éxito, el cargador de arranque necesita acceder al kernel y a la(s) imagen(es) de initramfs que normalmente se encuentran en el directorio /boot. Eso significa que debe ser compatible con todo, desde los dispositivos de bloque, pasando por los dispositivos de bloque apilados (LVM, RAID, dm-crypt, LUKS, etc.), hasta el sistema de archivos en el que se encuentran el kernel y las imágenes de initramfs.

Dado que casi ningún cargador de arranque admite dispositivos de bloque apilados y que los sistemas de archivos pueden incorporar nuevas funcionalidades que ningún cargador de arranque admita todavía (p. ej., archlinux/packaging/packages/grub#7, FS#79857, FS#59047, FS#58137, FS#51879, FS#46856, FS#38750, FS#21733 y directorios encriptados con fscrypt), a menudo resulta más factible utilizar una partición /boot independiente con un sistema de archivos con amplio soporte, como FAT32.

Comparación de características

Nota

Como GPT es parte de la especificación UEFI, todos los gestores de arranque UEFI soportan discos GPT. Es posible usar GPT en sistemas BIOS mediante el "arranque híbrido" con MBR híbrido, o el nuevo protocolo GPT-only. Sin embargo, este protocolo puede causar problemas con ciertas implementaciones de BIOS; consulte rodsbooks para más detalles.
Dado que el arranque seguro forma parte de la especificación UEFI, todos los cargadores de arranque UEFI lo admiten, aunque algunos presentan limitaciones.

Nombre	Firmware		Tabla de particiones		Multi-arranque	Sistema de archivos	Notas
Nombre	BIOS	UEFI	MBR	GPT	Multi-arranque	Sistema de archivos	Notas
Clover	Sí	Sí	No	Sí	Sí	Extensible^2,5	Puede emular UEFI en sistemas con BIOS heredado.
EFI boot stub	–	Sí¹	Sí	Sí	–	Proporcionado por el firmware²	El kernel es un ejecutable EFI válido que puede iniciarse directamente desde UEFI o desde otro cargador de arranque UEFI.
GRUB	Sí	Sí³	Sí	Sí	Sí	Integrado	Admite RAID, LUKS y LVM (pero no volúmenes con aprovisionamiento ligero). Consulte GRUB para conocer las limitaciones específicas de cada configuración.
Limine	Sí	Sí³	Sí	Sí	Sí	Limitado
rEFInd	No	Sí	Sí	Sí	Sí⁴	Extensible^2,5	Admite la detección automática de kernels y parámetros sin necesidad de una configuración explícita, además de fastboot [2].
Syslinux	Sí	Parcial¹	Sí	Sí	Parcial	Limitado	No admite determinadas características de los sistemas de archivos. Solo puede acceder al sistema de archivos en el que fue instalado.
systemd-boot	No	Sí³	Manual	Sí	Sí⁴	Extensible^2,5	Solo puede iniciar binarios desde la ESP en la que está instalado o desde la partición Extended Boot Loader (partición XBOOTLDR) del mismo disco. Detecta automáticamente las UKIs (unified kernel images) ubicadas en `esp/EFI/Linux/`.
Unified kernel image	–	Sí³	Sí	Sí	–	Proporcionado por el firmware²	systemd-stub(7), un kernel, un initramfs y la línea de comandos del kernel empaquetados en un ejecutable EFI que puede cargarse directamente desde el firmware UEFI o desde otro cargador de arranque.
GRUB Legacy	Sí	No	Sí	No	Sí	Limitado	Descontinuado en favor de GRUB.
LILO	Sí	No	Sí	Parcial	Sí	Limitado	Descontinuado debido a sus limitaciones (p. ej., con Btrfs, GPT, RAID y el cifrado).

Aunque el binario puede firmarse para Secure Boot, no realiza ninguna verificación posterior, por lo que rompe la cadena de confianza.
La compatibilidad con sistemas de archivos depende del firmware. La especificación UEFI exige compatibilidad con los sistemas de archivos FAT12, FAT16 y FAT32 [3], pero los fabricantes pueden añadir opcionalmente compatibilidad con otros sistemas de archivos; por ejemplo, el firmware de los Mac de Apple admite el sistema de archivos HFS+. Si el firmware proporciona una interfaz para cargar controladores UEFI durante el arranque, se puede añadir compatibilidad con otros sistemas de archivos mediante la carga de controladores de sistemas de archivos obtenidos de forma independiente.
Admite el arranque en modo mixto. Es decir, puede iniciar un kernel Linux x86_64 de 64 bits en un firmware UEFI IA32 de 32 bits.
Un gestor de arranque. Solo puede iniciar otras aplicaciones EFI, como imágenes del kernel Linux compiladas con CONFIG_EFI_STUB=y y el Windows Boot Manager (bootmgfw.efi).
Admite la carga de controladores UEFI de sistemas de archivos.

Véase también Wikipedia:Comparación de gestores de arranque

Kernel

El kernel es el núcleo de un sistema operativo. Funciona en un nivel bajo (kernelspace) que interactúa entre el hardware de la máquina y los programas que utilizan los recursos del hardware para funcionar. Mientras tanto, el kernel detiene temporalmente los programas para ejecutar otros programas, lo que se conoce como multitarea apropiativa. Esto crea la ilusión de que muchas tareas se ejecutan simultáneamente, incluso en una CPU de un solo núcleo. El kernel utiliza el planificador de la CPU para decidir qué programa tiene prioridad en un momento dado.

initramfs

Después de que el gestor de arranque cargue el kernel y los posibles archivos initramfs y ejecute el kernel, el kernel desempaqueta los archivos initramfs (sistema de archivos RAM inicial) en los (entonces vacíos) rootfs (sistema de archivos raíz inicial, específicamente un ramfs o tmpfs). El primer initramfs extraído es el que está incrustado en el binario del kernel durante la compilación del mismo, luego se extraen los posibles archivos initramfs externos. Por lo tanto, los archivos en el initramfs externo sobrescriben los archivos con el mismo nombre en el initramfs incrustado. El kernel ejecuta luego /init (en rootfs) como el primer proceso. El espacio de usuario inicial comienza.

Arch Linux utiliza un archivo vacío para el initramfs integrado (que es el predeterminado cuando se construye Linux). Véase mkinitcpio para obtener información más específica de Arch sobre los initramfs externos.

El propósito de initramfs es arrancar el sistema hasta el punto en que pueda acceder al sistema de archivos raíz (véase FHS para obtener más información). Esto significa que cualquier módulo que se requiera para dispositivos como IDE, SCSI, SATA, USB/FW (si se arranca desde una unidad externa) debe poder cargarse desde initramfs si no está integrado en el kernel; Una vez que se cargan los módulos adecuados (ya sea explícitamente a través de un programa o script, o implícitamente a través de udev), el proceso de arranque continúa. Por esta razón, el initramfs solo necesita contener los módulos necesarios para acceder al sistema de archivos raíz; no es necesario que contenga todos los módulos que uno quiera usar. La mayoría de los módulos se cargarán más tarde por udev, durante el proceso de inicio (Init).

Proceso init

En la etapa final del espacio de usuario inicial, la verdadera raíz se monta y luego reemplaza el sistema de archivos raíz inicial. Se ejecuta /sbin/init, reemplazando el proceso /init. Arch utiliza systemd como init predeterminado.

getty

init llama a getty una vez por cada terminal virtual (típicamente seis de ellos), lo que inicializa cada tty y solicita un nombre de usuario y una contraseña. Una vez que se proporcionan el nombre de usuario y la contraseña, getty los compara con /etc/passwd y /etc/shadow, luego llama al inicio de sesión. Alternativamente, getty puede iniciar un gestor de pantalla si hay uno presente en el sistema.

Gestor de pantallas

Se puede configurar un gestor de pantalla para reemplazar el indicador de inicio de sesión getty en un tty.

Para inicializar automáticamente un gestor de pantalla después del arranque, es necesario activar manualmente el servicio a través de systemd. Para obtener más información sobre cómo activar e iniciar unidades de servicio, véase systemd (Español)#Utilizar las unidades.

Inicio de sesión

El programa login inicia una sesión para el usuario configurando variables de entorno e iniciando el intérprete de órdenes del usuario, basado en /etc/passwd.

El programa login muestra el contenido de /etc/motd (mensaje del día) después de un inicio de sesión exitoso, justo antes de que se ejecute el intérprete de órdenes de inicio de sesión. Es un buen lugar para mostrar sus términos de servicio para recordar a los usuarios sus políticas locales o cualquier cosa que desee decirles.

Intérprete de órdenes

Una vez que el intérprete de órdenes del usuario se inicia, normalmente ejecutará un archivo de configuración, como bashrc, antes de presentar el indicador del intérprete de órdenes al usuario. Si la cuenta está configurada para arrancar X al iniciar sesión, el archivo de configuración llamará a startx o xinit.

GUI, xinit o wayland

xinit ejecuta el archivo de configuración xinitrc del usuario, que normalmente inicia un gestor de ventanas. Cuando el usuario finaliza y sale del gestor de ventanas, xinit, startx, el intérprete de órdenes y el inicio de sesión finalizarán en ese orden, volviendo a getty.

Véase también