Difference between revisions of "Arch boot process (Español)"

From ArchWiki
Jump to: navigation, search
m (corrección de enlace al artículo en español -> Bashrc (Español))
 
(74 intermediate revisions by 10 users not shown)
Line 1: Line 1:
 
[[Category:Boot process (Español)]]
 
[[Category:Boot process (Español)]]
 
[[Category:About Arch (Español)]]
 
[[Category:About Arch (Español)]]
{{i18n|Arch Boot Process}}
+
[[ar:Arch boot process]]
 +
[[cs:Arch boot process]]
 +
[[en:Arch boot process]]
 +
[[fr:Processus de boot]]
 +
[[it:Arch boot process]]
 +
[[ja:Arch ブートプロセス]]
 +
[[pt:Arch boot process]]
 +
[[ru:Arch boot process]]
 +
[[zh-hans:Arch boot process]]
 +
{{TranslationStatus (Español)|Arch boot process|2018-10-08|546665}}
 +
{{Related articles start (Español)}}
 +
{{Related2|Master Boot Record (Español)|Master Boot Record}}
 +
{{Related2|GUID Partition Table (Español)|GUID Partition Table}}
 +
{{Related2|Unified Extensible Firmware Interface (Español)|Unified Extensible Firmware Interface}}
 +
{{Related2|mkinitcpio (Español)|mkinitcpio}}
 +
{{Related|init}}
 +
{{Related2|systemd (Español)|systemd}}
 +
{{Related2|fstab (Español)|fstab}}
 +
{{Related2|Autostarting (Español)|Autostarting}}
 +
{{Related articles end}}
  
{{Article summary start}}
+
Para iniciar Arch Linux, debe configurarse un [[#Gestor de arranque|gestor de arranque]] capaz de iniciar Linux. El gestor de arranque es el responsable de cargar el kernel y el [[mkinitcpio (Español)|disco ram inicial]] antes de iniciar el proceso de arranque. El proceso es bastante diferente para los sistemas [[Wikipedia:es:BIOS|BIOS]] y [[Unified Extensible Firmware Interface (Español)|UEFI]], cuyos detalles se describen en esta página o en las enlazadas.
{{Article summary text|?}}
 
{{Article summary heading|Overview}}
 
{{Article summary text|{{Boot process overview}}}}
 
{{Article summary heading|Related}}
 
{{Article summary wiki|fstab}}
 
{{Article summary wiki|rc.conf}}
 
{{Article summary end}}
 
  
Este articulo tiene como objetivo dar una visión cronológica del proceso de arranque de Arch y los archivos y procesos involucrados, proveyendo enlaces a artículos relevantes de la wiki cuando es necesario. Arch sigue la convención de init de BSD, contrariamente al común SysV. Esto significa que hay poca distinción entre los niveles de ejecución, debido a que el sistema por defecto esta configurado para usar los mismos módulos y ejecutar los mismos procesos en todos los niveles de ejecución. La ventaja es que los usuarios tienen una simple manera de configurar el proceso de inicio (ver [[rc.conf]]); la desventaja es que algunas opciones de configuración muy especificas que ofrece SysV, son perdidas. Ver [[Adding Runlevels]] para poder agregar algunas capacidades parecidas a SysV en Arch. Ver [[Wikipedia:init]] para mas información en las distinciones entre el estilo SysV y el estilo BSD.
+
== Tipos de firmware ==
  
== Antes de init ==
+
=== BIOS ===
Luego de que el sistema es encendido y que [[Wikipedia:Power-on self-test|POST]] es completado, la BIOS localizara el medio preferido de arranque y transferira el control de este dispositivo al [[Master Boot Record]]. En un sistema GNU/Linux, comúnmente se encuentra un gestor de arranque como [[GRUB]] o [[LILO]] y luego se carga desde el MBR. El gestor de arranque presentara al usuario un rango de opciones para arrancar, por ejemplo Arch Linux y Windows en [[Windows and Arch Dual Boot|dual-boot setup]]. Una vez que Arch es seleccionado, la imagen de kernel en el directorio {{Filename|/boot}} (actualmente {{Filename|kernel26.img}}) es descomprimida y cargada en memoria.
 
  
 +
Una [[Wikipedia:es:BIOS|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.
  
El kernel es el núcleo de un sistema operativo. Este funciona en un nivel bajo (''kernelspace'') interactuando entre el hardware de la maquina, y los programas que usan el hardware para funcionar. Para hacer un uso eficiente del CPU, el kernel usa un planificador para arbitrar cuales tareas tienen prioridad a cada momento, creando la ilusión (para la percepción humana)  de que varias tareas están siendo ejecutadas simultáneamente.
+
=== UEFI ===
  
Luego de que el kernel es cargado, este lee el [[initramfs]] (sistema de archivos RAM inicial). El propósito de initramfs es de bootstrap el sistema a el punto donde este puede acceder al sistema de archivos raíz (ver [[FHS]] para detalles). Esto significa que cualquier modulo requerido por dispositivos como IDE, SCSI, o SATA (o USB/FW, si se esta arrancando desde una unidad USB/FW) tiene que ser cargado. Una vez que initramfs carga los módulos adecuados, manualmente o mediante [[udev]], este pasa el control a el kernel y el proceso de arranque continua. Por esta razón, initrd solo necesita contener los módulos necesarios para acceder al sistema de archivos raíz; no necesita contener cualquier otro modulo que uno quiera usar. La mayoría de los módulos serán cargaos mas tarde por udev, durante el proceso init.
+
[[Unified Extensible Firmware Interface (Español)|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.
  
El kernel luego busca el programa {{Codeline|init}} que reside en {{Filename|/sbin/init}}. {{Codeline|init}} se basa en {{Codeline|glibc}}, la biblioteca C GNU. Las bibliotecas son colecciones de rutinas de programa frecuentemente usadas y son ifentificables mediante la extension {{Filename|*.so}}. Estas son escenciales para la funcionalidad basica del sistema. Esta parte del proceso de arranque es llamada ''early userspace''.
+
La especificación UEFI exige el soporte para los sistemas de archivos [[FAT|FAT12, FAT16, y FAT32]] (véase [http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_7_A%20Sept%206.pdf#G17.1019485 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.
  
== init: Los scripts de arranque de Arch ==
+
UEFI lanza aplicaciones EFI, por ejemplo. [[#Gestor de arranque|gestores de arranque]], [[Unified Extensible Firmware Interface (Español)#Intérprete de órdenes UEFI|intérpretes de órdenes UEFI]], etc. Estas aplicaciones generalmente se almacenan como archivos en la [[EFI system partition (Español)|partición del sistema EFI]]. Cada proveedor puede almacenar sus archivos en la partición del sistema EFI en la carpeta {{ic|/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.
El principal proceso de arranque de Arch es iniciado por el programa {{Codeline|init}}, que llama a todos los demás procesos. El propósito de {{Codeline|init}} es el de brindad el sistema a un estado utilizable, usando los scripts de arranque para lograrlo. Como se menciono previamente, Arch usa scripts de arranque de estilo BSD. {{Codeline|init}} lee el archivo {{Codeline|/etc/inittab}}. Por defecto, {{Codeline|/etc/inittab}} empieza con lo siguiente:
 
  
 +
== Inicialización del sistema ==
  
{{File
+
=== Bajo BIOS ===
|name=/etc/inittab
 
|content=<nowiki>
 
...
 
  
# Boot to console
+
# Encendido del sistema, se ejecuta la [[Wikipedia:es:POST|autoprueba de encendido (POST)]].
id:3:initdefault:
+
# Después del POST, la BIOS inicializa el hardware del sistema necesario para el inicio (disco, controladores de teclado, etc.).
# Boot to X11
+
# BIOS inicia los primeros 440 bytes ([[Partitioning#Master Boot Record (bootstrap code)|el área del código de arranque del MBR]]) del primer disco según el orden de la BIOS.
#id:5:initdefault:
+
# 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 [[Wikipedia:Volume boot record|volume boot record (VBR)]].
 +
#* la [[BIOS boot partition (Español)|partición de inicio de BIOS]] ([[GRUB (Español)|GRUB]] solo en BIOS/GPT).
 +
# Se inicia el [[#Gestor de arranque|gestor de arranque]].
 +
# El gestor de arranque carga un sistema operativo ya sea en cadena o cargando directamente el kernel del sistema operativo.
  
rc::sysinit:/etc/rc.sysinit
+
=== Bajo UEFI ===
rs:S1:wait:/etc/rc.single
 
rm:2345:wait:/etc/rc.multi
 
rh:06:wait:/etc/rc.shutdown
 
su:S:wait:/sbin/sulogin
 
  
...
+
# Encendido del sistema, se ejecuta la [[Wikipedia:es:POST|autoprueba de encendido (POST)]].
</nowiki>}}
+
# UEFI inicializa el hardware requerido para el arranque.
 +
# 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 [[EFI system partition (Español)|partición del sistema EFI]] en ese disco e intenta encontrar una aplicación EFI en la ruta de arranque alternativa {{ic|\EFI\BOOT\BOOTX64.EFI}} ({{ic|BOOTIA32.EFI}} en [[Unified Extensible Firmware Interface (Español)#Firmware de UEFI|IA32 (32 bits) sistemas EFI]]). 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|gestor de arranque]] o el [[kernel (Español)|kernel]] de Arch usando [[EFISTUB (Español)|EFISTUB]].
 +
#* Podría ser alguna otra aplicación EFI, como un intérprete de órdenes UEFI o un [[#Gestor de arranque|gestor de arranque]] como [[systemd-boot (Español)|systemd-boot]] o [[rEFInd]].
  
La primer linea no comentada define el nivel de ejecución del sistema por defecto (3). Cuando el kernel llama init:
+
Si el [[Secure Boot|inicio seguro]] está habilitado, el proceso de arranque verificará la autenticidad del binario EFI por la firma.
  
* Primero, el principal script de inicializacion es ejecutado, {{Filename|/etc/rc.sysinit}} (un script [[Bash]]).
+
{{Nota|Algunos sistemas UEFI solo pueden arrancar desde la ruta de inicio alternativa.}}
* Si se inicia en modo de usuario simple (nivel de ejecución 1 o S), el script {{Filename|/etc/rc.single}} sera ejecutado.
 
* Si se inicia en cualquier otro nivel (2-5), se ejecuta en vez {{Filename|/etc/rc.multi}}.
 
* El ultimo script ejecutado sera {{Filename|/etc/rc.local}} (mediante {{Filename|/etc/rc.multi}}), que esta vació por defecto.
 
  
 +
=== Arranque múltiple en UEFI ===
  
=== {{Filename|/etc/rc.sysinit}} ===
+
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|gestor de arranque]] para cargar otro sistema operativo.
{{Filename|rc.sysinit}} es un gran script de inicio que básicamente se hace cargo de toda la configuración de hardware y de la inicialización general de tareas. Este puede ser identificado por su primer tarea, imprimiendo las lineas:
 
  
Arch Linux
+
Véase también [[Dual boot with Windows (Español)|Arranque dual con Windows]].
http://www.archlinux.org
 
Copyright 2002-2007 Judd Vinet
 
Copyright 2007-2010 Aaron Griffin
 
Distributed under the GNU General Public License (GPL)
 
  
A rough overview of its tasks:
+
== Gestor de arranque ==
* Sources the {{Filename|/etc/rc.conf}} script
 
* Sources the {{Filename|/etc/rc.d/functions}} script
 
* Displays a welcome message
 
* Mounts various virtual file systems
 
* Creates dummy device files
 
* Starts [[minilogd]]
 
* Outputs messages from [[dmesg]]
 
* Configures the hardware clock
 
* Empties the {{Filename|/proc/sys/kernel/hotplug}} file
 
* Starts [[udev]] and checks for udev events
 
* Starts the [[loopback]] interface
 
* Loads modules from the {{Codeline|MODULES}} array defined in [[rc.conf]]
 
* Configures RAID and encrypted filesystem mappings
 
* Runs a forced check of partitions ([[fsck]]) if the [[fstab|/etc/fstab]] file contains instructions to do so
 
* Mounts local partitions and swap (networked drives are not mounted before a network profile is up)
 
* Activates [[swap]] areas
 
* Sets the hostname, locale and system clock as defined in {{Filename|rc.conf}}
 
* Removes various leftover/temporary files, such as {{Filename|/tmp/*}}
 
* Configures the [[locale]], console and keyboard mappings
 
* Sets the console font
 
* Writes output from dmesg to {{Filename|/var/log/dmesg.log}}
 
  
{{Filename|/etc/rc.sysinit}} es un script y no un lugar para configuraciones. Sus origenes () is a script and not a place for settings. It sources (i.e. reads and inherits variables and functions) [[rc.conf]] for settings and {{Filename|/etc/rc.d/functions}} for the functions that produce its graphical output (nice colors, alignments, switching 'busy' to 'done', etc.) There is no particular need to edit this file, although some may wish to do so in order to speed up the boot process.
+
El gestor de arranque es la primera pieza de software iniciada por [[Wikipedia:BIOS|BIOS]] o [[UEFI]]. Es responsable de cargar el kernel con los [[kernel parameters (Español)|parámetros del núcleo]] deseados, y el [[mkinitcpio (Español)|disco RAM inicial]] en función de los archivos de configuración.
  
=== {{Filename|/etc/rc.single}} ===
+
{{Nota|La carga de las actualizaciones de [[Microcode (Español)|microcódigo]] requiere unos ajustes en la configuración del gestor de arranque. [https://www.archlinux.org/news/changes-to-intel-microcodeupdates/]}}
Single-user mode will boot straight into the root user account and should only be used if one cannot boot normally. This script ensures no daemons are running except for the bare minimum: syslog-ng and udev. The single-user mode is useful for system recovery where preventing remote users from doing anything that might cause data loss or damage is necessary. In single-user mode, users can continue with the standard (multi-user) boot by entering 'exit' at the prompt.
 
  
=== {{Filename|/etc/rc.multi}} ===
+
=== Comparación de características ===
{{Filename|/etc/rc.multi}} is run on any multi-user runlevel (i.e. 2, 3. 4 and 5) which basically means any ordinary boot. Typically, users will not notice the transition from {{Filename|rc.sysinit}} to {{Filename|rc.multi}} as {{Filename|rc.multi}} also uses the functions file to produce output. This script has three tasks:
 
  
* First, it runs sysctl (to modify kernel parameters at runtime) which applies the settings in {{Filename|/etc/sysctl.conf}}. Arch has very few of these by default; mainly networking settings.
+
{{Nota|
* Secondly, and most importantly, it starts [[daemons]], as per the {{Codeline|DAEMONS}} array in {{Filename|rc.conf}}.
+
* 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 {{ic|/boot}}).
* Finally, it will run {{Filename|/etc/rc.local}}.  
+
* 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 [https://www.rodsbooks.com/gdisk/hybrid.html MBR híbrido], o el nuevo protocolo [http://repo.or.cz/syslinux.git/blob/HEAD:/doc/gpt.txt GPT-only]. Sin embargo, este protocolo puede causar problemas con ciertas implementaciones de BIOS; consulte [http://www.rodsbooks.com/gdisk/bios.html#bios rodsbooks] para más detalles.
 
+
* El cifrado mencionado en la compatibilidad del sistema de archivos es un [[wikipedia:Filesystem-level encryption|cifrado a nivel de sistema de archivos]], no tiene relación con el [[dm-crypt (Español)|cifrado a nivel de bloque]].
=== {{Filename|/etc/rc.local}} ===
+
}}
{{Filename|rc.local}} is the local multi-user startup script. Empty by default, it is a good place to put any last-minute commands the system should run at the very end of the boot process. Most common system configuration tasks (like loading modules, changing
 
the console font, or setting up devices) usually have a dedicated place where they belong. To avoid confusion, ensure that whatever one intends to add to {{Filename|rc.local}} is not already residing in {{Filename|/etc/profile.d}}, or any other existing configuration location instead.
 
 
 
When editing this file, keep in mind that it is run '''after''' the basic setup (modules/daemons), as the '''root''' user, and '''whether or not''' X starts. Here is an example which just un-mutes the ALSA sound settings:
 
 
 
{{File
 
|name=/etc/rc.local
 
|content=<nowiki>
 
#!/bin/bash
 
 
 
# /etc/rc.local: Local multi-user startup script.
 
 
 
amixer sset 'Master Mono' 50% unmute &> /dev/null
 
amixer sset 'Master' 50% unmute &> /dev/null
 
amixer sset 'PCM' 75% unmute &> /dev/null
 
</nowiki>}}
 
 
 
Another common usage for {{Filename|rc.local}} is to apply various hacks when one cannot make the ordinary initialization work correctly.
 
  
== Custom hooks ==
+
{| class="wikitable sortable"
Hooks can be used to include custom code in various places in the rc.* scripts.
+
! rowspan="2"| Nombre
{| class="wikitable"
+
! colspan="2"| Firmware
|-
+
! rowspan="2"| Multi-arranque
! scope="col" | Hook Name
+
! colspan="5"| [[File systems (Español)|Sistemas de archivos]]
! scope="col" | When hook is executed
+
! rowspan="2"| Notas
|-
 
| sysinit_start
 
| At the beginning of rc.sysinit
 
|-
 
| sysinit_udevlaunched
 
| After udev has been launched in rc.sysinit
 
|-
 
| sysinit_udevsettled
 
| After uevents have settled in rc.sysinit
 
|-
 
| sysinit_prefsck
 
| Before fsck is run in rc.sysinit
 
|-
 
| sysinit_postfsck
 
| After fsck is run in rc.sysinit
 
|-
 
| sysinit_premount
 
| Before local filesystems are mounted, but after root is mounted read-write in rc.sysinit
 
|-
 
| sysinit_end
 
| At the end of rc.sysinit
 
 
|-
 
|-
| multi_start
+
! BIOS !! [[Unified Extensible Firmware Interface (Español)|UEFI]]
| At the beginning of rc.multi
+
! [[Btrfs]] !! [[Ext4 (Español)|ext4]] !! ReiserFS v3 !! [[VFAT]] !! [[XFS]]
 
|-
 
|-
| multi_end
+
| [[EFISTUB (Español)|EFISTUB]]
| At the end of rc.multi
+
| {{-}} || {{Si}}
 +
| {{-}}
 +
| {{-}} || {{-}} || {{-}} || {{Y|Solo ESP}} || {{-}}
 +
| Kernel convertido en ejecutable EFI para ser iniciado directamente desde el firmware [[Unified Extensible Firmware Interface (Español)|UEFI]] u otro gestor de arranque.
 
|-
 
|-
| single_start
+
| [[Clover]]
| At the beginning of rc.single
+
| {{G|Emula UEFI}} || {{Si}}
 +
| {{Si}}
 +
| {{No}} || {{Y|Sin cifrado}} || {{No}} || {{Si}} || {{No}}
 +
| Bifurcación de rEFIt modificada para ejecutar [[wikipedia:es:Hackintosh|macOS en hardware que no es de Apple]].
 
|-
 
|-
| single_prekillall
+
| [[GRUB (Español)|GRUB]]
| Before all processes are being killed in rc.single
+
| {{Si}} || {{Si}}
 +
| {{Si}}
 +
| {{Y|Sin compresión zstd}} || {{Si}} || {{Si}} || {{Si}} || {{Si}}
 +
| En la configuración de BIOS/GPT requiere una [[BIOS boot partition|partición de arranque BIOS]]. <br/>Soporta RAID, LUKS1 y LVM (pero no volúmenes aprovisionados ligeros).
 
|-
 
|-
| single_postkillall
+
| [[rEFInd]]
| After all processes have been killed in rc.single
+
| {{No}} || {{Si}}
 +
| {{Si}}
 +
| {{Y|Sin: cifrado, compresión zstd}} || {{Y|Sin cifrado}} || {{Y|Sin características ''tail-packing''}} || {{Si}} || {{No}}
 +
| Soporta autodetección de kernel y parámetros sin configuración explícita.
 
|-
 
|-
| single_udevlaunched
+
| [[Syslinux (Español)|Syslinux]]
| After udev has been launched in rc.single
+
| {{Si}} || {{Y|[[Syslinux (Español)#Limitaciones de Syslinux en la modalidad UEFI|Parcial]]}}
 +
| {{Y|[[Syslinux (Español)#Chainloading|Parcial]]}}
 +
| {{Y|Sin: volúmenes multi-dispositivo, compresión, cifrado}} || {{Y|Sin cifrado}} || {{No}} || {{Si}} || {{Y|v4 en [[Partitioning (Español)#Master Boot Record|MBR]] solo}}
 +
| No admite ciertas características de los [[File systems (Español)|sistemas de archivos]] [http://www.syslinux.org/wiki/index.php?title=Filesystem]
 
|-
 
|-
| single_udevsettled
+
| [[systemd-boot (Español)|systemd-boot]]
| After uevents have settled in rc.single
+
| {{No}} || {{Si}}
 +
| {{Si}}
 +
| {{No}} || {{No}} || {{No}} || {{Y|Solo ESP}} || {{No}}
 +
| No se pueden ejecutar binarios desde particiones que no sean [[EFI system partition|ESP]].
 
|-
 
|-
| single_end
+
| {{Grey|[[GRUB Legacy]]}}
| At the end of rc.single
+
| {{Y|Sin GPT}} || {{No}}
 +
| {{Si}}
 +
| {{No}} || {{No}} || {{Si}} || {{Si}} || {{Y|Solo v4}}
 +
| [https://www.gnu.org/software/grub/grub-legacy.html Descontinuado] a favor de [[GRUB (Español)|GRUB]].
 
|-
 
|-
| shutdown_start
+
| {{Grey|[[LILO (Español)|LILO]]}}
| At the beginning of rc.shutdown
+
| {{Y|Sin GPT}} || {{No}}
|-
+
| {{Si}}
| shutdown_prekillall
+
| {{No}} || {{Y|Sin cifrado}} || {{Si}} || {{Si}} || {{Y|Solo MBR [http://xfs.org/index.php/XFS_FAQ#Q:_Does_LILO_work_with_XFS.3F]}}
| Before all processes are being killed in rc.shutdown
+
| [http://web.archive.org/web/20180323163248/http://lilo.alioth.debian.org/ Descontinuado] debido a sus limitaciones (por ejemplo, con Btrfs, GPT, RAID).
|-
 
| shutdown_postkillall
 
| After all processes have been killed in rc.shutdown
 
|-
 
| shutdown_poweroff
 
| Directly before powering off in rc.shutdown
 
 
|}
 
|}
  
To define a hook function, create a file in /etc/rc.d/functions.d using:
+
Véase también [[Wikipedia:Comparison of boot loaders|Wikipedia:Comparación de gestores de arranque]]
<pre>
+
 
function_name() {
+
== Kernel ==
  ...
+
 
}
+
El [[kernel (Español)|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.
add_hook hook_name function_name
+
 
</pre>
+
== initramfs ==
Files in /etc/rc.d/functions.d are sourced from {{Filename|/etc/rc.d/functions}}.
+
 
You can register multiple hook functions for the same hook, as well as registering the same hook function for multiple hooks. Don't define functions named add_hook or run_hook in these files, as they are defined in {{Filename|/etc/rc.d/functions}}.
+
Una vez cargado el kernel, este desempaqueta el [[initramfs (Español)|initramfs]] (sistema de archivos RAM inicial), que se convierte en el sistema de archivos raíz inicial. El kernel ejecuta entonces {{ic|/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 (Español)|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 (Español)|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)''.
  
==== Example ====
+
== Proceso de inicio (Init) ==
Adding the following file will disable the write-back cache on a hard drive <i>before</i> any daemons are started (useful for drives containing MySQL InnoDB files).
+
 
{{File|name=/etc/rc.d/functions.d/hd_settings|content=hd_settings() {
+
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 {{ic|/sbin/init}}, reemplazando el proceso {{ic|/init}}. Arch utiliza [[systemd (Español)|systemd]] como [[init]] predeterminado.
    /sbin/hdparm -W0 /dev/sdb
+
 
}
+
== Getty ==
add_hook sysinit_udevsettled hd_settings
+
 
add_hook single_udevsettled  hd_settings
+
[[init]] llama a [[getty]] una vez por cada [[Wikipedia:Virtual console|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 {{ic|/etc/passwd}} y {{ic|/etc/shadow}}, luego llama al [[#Inicio de sesión|inicio de sesión]]. Alternativamente, getty puede iniciar un gestor de pantalla si hay uno presente en el sistema.
}}
+
 
First it defines the function hd_settings, and then registers it for the single_udevsettled and sysinit_udevsettled hooks. The function will then be called immediately after uvents have settled in {{Filename|/etc/rc.d/rc.sysinit}} or {{Filename|/etc/rc.d/rc.single}}.
+
== Gestor de pantallas ==
 +
 
 +
Se puede configurar un [[Display manager (Español)|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 {{ic|/etc/passwd}}.
  
== init: Login ==
+
El programa ''login'' muestra el contenido de [[Wikipedia:motd (Unix)|/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.
By default, after the Arch boot scripts are completed, the {{Codeline|/sbin/agetty}} program prompts users for a login name. After a login name is received, {{Codeline|/sbin/agetty}} calls {{Codeline|/bin/login}} to prompt for the login password.
 
  
Finally, with a successful login, the {{Codeline|/bin/login}} program starts the user's default shell. The default shell and environment variables may be globally defined within {{Filename|/etc/profile}}. All variables within a user's home directory shall take precedence over those globally defined under {{Filename|/etc}}. For instance, if two conflicting variables are specified within {{Filename|/etc/profile}} and {{Filename|~/.bashrc}}, the one dictated by {{Filename|~/.bashrc}} shall prevail.
+
== Intérprete de órdenes ==
  
Other options include [[Automatic login to virtual console|mingetty]] which allows for auto-login and [[rungetty]] which allows for auto-login and automatically running commands and programs, e.g. the always useful htop.  
+
Una vez que el [[shell|intérprete de órdenes]] del usuario se inicia, normalmente ejecutará un archivo de configuración, como [[bashrc (Español)|bashrc]], antes de presentar el indicador del intérprete de órdenes al usuario. Si la cuenta está configurada para [[Start X at login (Español)|arrancar X al iniciar sesión]], el archivo de configuración llamará a [[startx (Español)|startx]] o [[xinitrc (Español)|xinit]].
  
The majority of users wishing to start an [[X]] server during the boot process will want to install a display manager, and see [[Display Manager]] for details. Alternatively, [[Start X at Boot]] outlines methods that do not involve a display manager.
+
== GUI, xinit o wayland ==
  
== See also ==
+
[[xinitrc (Español)|xinit]] ejecuta el archivo de configuración [[xinitrc (Español)|xinitrc]] del usuario, que normalmente inicia un [[Window manager (Español)|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.
  
* [[Startup files]]
+
== Véase también ==
  
== External resources ==
+
* [https://web.archive.org/web/20150430223035/http://archlinux.me/brain0/2010/02/13/early-userspace-in-arch-linux/ Early Userspace en Arch Linux]
* [http://www.cyberciti.biz/faq/grub-boot-into-single-user-mode/ Boot Linux Grub Into Single User Mode]
+
* [http://www.ibm.com/developerworks/linux/library/l-linuxboot/ El Proceso de Arranque de Linux desde Dentro]
* [http://www.linuxjournal.com/article/4622 Boot with GRUB]
+
* [[Wikipedia:es:Proceso de arranque en Linux|Wikipedia: Proceso de inicio de Linux]]
* [http://www.ibm.com/developerworks/linux/library/l-linuxboot/ Inside the Linux boot process]
+
* [[Wikipedia:es:initrd|Wikipedia: initrd]]
* [http://linux.about.com/library/cmd/blcmdl5_sysctl.conf.htm Linux / Unix Command: sysctl.conf]
+
* [http://www.cyberciti.biz/faq/grub-boot-into-single-user-mode/ Del Arranque de Linux con GRUB en Modo Single User]
* [http://bbs.archlinux.org/search.php?action=search&keywords=rc.local&search_in=topic&sort_dir=DESC&show_as=topics Search the forum for rc.local examples]
+
* [https://neosmart.net/wiki/mbr-boot-process/ NeoSmart: El proceso de arranque BIOS/MBR]
* [[Wikipedia:Linux startup process]]
+
* [https://www.linux.com/learn/kernel-newbie-corner-initrd-and-initramfs-whats Kernel Newbie Corner: initrd e initramfs]
* [[Wikipedia:initrd]]
+
* [http://www.rodsbooks.com/efi-bootloaders/ Rod Smith - Manejando los gestores de arranque EFI para Linux]

Latest revision as of 21:36, 18 October 2018

Estado de la traducción
Este artículo es una traducción de Arch boot process, revisada por última vez el 2018-10-08. 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 IA32 (32 bits) sistemas EFI). 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