Arch boot process (Español)

From ArchWiki
Jump to: navigation, search
Estado de la traducción
Este artículo es una traducción de Arch boot process, revisada por última vez el 2018-11-11. Si advierte que la versión inglesa ha cambiado puede ayudar a actualizar la traducción, bien por usted mismo o bien avisando al equipo de traducción.

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 en el 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érpretes 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.

Inicialización del sistema

Bajo BIOS

  1. Encendido del sistema, se ejecuta la autoprueba de encendido (POST).
  2. Después del POST, la BIOS inicializa el hardware del sistema necesario para el inicio (disco, controladores de teclado, etc.).
  3. 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.
  4. 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:
  5. Se inicia el gestor de arranque.
  6. El gestor de arranque carga un sistema operativo ya sea en cadena o cargando directamente el kernel del sistema operativo.

Bajo UEFI

  1. Encendido del sistema, se ejecuta la autoprueba de encendido (POST).
  2. UEFI inicializa el hardware requerido para el arranque.
  3. 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.
  4. El firmware lanza la aplicación EFI.

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

El gestor de arranque es la primera pieza de software iniciada por BIOS o UEFI. Es responsable de cargar el kernel con los parámetros del núcleo deseados, y el disco RAM inicial en función de los archivos de configuración.

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:
  • Los gestores de arranque solo necesitan soporte del sistema de archivos en el que residen el kernel e initramfs (el sistema de archivos en el que se encuentra /boot).
  • 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 Multi-arranque Sistemas de archivos Notas
BIOS UEFI Btrfs ext4 ReiserFS v3 VFAT XFS
EFISTUB Si Solo ESP Kernel convertido en ejecutable EFI para ser iniciado directamente desde el firmware UEFI u otro gestor de arranque.
Clover Emula UEFI Si Si No Sin cifrado No Si No Bifurcación de rEFIt modificada para ejecutar macOS en hardware que no es de Apple.
GRUB Si Si Si Sin compresión zstd Si Si Si Si 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 Si Si Sin: cifrado, compresión zstd Sin cifrado Sin características tail-packing Si No Soporta autodetección de kernel y parámetros sin configuración explícita.
Syslinux Si Parcial Parcial Sin: volúmenes multi-dispositivo, compresión, cifrado Sin cifrado No Si v4 en MBR solo No admite ciertas características de los sistemas de archivos [2]
systemd-boot No Si Si No No No Solo ESP No No se pueden ejecutar binarios desde particiones que no sean ESP.
GRUB Legacy Sin GPT No Si No No Si Si Solo v4 Descontinuado a favor de GRUB.
LILO Sin GPT No Si No Sin cifrado Si Si Solo MBR [3] Descontinuado debido a sus limitaciones (por ejemplo, con Btrfs, GPT, RAID).

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. Para hacer un uso eficiente de la CPU, el kernel utiliza un sistema de programación para arbitrar qué tareas tienen prioridad en un momento dado, creando la ilusión de varias tareas siendo ejecutadas simultáneamente.

initramfs

Una vez cargado el kernel, este desempaqueta el initramfs (sistema de archivos RAM inicial), que se convierte en el sistema de archivos raíz inicial. El kernel ejecuta entonces /init como el primer proceso. El espacio de usuario inicial comienza.

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 de inicio (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.

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