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

From ArchWiki
Jump to: navigation, search
(/etc/rc.sysinit)
m (Tipos de firmware)
(12 intermediate revisions by 2 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)]]
 +
[[ar:Arch Boot Process]]
 
[[cs:Arch Boot Process]]
 
[[cs:Arch Boot Process]]
 
[[en:Arch Boot Process]]
 
[[en:Arch Boot Process]]
 
[[fr:Processus de boot]]
 
[[fr:Processus de boot]]
 
[[it:Arch Boot Process]]
 
[[it:Arch Boot Process]]
 +
[[ja:Arch Boot Process]]
 
[[ru:Arch Boot Process]]
 
[[ru:Arch Boot Process]]
 
[[zh-CN:Arch Boot Process]]
 
[[zh-CN:Arch Boot Process]]
{{Article summary start|Sumario}}
+
{{Related articles start (Español)}}
{{Article summary text|En este artículo se describe un recorrido cronológico del proceso de arranque de Arch.}}
+
{{Related|Boot Loaders}}
{{Article summary heading|Descripción}}
+
{{Related|Master Boot Record (Español)}}
{{Article summary text|Para iniciar Arch Linux, es necesario tener instalado en el [[Master_Boot_Record_(Español)|Master Boot Record (MBR)]] o en la [[GUID_Partition_Table_(Español)|GUID Partition Table (GPT)]] un gestor de arranque compatible con Linux como [[GRUB2_(Español)|GRUB(2)]], [[Syslinux|Syslinux]], [[LILO|LILO]] o [[GRUB_Legacy|GRUB Legacy]]. El gestor de arranque es responsable de cargar el kernel y el [[Mkinitcpio_(Español)|ramdisk inicial]] antes de iniciar el '''proceso de arranque de Arch'''.}}
+
{{Related|GUID Partition Table (Español)}}
{{Article summary heading|Relacionado}}
+
{{Related|Unified Extensible Firmware Interface (Español)}}
{{Article summary wiki|fstab}}
+
{{Related|mkinitcpio (Español)}}
{{Article summary wiki|rc.conf}}
+
{{Related|systemd (Español)}}
{{Article summary wiki|Autostarting}}
+
{{Related|fstab (Español)}}
{{Article summary end}}
+
{{Related|Autostarting (Español)}}
 +
{{Related articles end}}
  
Este artículo pretende describir el orden cronológico del proceso de arranque del Arch y de los archivos involucrados, proporcionando enlaces a artículos de la  wiki pertinentes cuando sea necesario. Arch como BSD utiliza init, contrariamente al más común SysV. Esto implica una leve distinción entre los niveles de ejecución, dado que el sistema por defecto está configurado para utilizar los mismos módulos y los mismos procesos en todos los niveles de ejecución. La ventaja es que los usuarios tienen una forma sencilla de configurar el proceso de inicio (consulte [[rc.conf]]); la desventaja es que algunas opciones de configuración interesantes que ofrece SysV se pierden. Consulte la guía sobre [[Adding_Runlevels|cómo agregar niveles de ejecución]] para poder utilizar algunas opciones de SysV en Arch. Consulte [[Wikipedia:init]] para más información sobre las diferencias entre SysV y el método BSD.
+
Para arrancar Arch Linux, un [[Boot Loaders|gestor de arranque]] capaz de iniciar Linux, como [[GRUB (Español)|GRUB]] o [[Syslinux (Español)|Syslinux]], debe estar instalado en el [[Master Boot Record (Español)|Master Boot Record]] o la [[GUID Partition Table (Español)|GUID Partition Table]]. El gestor de arranque es el responsable de cargar el kernel y el [[mkinitcpio (Español)|ramdisk inicial]] antes de iniciarse el proceso de arranque. El proceso es bastante diferente según se trate de un sistema [[Wikipedia:es:BIOS|BIOS]] o de [[Unified Extensible Firmware Interface (Español)|UEFI]], cuyos detalles se describen en esta página o en las enlazadas.
  
==Antes de init==
+
==Tipos de firmware==
Después de que el sistema está encendido y el [[Wikipedia: Power-on self-test|POST]] se ha completado, los BIOS identifica el dispositivo configurado para arrancar y pasa el control al sector de arranque [[Master Boot Record]] de este dispositivo. En una máquina GNU/Linux a menudo se instala en el MBR un gestor de arranque como [[GRUB]] o [[LILO]]. El gestor de arranque presenta al usuario una gama de opciones para el arranque, por ejemplo, Arch Linux y Windows [[Windows_and_Arch_Dual_Boot|configurando un arranque dual]]. Una vez que se ha seleccionado Arch, el bootloader carga el kernel ({{ic|vmlinuz-linux}}) y el ramdisk inicial ({{ic|initramfs-linux.img}}) en la memoria y luego se inicializa el kernel, pasando la dirección a la memoria de la imagen.
+
=== BIOS ===
  
El kernel es el núcleo de un sistema operativo. Funciona en un nivel bajo (''kernelspace'') que interactúan entre el hardware de la máquina y los programas que requieren los recursos 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 (para la precepción humana) que varias tareas se están ejecutando simultáneamente.
+
Una BIOS o ''«Basic Input-Output System»'' es el primer programa (firmware) que se ejecuta cuando el sistema es puesto en marcha. En la mayoría de los casos, este se almacena en una memoria flash en la propia placa base e independiente del almacenamiento del sistema.
 +
La BIOS lanza los primeros 440 bytes ([[Master Boot Record (Español)|Master Boot Record]]) del primer disco según el orden de discos de la BIOS. Dado que se puede obtener muy poco de un programa que debe adaptarse solo a los primeros 440 bytes del disco, por lo general, un gestor de arranque común como [[GRUB2 (Español)|GRUB]], [[Syslinux (Español)|Syslinux]] o [[LILO]] sería cargado por la BIOS, el cual, seguidamente, se ocuparía de cargar el sistema operativo, ya sea cargando los sistemas en cadena, ya sea cargando directamente el kernel.
  
Después de estar cargado, el Kernel descomprime el [[initramfs]] (sistema de archivos RAM inicial), el cual se convierte en el sistema de archivos del root inicial. El kernel, seguidamente, ejecuta {{ic|/init}} como primer proceso. El ''early userspace'' comienza.
+
=== UEFI===
  
El propósito de initramfs es arrancar el sistema hasta el punto donde se puede acceder al sistema de archivos raíz (consulte [[FHS]] para más detalles). Esto significa que los módulos que se requieren para dispositivos como IDE, SCSI, SATA (o USB/FireWire, si se efectúa el arranque desde una de estas unidades) deben ser cargables desde el initramfs si no están compilados en el kernel; una vez que los módulos necesarios se cargan (ya sea a través de un programa, ya sea a través de un script que tramite [[udev]]), el proceso de arranque continúa. Por esta razón, el initramfs sólo debe contener los módulos necesarios para acceder al sistema de archivos raíz, no tiene por qué contener todos los módulos que sirven al completo funcionamiento de la máquina. La mayoría de los módulos se cargarán más tarde por udev, durante la fase init.
+
UEFI tiene la capacidad de leer tanto la tabla de particiones, como de reconocer los sistemas de archivos. Por lo tanto, no está restringido por la limitación del código de los 440 bytes (código de arranque del MBR) como en los sistemas BIOS. No utiliza el código de arranque MBR en absoluto.
  
En la etapa final del early userspace, la verdadera raíz está montada, y reemplaza al sistema de archivos root inicial. {{ic|/sbin/init}} se ejecuta, sustituyendo el proceso {{ic|/init}}.
+
Los firmwares UEFI comunmente utilizados dan apoyo tanto a los sistemas de particionado MBR como GPT. Las EFI de Apple son conocidas por apoyar mapas de particionado Apple, además de MBR y GPT. La mayoría de los firmwares UEFI tienen soporte para acceder a sistemas de archivos FAT12 (disquetes), FAT16 y FAT32 en discos duros, y ISO9660 (y UDF) en CD/DVD. El firmware EFI en Apple puede acceder también a HFS/HFS+, aparte de los mencionados.
  
Consulte también: [http://archlinux.me/brain0/2010/02/13/early-userspace-in-arch-linux/ Early Userspace en Arch Linux]
+
UEFI no ejecuta ningún código de arranque del MBR, tanto si existe como si no. En su lugar, utiliza una partición especial de la tabla de particiones, llamada '''EFI SYSTEM PARTITION''' (partición del sistema EFI), en la que se guardan los archivos necesarios para ser lanzado el firmware. Cada proveedor puede almacenar sus archivos en la carpeta {{ic|<EFI SYSTEM PARTITION>/EFI/<FABRICANTE>/}} y pueden usar el firmware o la shell (shell de UEFI) para iniciar el programa de arranque. Una partición del sistema EFI usa, por lo general, el formato FAT32 (principalmente) o FAT16.
  
==Init y los scripts de arranque de Arch==
+
Bajo UEFI, todos los programas que son cargados por un sistema operativo o por otros instrumentos (como aplicaciones de pruebas de memoria) o herramientas de recuperación fuera del sistema operativo, deben ser aplicaciones UEFI correspondiente a la arquitectura del firmware EFI. La mayor parte de los firmware UEFI en el mercado, incluyendo los recientes Mac de Apple, usan un firmware EFI x86_64. Solo algunos Mac antiguos (anteriores a 2008) que funcionan utilizando EFI IA32 (32-bit), algunos ultrabooks recientes de Intel Cloverfield y algunas placas bases de Intel Servers, son conocidos por operar con un firmware  EFI 1.10 de Intel.
El principal proceso de arranque del Arch es iniciado por el programa {{ic|init}}, que genera todos los demás procesos. El propósito de {{ic|init}} es llevar el sistema a un estado que pueda ser utilizado, sirviéndose de los scripts de arranque para hacerlo. Como se mencionó anteriormente, Arch utiliza los script de arranque similares a los de BSD. {{ic|init}} lee el archivo {{ic|/etc/inittab}}; el archivo {{ic|inittab}}, por defecto, comienza con lo siguiente:
+
  
{{hc
+
Un firmware EFI x86_64 no incluye el soporte para lanzar aplicaciones de 32-bit (a diferencia del EFI de Linux y de Windows x86_64 que incluyen dicho apoyo). En definitiva, la aplicación UEFI (esto es, el gestor de arranque) debe ser compilada para la arquitectura correcta.
|/etc/inittab
+
|<nowiki>
+
...
+
  
# Boot to console
+
== Procesos de arranque ==
id:3:initdefault:
+
===Bajo BIOS===
# Boot to X11
+
#id:5:initdefault:
+
  
rc::sysinit:/etc/rc.sysinit
+
# Encendido del sistema &mdash;Power On Self Test&mdash;, o proceso [[wikipedia:es:POST|POST]].
rs:S1:wait:/etc/rc.single
+
# Después del POST la BIOS inicializa el hardware necesario para el arranque del sistema (disco, controladores del teclado, etc.).
rm:2345:wait:/etc/rc.multi
+
# La BIOS ejecuta el código de los primeros 440 bytes (la región del código de arranque del MBR) del primer disco de los que aparecen ordenados en la BIOS.
rh:06:wait:/etc/rc.shutdown
+
# El código de arranque del MBR entonces toma el control desde la BIOS y ejecuta el código de la siguiente etapa (en su caso) (normalmente, el código del gestor de arranque).
su:S:wait:/sbin/sulogin
+
# El código (segunda etapa) lanzado (el gestor de arranque presente) entonces lee los archivos de configuración y apoyo.
 +
# En base a los datos de los archivos de configuración, el gestor de arranque carga el kernel e initramfs en la memoria del sistema (RAM), e inicia el kernel.
  
...
+
=== Bajo UEFI ===
</nowiki>}}
+
  
La primera línea no comentada define el nivel de ejecución por defecto del sistema (3). Cuando el kernel llama a init:
+
Véase la página principal: [[Unified_Extensible_Firmware_Interface_(Español)#Proceso_de_arranque_bajo_UEFI|Proceso de arranque bajo UEFI ]].
  
* En primer lugar, el script de inicialización principal se ejecuta, {{ic|/etc/rc.sysinit}} (un script [[Bash]]).
+
== Kernel ==
* Seguidamente, si se inicia en modo monousuario (nivel 1 ó S), el script {{ic|/etc/rc.single}} será lanzado.
+
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 (para la precepción humana) que varias tareas se están ejecutando simultáneamente.  
* Si, por el contrario, se ejecuta otro nivel (2-5), será lanzado en su lugar {{ic|/etc/rc.multi}}.
+
* La última secuencia de comandos a ejecutar es {{ic|/etc/rc.local}} (a  través de {{ic|/etc/rc.multi}}) que está vacío de forma predeterminada.
+
  
{{Nota|Usted puede obtener mas información acerca de init e inittab [[Init_and_inittab_(Español)|aquí]]}}
+
== initramfs ==
 +
Después de estar cargado, el Kernel descomprime la imagen [[mkinitcpio (Español)|initramfs]] (sistema de archivos RAM inicial), que se convierte en el sistema de ficheros root inicial. El kernel seguidamente ejecuta {{ic|/init}} como el primer proceso. El primer espacio de usuario (''«early userspace»'') comienza.
  
===/etc/rc.sysinit===
+
El propósito de initramfs es arrancar el sistema hasta el punto donde se puede acceder al sistema de archivos raíz (consulte [[FHS]] para más detalles). Esto significa que los módulos que se requieren para dispositivos como IDE, SCSI, SATA, USB/FW (si el arranque se realiza desde una unidad externa) deben ser cargados desde initramfs si no están compilados en el kernel; una vez que los módulos necesarios se cargan (ya sea de forma explícita 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 sólo debe contener los módulos necesarios para acceder al sistema de archivos raíz, no tiene por qué contener todos los módulos que sirven al completo funcionamiento de la máquina. La mayoría de los módulos se cargarán más tarde por udev, durante la fase init.
El archivo {{ic|etc/rc.sysinit}} es un gran script que se ocupa de toda la configuración del hardware, y realiza tareas generales de inicialización. Puede ser identificado por una de sus primeras tareas, imprimiendo las líneas:
+
  
Arch Linux
+
== Fase init ==
http://www.archlinux.org
+
En la etapa final del ''«early userspace»'', el verdadero sistema de archivos root es montado, y pasa a sustituir al sistema de archivos root inicial. {{ic|/sbin/init}} se ejecuta, sustituyendo al proceso {{ic|/init}}. Arch Linus utiliza [[systemd (Español)|systemd]] como proceso init.
  
Las tareas de {{ic|rc.sysinit}} son los siguientes:
+
== Getty ==
# Incluir el archivo {{ic|/etc/rc.conf}}.
+
[[init]] lanza las [[getty]], una para cada [[Wikipedia:Virtual console|terminal virtual]] (normalmente seis de ellas), las cuales inicializan cada tty pidiendo el nombre de usuario y contraseña. Una vez que se proporcionan el nombre de usuario y la contraseña, getty los compara con las que se encuentran en {{ic|/etc/passwd}}, llamando a continuación al programa [[#Login|login]], para que, una vez inicida la sesión de usuario, lance la shell de usuario de acuerdo con lo definido en {{ic|/etc/passwd}}. Alternativamente, getty puede iniciar directamente un gestor de pantallas si existe uno presente en el sistema.
# Incluir el archivo de script {{ic|/etc/rc.d/functions}}.
+
# Mostrar un mensaje de bienvenida.
+
# Montar varios sistemas de archivos virtuales.
+
# Asegurarse que rootfs se monta en sólo lectura (si es necesario).
+
# Iniciar [[bootlogd]].
+
# Mostrar advertencias de desaprobación.
+
# Configurar el reloj del hardware.
+
# Iniciar [[udev]], cargar módulos desde la matriz {{ic|MODULES}} definidos en [[rc.conf]], y esperar a que termine de procesar udev eventos coldplug.
+
# Iniciar la interfaz de [[loopback]] .
+
# Configurar RAID, btrfs y las asignaciones del sistema de archivos cifrados.
+
# Verificar particiones ([[fsck]]).
+
# Volver a montar rootfs con el fin de aplicar las opciones de [[fstab|/etc/fstab.]]
+
# Montar sistemas de archivos locales (unidades de red no se montan antes de un perfil de red está arriba).
+
# Iniciar la supervisión de los grupos de volúmenes LVM.
+
# Activar áreas [[swap]] .
+
# Configurar la zona horaria.
+
# Inicializar la semilla random.
+
# Eliminar los residuos de los diversos archivos temporales, como {{ic|/tmp/*}}.
+
# Ajustar el nombre de la máquina (hostname), locale y reloj del sistema tal como se define en {{ic|rc.conf}}.
+
# Configurar [[locale]], la consola y la distribución del teclado.
+
# Establecer la fuente de la consola.
+
# Escribir la salida del comando en {{ic|/var/log/dmesg.log}}.
+
  
{{ic|/etc/rc.sysinit}} es un script y no un archivo de configuración. Ésto incluye (cuando obtiene las variables de) [[rc.conf]] para las configuracines y {{ic|/etc/rc.d/functions}} para las funciones que producen salida gráfica (colores, alineaciones, cambiar del demonio 'busy' a 'done', etc.) Este archivo no debe modificarse manualmente dado que se sobreescribe en la actualización de {{pkg|initscripts}}. Para añadir personalizaciones es aconsejable utilizar los hooks como se describe a continuación.
+
== Gestor de pantallas ==
 +
Si hay un [[Display Manager (Español)|gestor de pantallas (o gestor de inicio de sesión)]] instalado, este se ejecutará en la tty configurada, reemplazando el prompt de inicio de la getty. En su defecto, si no hay un gestor de pantallas, se mostrará el prompt de getty que pedirá en modo texto al usuario las credenciales, para poder realizar [[#Login|inicio de sesión]].
  
===/etc/rc.single===
+
== Login ==
La modalidad de usuario único (single-user mode) se iniciará como usuario root y sólo debe utilizarse si el sistema no puede arrancar normalmente o en caso de recuperación del sistema. Este script asegura que no se inicien otros demonios que no sean los esenciales: syslog-ng y udev. El modo single-user es útil para la recuperación del sistema impidiendo a usuarios remotos conectarse previniendo así que puedan hacer cualquier cosa que pudiera causar pérdida de datos o daños. En el modo de un solo usuario, los usuarios pueden volver a acceder a la sesión normal (multi-user) escribiendo "exit" en el prompt del sistema.
+
El programa ''login'' inicia una sesión para el usuario mediante el establecimiento de las variables de entorno y arranca la shell del usuario, basada en {{ic|/etc/passwd}}.
  
===/etc/rc.multi===
+
== Shell ==
{{ic|/etc/rc.multi}} se ejecuta por todos los runlevel multiusuario (esto es, 2, 3, 4, y 5), es decir, en cada arranque normal. Por lo general, los usuarios no se dan cuenta de la transición de {{ic|rc.sysinit}} a {{ic|rc.multi}} porque también utiliza {{ic|/etc/rc.d/functions}} para el manejo de video. Este script:
+
Una vez que la [[shell]] del usuario se inicia, normalmente ejecuta un archivo de configuración runtime, como por ejemplo [[.bashrc]], antes de presentar un prompt para el usuario. Si la cuenta está configurada para [[Start X at Login (Español)|iniciar X al iniciar sesión]], el archivo de configuración mencionado llamará a [[startx]] o [[xinit]].
  
# inicia [[sysctl]] (para modificar los parámetros del kernel en runtime) haciendo referencia a la configuración presente en {{ic|/etc/sysctl.conf}}. Arch tiene muy pocas opciones de éstos por defecto (principalmente la configuración de red).
+
== xinit ==
# se ocupa de iniciar los [[DAEMONS|demonios]], según lo dispuesto en la matriz {{ic|DAEMONS}} en {{ic|rc.conf}}.
+
[[xinit]] ejecuta el archivo de configuración del usuario [[.xinitrc]], que normalmente arrancará un [[Window Manager (Español)|gestor de ventanas]]. Cuando el usuario ha terminado y sale del gestor de ventanas, xinit, startx, la shell, y el programa login terminarán en ese orden, devolviéndonos a getty.
# ejecuta {{ic|/etc/rc.local}} para tratar las personalizaciones de usuario.
+
 
+
===/etc/rc.local===
+
 
+
{{ic|/etc/rc.local}} es el script del arranque local para las sesiones multiusuarios. Vacío por defecto, es un buen lugar donde insertar eventuales comandos de última hora que deben ser iniciados al final del proceso de arranque. La mayoría de las tareas comunes de configuración del sistema (carga de módulos, cambio de fuente de consola, encendido de periféricos), por lo general, tienen un lugar especial en el que se introducen. Para evitar confusiones, asegúrese de que los comandos introducidos en {{ic|rc.local}} no sea posible insertarlos en {{ic|/etc/profile.d}}, o en cualquier otro archivo de configuración.
+
 
+
Al editar este archivo, tenga en cuenta que se ejecutará '''después''' de la configuración básica (módulos/demonios), se iniciará como usuario '''root''', y '''tanto si el servidor gráfico (X) se inicia como si no'''. En este ejemplo, el archivo {{ic|rc.local}} se utiliza para quitar el silencio a algunos canales de audio de ALSA:
+
 
+
{{hc|/etc/rc.local
+
|output=<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>}}
+
 
+
==Hooks personalizados==
+
 
+
Los Hooks se pueden usar para incluir códigos personalizados en varias partes del script rc.*
+
{| class="wikitable"
+
|-
+
! scope="col" | Nombre del Hook
+
! scope="col" | Tiempo de ejecución del hook
+
|-
+
| sysinit_start
+
| Al comienzo de rc.sysinit
+
|-
+
| sysinit_udevlaunched
+
| Después que udev ha sido lanzado en rc.sysinit
+
|-
+
| sysinit_udevsettled
+
| Después que uevents se ha estabilizado en rc.sysinit
+
|-
+
| sysinit_prefsck
+
| Antes que fsck se ejecute en rc.sysinit
+
|-
+
| sysinit_postfsck
+
| Después que fsck se ejecute en rc.sysinit
+
|-
+
| sysinit_premount
+
| Antes que los sistemas de archivos locales sean montados, pero después de que la raíz está montada en modo lectura y escritura en rc.sysinit
+
|-
+
| sysinit_end
+
| Al final de rc.sysinit
+
|-
+
| multi_start
+
| Al comienzo de rc.multi
+
|-
+
| multi_end
+
| Al final de rc.multi
+
|-
+
| single_start
+
| Al comienzo de rc.single
+
|-
+
| single_prekillall
+
| Antes que todos los procesos estén terminando en rc.single
+
|-
+
| single_postkillall
+
| Después que todos los procesos estén terminando en rc.single
+
|-
+
| single_udevlaunched
+
| Después que udev ha sido lanzado en rc.single
+
|-
+
| single_udevsettled
+
| Después que uevents se ha estabilizado en rc.single
+
|-
+
| single_end
+
| Al final de rc.single
+
|-
+
| shutdown_start
+
| Al comienzo de rc.shutdown
+
|-
+
| shutdown_prekillall
+
| Antes que todos los procesos que están acabando en rc.shutdown
+
|-
+
| shutdown_postkillall
+
| Después que todos los procesos han acabado en rc.shutdown
+
|-
+
| shutdown_preumount
+
| Después de la última escritura del sistema de archivos (demonios han sido terminados), antes de desmontar el sistema de archivos
+
|-
+
| shutdown_postumount
+
| Después que los sistemas de archivos se han desmontado
+
|-
+
| shutdown_poweroff
+
| Justo antes de apagar en rc.shutdown
+
|}
+
 
+
Para definir una función hook, cree un archivo en /etc/rc.d/functions.d usando:
+
{{bc|1=function_name() {
+
  ...
+
}
+
add_hook hook_name function_name}}
+
 
+
Los archivos en /etc/rc.d/functions.d proceden de {{ic|/etc/rc.d/functions}}.
+
Se pueden registrar múltiples funciones hooks para el mismo hook, así como registrar la misma función hook por hook múltiples. No defina funciones denominadas add_hook o run_hook en estos archivos, ya que están definidas en {{ic|/etc/rc.d/functions}}.
+
 
+
====Ejemplo====
+
 
+
Agregando el siguiente archivo se permite la desactivación de la caché write-back en un disco duro <i>antes</i> que todos los daemons se inicien (útil para unidades que contienen archivos de MySQL InnoDB).
+
 
+
{{hc|/etc/rc.d/functions.d/hd_settings|output=<nowiki>hd_settings() {
+
    /sbin/hdparm -W0 /dev/sdb
+
}
+
add_hook sysinit_udevsettled hd_settings
+
add_hook single_udevsettled  hd_settings</nowiki>}}
+
 
+
En primer lugar, se define la función hd_settings, y luego la registra para los hooks '''single_udevsettled''' y '''sysinit_udevsettled'''. La función se llamará inmediatamente después que uvents se haya estabilizado en {{ic|/etc/rc.d/rc.sysinit}} o {{ic|/etc/rc.d/rc.single}}.
+
 
+
==init: Login==
+
 
+
Por defecto, después que los scripts de arranque de Arch se han completado, el programa {{ic|/sbin/agetty}} pide a los usuarios el nombre del login. Después que el nombre de usuario se recibe, {{ic|/sbin/agetty}} solicita {{ic|/bin/login}} el cual solicita la contraseña.
+
 
+
Finalmente, una vez efectuado el acceso, {{ic|/bin/login}} iniciará la shell predeterminada del usuario. El shell por defecto y las variables de entorno pueden ser definidos en el archivo {{ic|/etc/profile}}. Todas las variables dentro del directorio personal tendrán prioridad para sustituir las definidas en {{ic|/etc}}. Por ejemplo, si una misma variable está definida en {{ic|/etc/profile}} y en {{ic|~/.bashrc}}, la definida en {{ic|~/.bashrc}} prevalecerá.
+
 
+
Otras alternativas son [[Automatic login to virtual console_(Español)|mingetty]], que permite el inicio de sesión automático (agetty tiene la opción de inicio de sesión automático a partir de la versión 2.20 con {{Pkg|util-linux}}) o [[rungetty]], donde el primero permite auto-login y el segundo la ejecución automática de comandos y programas, por ejemplo {{ic|htop}}.
+
 
+
La mayoría de los usuarios que deseen iniciar un servidor gráfico [[Xorg_(Español)|X]] durante el proceso de arranque, deberían instalar un gestor de ventanas para efectuar el acceso (consulte [[Display Manager_(Español)|Display Manager]] para más detalles). Alternativamente, [[Start X at boot (Español)|este artículo]] describe métodos que no implican un gestor de ventanas.
+
  
 
== Véase también ==
 
== Véase también ==
 
+
* [http://archlinux.me/brain0/2010/02/13/early-userspace-in-arch-linux/ Early Userspace en Arch Linux]
* [[Improve Boot Performance|Mejorar el Rendimiento de Inicio]]
+
* [http://www.ibm.com/developerworks/linux/library/l-linuxboot/ El Proceso de Arranque de Linux desde Dentro]
* [[Runlevels|Niveles de ejecución]]
+
* [http://www.linuxjournal.com/article/4622 Boot con GRUB]
 +
* [[Wikipedia:es:Proceso de arranque en Linux|Wikipedia: Proceso de inicio de Linux]]
 +
* [[Wikipedia:es:initrd|Wikipedia: initrd]]
 
* [http://www.cyberciti.biz/faq/grub-boot-into-single-user-mode/ Del Arranque de Linux con GRUB en Modo Single User]
 
* [http://www.cyberciti.biz/faq/grub-boot-into-single-user-mode/ Del Arranque de Linux con GRUB en Modo Single User]
* [http://www.linuxjournal.com/article/4622 Arrancar con GRUB]
 
* [http://www.ibm.com/developerworks/linux/library/l-linuxboot/ Dentro del Proceso de Arranque de Linux]
 
* [http://linux.about.com/library/cmd/blcmdl5_sysctl.conf.htm Linux/Unix Comando: sysctl.conf]
 
* [http://bbs.archlinux.org/search.php?action=search&keywords=rc.local&search_in=topic&sort_dir=DESC&show_as=topics Buscar en el foro ejemplos de rc.local]
 
* [[Wikipedia:Linux startup process|Wikipedia: Proceso de inicio de Linux]]
 
* [[Wikipedia:initrd|Wikipedia: initrd]]
 

Revision as of 12:22, 18 January 2014

Para arrancar Arch Linux, un gestor de arranque capaz de iniciar Linux, como GRUB o Syslinux, debe estar instalado en el Master Boot Record o la GUID Partition Table. El gestor de arranque es el responsable de cargar el kernel y el ramdisk inicial antes de iniciarse el proceso de arranque. El proceso es bastante diferente según se trate de un sistema BIOS o de UEFI, cuyos detalles se describen en esta página o en las enlazadas.

Tipos de firmware

BIOS

Una BIOS o «Basic Input-Output System» es el primer programa (firmware) que se ejecuta cuando el sistema es puesto en marcha. En la mayoría de los casos, este se almacena en una memoria flash en la propia placa base e independiente del almacenamiento del sistema. La BIOS lanza los primeros 440 bytes (Master Boot Record) del primer disco según el orden de discos de la BIOS. Dado que se puede obtener muy poco de un programa que debe adaptarse solo a los primeros 440 bytes del disco, por lo general, un gestor de arranque común como GRUB, Syslinux o LILO sería cargado por la BIOS, el cual, seguidamente, se ocuparía de cargar el sistema operativo, ya sea cargando los sistemas en cadena, ya sea cargando directamente el kernel.

UEFI

UEFI tiene la capacidad de leer tanto la tabla de particiones, como de reconocer los sistemas de archivos. Por lo tanto, no está restringido por la limitación del código de los 440 bytes (código de arranque del MBR) como en los sistemas BIOS. No utiliza el código de arranque MBR en absoluto.

Los firmwares UEFI comunmente utilizados dan apoyo tanto a los sistemas de particionado MBR como GPT. Las EFI de Apple son conocidas por apoyar mapas de particionado Apple, además de MBR y GPT. La mayoría de los firmwares UEFI tienen soporte para acceder a sistemas de archivos FAT12 (disquetes), FAT16 y FAT32 en discos duros, y ISO9660 (y UDF) en CD/DVD. El firmware EFI en Apple puede acceder también a HFS/HFS+, aparte de los mencionados.

UEFI no ejecuta ningún código de arranque del MBR, tanto si existe como si no. En su lugar, utiliza una partición especial de la tabla de particiones, llamada EFI SYSTEM PARTITION (partición del sistema EFI), en la que se guardan los archivos necesarios para ser lanzado el firmware. Cada proveedor puede almacenar sus archivos en la carpeta <EFI SYSTEM PARTITION>/EFI/<FABRICANTE>/ y pueden usar el firmware o la shell (shell de UEFI) para iniciar el programa de arranque. Una partición del sistema EFI usa, por lo general, el formato FAT32 (principalmente) o FAT16.

Bajo UEFI, todos los programas que son cargados por un sistema operativo o por otros instrumentos (como aplicaciones de pruebas de memoria) o herramientas de recuperación fuera del sistema operativo, deben ser aplicaciones UEFI correspondiente a la arquitectura del firmware EFI. La mayor parte de los firmware UEFI en el mercado, incluyendo los recientes Mac de Apple, usan un firmware EFI x86_64. Solo algunos Mac antiguos (anteriores a 2008) que funcionan utilizando EFI IA32 (32-bit), algunos ultrabooks recientes de Intel Cloverfield y algunas placas bases de Intel Servers, son conocidos por operar con un firmware EFI 1.10 de Intel.

Un firmware EFI x86_64 no incluye el soporte para lanzar aplicaciones de 32-bit (a diferencia del EFI de Linux y de Windows x86_64 que incluyen dicho apoyo). En definitiva, la aplicación UEFI (esto es, el gestor de arranque) debe ser compilada para la arquitectura correcta.

Procesos de arranque

Bajo BIOS

  1. Encendido del sistema —Power On Self Test—, o proceso POST.
  2. Después del POST la BIOS inicializa el hardware necesario para el arranque del sistema (disco, controladores del teclado, etc.).
  3. La BIOS ejecuta el código de los primeros 440 bytes (la región del código de arranque del MBR) del primer disco de los que aparecen ordenados en la BIOS.
  4. El código de arranque del MBR entonces toma el control desde la BIOS y ejecuta el código de la siguiente etapa (en su caso) (normalmente, el código del gestor de arranque).
  5. El código (segunda etapa) lanzado (el gestor de arranque presente) entonces lee los archivos de configuración y apoyo.
  6. En base a los datos de los archivos de configuración, el gestor de arranque carga el kernel e initramfs en la memoria del sistema (RAM), e inicia el kernel.

Bajo UEFI

Véase la página principal: Proceso de arranque bajo UEFI .

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 (para la precepción humana) que varias tareas se están ejecutando simultáneamente.

initramfs

Después de estar cargado, el Kernel descomprime la imagen initramfs (sistema de archivos RAM inicial), que se convierte en el sistema de ficheros root inicial. El kernel seguidamente ejecuta /init como el primer proceso. El primer espacio de usuario («early userspace») comienza.

El propósito de initramfs es arrancar el sistema hasta el punto donde se puede acceder al sistema de archivos raíz (consulte FHS para más detalles). Esto significa que los módulos que se requieren para dispositivos como IDE, SCSI, SATA, USB/FW (si el arranque se realiza desde una unidad externa) deben ser cargados desde initramfs si no están compilados en el kernel; una vez que los módulos necesarios se cargan (ya sea de forma explícita 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 sólo debe contener los módulos necesarios para acceder al sistema de archivos raíz, no tiene por qué contener todos los módulos que sirven al completo funcionamiento de la máquina. La mayoría de los módulos se cargarán más tarde por udev, durante la fase init.

Fase init

En la etapa final del «early userspace», el verdadero sistema de archivos root es montado, y pasa a sustituir al sistema de archivos root inicial. /sbin/init se ejecuta, sustituyendo al proceso /init. Arch Linus utiliza systemd como proceso init.

Getty

init lanza las getty, una para cada terminal virtual (normalmente seis de ellas), las cuales inicializan cada tty pidiendo el nombre de usuario y contraseña. Una vez que se proporcionan el nombre de usuario y la contraseña, getty los compara con las que se encuentran en /etc/passwd, llamando a continuación al programa login, para que, una vez inicida la sesión de usuario, lance la shell de usuario de acuerdo con lo definido en /etc/passwd. Alternativamente, getty puede iniciar directamente un gestor de pantallas si existe uno presente en el sistema.

Gestor de pantallas

Si hay un gestor de pantallas (o gestor de inicio de sesión) instalado, este se ejecutará en la tty configurada, reemplazando el prompt de inicio de la getty. En su defecto, si no hay un gestor de pantallas, se mostrará el prompt de getty que pedirá en modo texto al usuario las credenciales, para poder realizar inicio de sesión.

Login

El programa login inicia una sesión para el usuario mediante el establecimiento de las variables de entorno y arranca la shell del usuario, basada en /etc/passwd.

Shell

Una vez que la shell del usuario se inicia, normalmente ejecuta un archivo de configuración runtime, como por ejemplo .bashrc, antes de presentar un prompt para el usuario. Si la cuenta está configurada para iniciar X al iniciar sesión, el archivo de configuración mencionado llamará a startx o xinit.

xinit

xinit ejecuta el archivo de configuración del usuario .xinitrc, que normalmente arrancará un gestor de ventanas. Cuando el usuario ha terminado y sale del gestor de ventanas, xinit, startx, la shell, y el programa login terminarán en ese orden, devolviéndonos a getty.

Véase también