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
.
Artículos relacionados
Master Boot Record
GUID Partition Table
Unified Extensible Firmware Interface
mkinitcpio
init
systemd
fstab
Autostarting
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.
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
/EFI/
nombre del 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.
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
\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 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.
Nota
La carga de las actualizaciones de
microcódigo
requiere unos ajustes en la configuración del gestor de arranque.
[1]
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.
El cifrado mencionado en la compatibilidad del sistema de archivos es un
cifrado a nivel de sistema de archivos
, no tiene relación con el
cifrado a nivel de bloque
.
Nombre
Firmware
Tabla de particiones
Multi-arranque
Sistemas de archivos
Notas
BIOS
UEFI
MBR
GPT
Btrfs
Ext4
ReiserFS
VFAT
XFS
EFISTUB
–
Sí
Sí
Sí
–
–
–
–
Heredado del firmware
1
–
Kernel convertido en ejecutable EFI para ser iniciado directamente desde el firmware
UEFI
u otro gestor de arranque.
Clover
Emula UEFI
Sí
Sí
Sí
Sí
1
No
Sin cifrado
No
Heredado del firmware
1
No
Bifurcación de rEFIt modificada para ejecutar
macOS en hardware que no es de Apple
.
GRUB
Sí
Sí
Sí
Sí
Sí
Sí
Sí
Sí
Sí
Sí
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
No
Sí
Sí
Sí
Sí
1
Sin cifrado
Sin cifrado
Sin características
tail-packing
Heredado del firmware
1
No
Soporta autodetección de kernel y parámetros sin configuración explícita, y soporta fastboot
[2]
.
Syslinux
Sí
Parcial
Sí
Sí
Parcial
Sin: volúmenes multi-dispositivo, compresión, cifrado
Sin cifrado
No
Sí
MBR solamente; sin inodos dispersos
No admite ciertas características de los
sistemas de archivos
[3]
No tiene controladores de sistema de archivos
[4]
, solo puede acceder al sistema de archivos en el que se instaló.
systemd-boot
No
Sí
Instalación manual solamente
Sí
Sí
2
No
No
No
Heredado del firmware
1
No
No se pueden ejecutar binarios desde particiones que no sean el
ESP
o la partición extendida de arranque (partición XBOOTLDR).
GRUB Legacy
Sí
No
Sí
No
Sí
No
No
Sí
Sí
Solo XFS v4
Descontinuado
a favor de
GRUB
.
LILO
Sí
No
Sí
No
Sí
No
Sin cifrado
Sí
Sí
Sí
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
[5]
, 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
CONFIG_EFI_STUB=y
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
/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
Early Userspace en Arch Linux
El Proceso de Arranque de Linux desde Dentro
Wikipedia: Proceso de inicio de Linux
Wikipedia: initrd
Del Arranque de Linux con GRUB en Modo Single User
NeoSmart: El proceso de arranque BIOS/MBR
Kernel Newbie Corner: initrd e initramfs
Rod Smith - Manejando los gestores de arranque EFI para Linux