Arch boot process (Español)

Para iniciar Arch Linux, debe configurarse un gestor de arranque capaz de iniciar Linux. El gestor de arranque es el responsable de cargar el kernel y el disco ram inicial antes de iniciar el proceso de arranque. El proceso es bastante diferente para los sistemas BIOS y UEFI, cuyos detalles se describen en esta página o en las enlazadas.

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.

Tipos de firmware

BIOS

Una BIOS o sistema básico de entrada-salida (Basic Input-Output System) es el primer programa (firmware) que se ejecuta una vez que se enciende el sistema. En la mayoría de los casos, se almacena en una memoria flash en la propia placa base e independiente del almacenamiento del sistema.

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, Apple Mac admite (y de forma predeterminada) sus propios controladores de sistema de archivos HFS+. Las implementaciones UEFI también son compatibles con ISO-9660 para discos ópticos.

UEFI lanza aplicaciones EFI, por ejemplo. 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 en la carpeta . 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.

Inicialización del sistema

Bajo BIOS

Encendido del sistema, se ejecuta la autoprueba de encendido (POST).
Después del POST, la BIOS inicializa el hardware requerido para el inicio (disco, controladores de teclado, etc.).
BIOS inicia los primeros 440 bytes (el área del código de arranque del MBR) del primer disco según el orden de la BIOS.
La primera etapa del cargador de arranque en el código de arranque del MBR, luego inicia el código de su segunda etapa (si existe) desde:
- sectores de discos siguientes tras el MBR, por ejemplo la denominada brecha posterior al MBR (solo en la tabla de particiones MBR).
- un disco de partición o un disco sin partición volume boot record (VBR).
- la partición de inicio de BIOS (GRUB solo en BIOS/GPT).
Se inicia el gestor de arranque.
El gestor de arranque carga un sistema operativo ya sea en cadena o cargando directamente el kernel del sistema operativo.

Bajo UEFI

Encendido del sistema, se ejecuta la autoprueba de encendido (POST).
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 ( 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 ser un gestor de arranque o el 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 del binario EFI por la firma.

Nota: Algunos sistemas UEFI solo pueden arrancar desde la ruta de inicio alternativa.

Arranque múltiple en UEFI

Dado que cada sistema operativo o proveedor puede mantener sus propios archivos dentro de la partición del sistema EFI sin afectar al otro, el arranque múltiple con UEFI es simplemente una cuestión de iniciar una aplicación EFI diferente correspondiente al gestor de arranque del sistema operativo en particular. Esto elimina la necesidad de confiar en los mecanismos de carga en cadena de un gestor de arranque para cargar otro sistema operativo.

Véase también Arranque dual con Windows.

Gestor de arranque

Un gestor de arranque es un programa iniciado por el firmware (BIOS o UEFI). Es responsable de cargar el kernel con los parámetros del kernel y disco RAM inicial según los archivos de configuración. En el caso de UEFI, el kernel en sí puede ser lanzado directamente por el UEFI utilizando el código auxiliar de arranque EFI. Aún se puede usar un gestor de arranque separado para editar los parámetros del kernel antes de arrancar.

Advertencia: Un gestor de arranque debe poder acceder al kernel y a las imágenes initramfs; de lo contrario, el sistema no se iniciará. Por lo tanto, en una configuración típica, debe soportar el acceso /boot. Eso significa que debe tener soporte para todo, comenzando desde los dispositivos de bloque, los dispositivos de bloque apilados (LVM, RAID, dm-crypt, LUKS, etc) y terminando con el sistema de archivos en el que residen el (los) núcleo(s) y las imágenes initramfs.

Comparación de características

Nombre	Firmware		Tabla de particiones		Multi-arranque	Sistemas de archivos					Notas
Nombre	BIOS	UEFI	MBR	GPT	Multi-arranque	Btrfs	Ext4	ReiserFS	VFAT	XFS	Notas
EFISTUB											Kernel convertido en ejecutable EFI para ser iniciado directamente desde el firmware UEFI u otro gestor de arranque.
Clover					¹						Bifurcación de rEFIt modificada para ejecutar macOS en hardware que no es de Apple.
GRUB											En la configuración de BIOS/GPT requiere una partición de arranque BIOS. Soporta RAID, LUKS1 y LVM (pero no volúmenes aprovisionados ligeros).
rEFInd					¹						Soporta autodetección de kernel y parámetros sin configuración explícita, y soporta fastboot .
Syslinux		Parcial			Parcial						No admite ciertas características de los sistemas de archivos No tiene controladores de sistema de archivos, solo puede acceder al sistema de archivos en el que se instaló.
systemd-boot					²						No se pueden ejecutar binarios desde particiones que no sean el ESP o la partición extendida de arranque (partición XBOOTLDR).
											Descontinuado a favor de GRUB.
											Descontinuado debido a sus limitaciones (por ejemplo, con Btrfs, GPT, RAID).

La compatibilidad con el sistema de archivos es heredada del firmware. La especificación UEFI exige compatibilidad con los sistemas de archivos FAT12, FAT16 y FAT32 , pero los proveedores pueden añadir opcionalmente compatibilidad con sistemas de archivos adicionales; por ejemplo, el firmware de Apple Mac es compatible con el sistema de archivos HFS+. Si el firmware proporciona una interfaz para cargar controladores UEFI al inicio, entonces se puede añadir soporte para sistemas de archivos adicionales cargando controladores del sistema de archivos (adquiridos independientemente).
Un gestor de arranque solo puede iniciar otras aplicaciones EFI, por ejemplo, imágenes del kernel de Linux creadas con y bootmgfw.efi de Windows.

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 (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 , reemplazando el proceso . 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 , 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

gollark: No, overwrite the BIOS and/or firmware with zeros so no buggy code can run again. Ever.

gollark: Well, we made the two esoteric bots.

gollark: One person to manage emojis, one to view audit logs, one to be able to assign roles, etc.

gollark: To ensure proper distribution of powers, you should have many submods with one permission each.

gollark: The best form of government is of course anarchototalitarianism.

This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.