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

From ArchWiki
Jump to: navigation, search
m (Tipos de firmware)
(29 intermediate revisions by 6 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)]]
{{es|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 Boot Process]]
 +
[[ru:Arch Boot Process]]
 +
[[zh-CN:Arch Boot Process]]
 +
{{Related articles start (Español)}}
 +
{{Related|Boot Loaders}}
 +
{{Related|Master Boot Record (Español)}}
 +
{{Related|GUID Partition Table (Español)}}
 +
{{Related|Unified Extensible Firmware Interface (Español)}}
 +
{{Related|mkinitcpio (Español)}}
 +
{{Related|systemd (Español)}}
 +
{{Related|fstab (Español)}}
 +
{{Related|Autostarting (Español)}}
 +
{{Related articles end}}
  
{{Article summary start}}
+
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.
{{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, 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, en lugar del 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 [[es|Adding Runlevels]] para poder agregar configuraciones parecidas a SysV en Arch. Ver [[es|Wikipedia:init]] para mas información en las diferencias entre los estilos SysV y BSD.
+
==Tipos de firmware==
 +
=== BIOS ===
  
== Antes de init ==
+
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.
Luego de que el sistema es encendido y que [[Wikipedia:Power-on self-test|POST]] es completado, la BIOS localizara el medio preestablecido 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]] que luego se carga desde el MBR. El gestor de arranque presentara al usuario un rango de opciones para arrancar, por ejemplo Arch Linux o Windows en [[Windows and Arch Dual Boot|dual-boot setup]]. Una vez que Arch es seleccionado, la imagen del kernel en el directorio {{Filename|/boot}} (actualmente {{Filename|kernel26.img}}) es descomprimida y cargada en memoria.
+
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.
  
 +
=== UEFI===
  
El kernel es el núcleo de un sistema operativo. Este funciona en bajo nivel (''kernelspace'') interactuando entre el hardware y los programas ejecutandose. Para hacer un uso eficiente del CPU, el kernel usa un planificador para decidir cuales tareas tienen mayor prioridad a cada momento, creando la ilusión (para la percepción humana) de que varias tareas están siendo ejecutadas simultáneamente (multitasking).
+
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.
  
Luego de que el kernel es cargado, este lee el [[initramfs]] (sistema de archivos RAM inicial). El propósito de initramfs es de llevar al sistema a un 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 requiera usar después. La mayoría de los módulos serán cargaos mas tarde por udev, durante el proceso 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.
  
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''.
+
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: 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 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:
+
  
{{File
+
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.
|name=/etc/inittab
+
|content=<nowiki>
+
...
+
# Boot to console
+
id:3:initdefault:
+
# Boot to X11
+
#id:5:initdefault:
+
  
rc::sysinit:/etc/rc.sysinit
+
== Procesos de arranque ==
rs:S1:wait:/etc/rc.single
+
===Bajo BIOS===
rm:2345:wait:/etc/rc.multi
+
rh:06:wait:/etc/rc.shutdown
+
su:S:wait:/sbin/sulogin
+
...
+
</nowiki>}}
+
  
La primer linea no comentada define el nivel de ejecución del sistema por defecto (3). Cuando el kernel llama init:
+
# Encendido del sistema &mdash;Power On Self Test&mdash;, o proceso [[wikipedia:es:POST|POST]].
 +
# Después del POST la BIOS inicializa el hardware necesario para el arranque del sistema (disco, controladores del teclado, etc.).
 +
# 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.
 +
# 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).
 +
# 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.
  
* Primero, el principal script de inicializacion es ejecutado, {{Filename|/etc/rc.sysinit}} (un script [[Bash]]).
+
=== Bajo UEFI ===
* 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.
+
  
=== {{Filename|/etc/rc.sysinit}} ===
+
Véase la página principal: [[Unified_Extensible_Firmware_Interface_(Español)#Proceso_de_arranque_bajo_UEFI|Proceso de arranque bajo UEFI ]].
{{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
+
== Kernel ==
http://www.archlinux.org
+
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.
Copyright 2002-2007 Judd Vinet
+
Copyright 2007-2010 Aaron Griffin
+
Distributed under the GNU General Public License (GPL)
+
  
Una vision aproximada de sus tareas:
+
== initramfs ==
* Toma el script {{Filename|/etc/rc.conf}}
+
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.
* Toma el script {{Filename|/etc/rc.d/functions}}
+
* Muestra un mensaje de bienvenida
+
* Monta varios sistemas de archivos virtuales
+
* Crea falsos archivos de dispositivo
+
* Inicia [[minilogd]]
+
* Muestra salida de [[dmesg]]
+
* Configura el reloj de hardware
+
* Borra el archivo {{Filename|/proc/sys/kernel/hotplug}}
+
* Inicia [[udev]] y chequea eventos de udev
+
* Inicia la interfaz [[loopback]]
+
* Carga modulos del arreglo {{Codeline|MODULES}} definido en [[rc.conf]]
+
* Configura mapeo de sistemas de archivos RAID y encriptados
+
* Ejecuta un chequeo forzado de particiones ([[fsck]]) en el archivo [[fstab|/etc/fstab]] contiene instrucciones para hacerlo
+
* Monta particiones locales y swap (unidades de red no son montadas hasta que se inicia la red)
+
* Activa areas [[swap]]
+
* Setea el nombre del equipo, localizacion y reloh del sistema como se define en {{Filename|rc.conf}}
+
* Elimina varios archivos temporales, como {{Filename|/tmp/*}}
+
* Configura el [[locale]], la consola y el mapeo del teclado
+
* Setea la fuente de consola
+
* Escribe salida de dmseg a {{Filename|/var/log/dmesg.log}}
+
  
{{Filename|/etc/rc.sysinit}} es un script y no un lugar para configuraciones. Sus orígenes (por ejemplo lecturas de variables y funciones) [[rc.conf]] para configuraciones y {{Filename|/etc/rc.d/functions}} para funciones que producen la salida gráfica (colores, alineación, , etc.) No hay necesidad de editar este archivo, aunque algunos puede ser que lo deseen para mejorar tiempos de arranque.
+
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.
  
=== {{Filename|/etc/rc.single}} ===
+
== 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. {{ic|/sbin/init}} se ejecuta, sustituyendo al proceso {{ic|/init}}.  Arch Linus utiliza [[systemd (Español)|systemd]] como proceso init.
  
El modo de único usuario arrancara el sistema directamente en la cuenta de usuario root y debe ser usado si uno no puede arrancar el sistema normalmente. Este script asegura que no hay demonios ejecutándose  excepto por los mínimos requeridos (syslog-ng y udev). El modo de único usuario es útil para hacer una recuperación del sistema donde se previene que usuarios remotos que hagan cualquier cosa que pueda causar perdida de datos o dano. En este modo, los usuarios pueden continuar con el arranque estándar (multi-usuario) escribiendo exit en la consola.
+
== Getty ==
 +
[[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.
  
 +
== 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]].
  
=== {{Filename|/etc/rc.multi}} ===
+
== Login ==
{{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:
+
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}}.
  
* 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.
+
== Shell ==
* Secondly, and most importantly, it starts [[daemons]], as per the {{Codeline|DAEMONS}} array in {{Filename|rc.conf}}.
+
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]].
* Finally, it will run {{Filename|/etc/rc.local}}.  
+
  
=== {{Filename|/etc/rc.local}} ===
+
== xinit ==
{{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
+
[[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.
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:
+
== Véase también ==
 
+
* [http://archlinux.me/brain0/2010/02/13/early-userspace-in-arch-linux/ Early Userspace en Arch Linux]
{{File
+
* [http://www.ibm.com/developerworks/linux/library/l-linuxboot/ El Proceso de Arranque de Linux desde Dentro]
|name=/etc/rc.local
+
* [http://www.linuxjournal.com/article/4622 Boot con GRUB]
|content=<nowiki>
+
* [[Wikipedia:es:Proceso de arranque en Linux|Wikipedia: Proceso de inicio de Linux]]
#!/bin/bash
+
* [[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]
# /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 ==
+
Hooks can be used to include custom code in various places in the rc.* scripts.
+
{| class="wikitable"
+
|-
+
! scope="col" | Hook Name
+
! scope="col" | When hook is executed
+
|-
+
| 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
+
| At the beginning of rc.multi
+
|-
+
| multi_end
+
| At the end of rc.multi
+
|-
+
| single_start
+
| At the beginning of rc.single
+
|-
+
| single_prekillall
+
| Before all processes are being killed in rc.single
+
|-
+
| single_postkillall
+
| After all processes have been killed in rc.single
+
|-
+
| single_udevlaunched
+
| After udev has been launched in rc.single
+
|-
+
| single_udevsettled
+
| After uevents have settled in rc.single
+
|-
+
| single_end
+
| At the end of rc.single
+
|-
+
| shutdown_start
+
| At the beginning of rc.shutdown
+
|-
+
| shutdown_prekillall
+
| Before all processes are being killed in rc.shutdown
+
|-
+
| 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:
+
<pre>
+
function_name() {
+
  ...
+
}
+
add_hook hook_name function_name
+
</pre>
+
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}}.
+
 
+
==== Example ====
+
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() {
+
    /sbin/hdparm -W0 /dev/sdb
+
}
+
add_hook sysinit_udevsettled hd_settings
+
add_hook single_udevsettled  hd_settings
+
}}
+
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}}.
+
 
+
== init: Login ==
+
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.
+
 
+
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.
+
 
+
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.
+
 
+
== See also ==
+
 
+
* [[Startup files]]
+
 
+
== External resources ==
+
* [http://www.cyberciti.biz/faq/grub-boot-into-single-user-mode/ Boot Linux Grub Into Single User Mode]
+
* [http://www.linuxjournal.com/article/4622 Boot with GRUB]
+
* [http://www.ibm.com/developerworks/linux/library/l-linuxboot/ Inside the Linux boot process]
+
* [http://linux.about.com/library/cmd/blcmdl5_sysctl.conf.htm Linux / Unix Command: sysctl.conf]
+
* [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]
+
* [[Wikipedia:Linux startup process]]
+
* [[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