Arch boot process (Español)

From ArchWiki
Revision as of 17:51, 29 March 2011 by Sironitomas (Talk | contribs)

Jump to: navigation, search

This template has only maintenance purposes. For linking to local translations please use interlanguage links, see Help:i18n#Interlanguage links.


Local languages: Català – Dansk – English – Español – Esperanto – Hrvatski – Indonesia – Italiano – Lietuviškai – Magyar – Nederlands – Norsk Bokmål – Polski – Português – Slovenský – Česky – Ελληνικά – Български – Русский – Српски – Українська – עברית – العربية – ไทย – 日本語 – 正體中文 – 简体中文 – 한국어


External languages (all articles in these languages should be moved to the external wiki): Deutsch – Français – Română – Suomi – Svenska – Tiếng Việt – Türkçe – فارسی

Template:Article summary start Template:Article summary text Template:Article summary heading Template:Article summary text Template:Article summary heading Template:Article summary wiki Template:Article summary wiki Template: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.

Antes de init

Luego de que el sistema es encendido y que 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 dual-boot setup. Una vez que Arch es seleccionado, la imagen de kernel en el directorio Template:Filename (actualmente Template:Filename) es descomprimida y cargada en memoria.


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.

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.

The kernel then looks for the program Template:Codeline which resides at Template:Filename. Template:Codeline relies on Template:Codeline, the GNU C library. Libraries are collections of frequently used program routines and are readily identifiable through their filename extension of Template:Filename. They are essential for basic system functionality. This part of the boot process is called early userspace.

init: The Arch boot scripts

The main Arch startup process is initiated by the program Template:Codeline, which spawns all other processes. The purpose of Template:Codeline is to bring the system into a usable state, using the boot scripts to do so. As previously mentioned, Arch uses BSD-style boot scripts. Template:Codeline reads the file Template:Filename; the default Template:Filename begins with the following:

Template:File

The first uncommented line defines the default system runlevel (3). When the kernel calls init:

Template:Filename

Template:Filename is a huge startup script that basically takes care of all hardware configuration plus a number of general initialization tasks. It can be identified by its first task, printing the lines:

Arch Linux
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:

  • Sources the Template:Filename script
  • Sources the Template:Filename 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 Template:Filename file
  • Starts udev and checks for udev events
  • Starts the loopback interface
  • Loads modules from the Template:Codeline array defined in rc.conf
  • Configures RAID and encrypted filesystem mappings
  • Runs a forced check of partitions (fsck) if the /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 Template:Filename
  • Removes various leftover/temporary files, such as Template:Filename
  • Configures the locale, console and keyboard mappings
  • Sets the console font
  • Writes output from dmesg to Template:Filename

Template:Filename is a script and not a place for settings. It sources (i.e. reads and inherits variables and functions) rc.conf for settings and Template:Filename 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.

Template:Filename

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.

Template:Filename

Template:Filename 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 Template:Filename to Template:Filename as Template:Filename also uses the functions file to produce output. This script has three tasks:

Template:Filename

Template:Filename 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 Template:Filename is not already residing in Template:Filename, 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:

Template:File

Another common usage for Template:Filename 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.

Hook Name 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:

function_name() {
   ...
}
add_hook hook_name function_name

Files in /etc/rc.d/functions.d are sourced from Template:Filename. 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 Template:Filename.

Example

Adding the following file will disable the write-back cache on a hard drive before any daemons are started (useful for drives containing MySQL InnoDB files). Template:File 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 Template:Filename or Template:Filename.

init: Login

By default, after the Arch boot scripts are completed, the Template:Codeline program prompts users for a login name. After a login name is received, Template:Codeline calls Template:Codeline to prompt for the login password.

Finally, with a successful login, the Template:Codeline program starts the user's default shell. The default shell and environment variables may be globally defined within Template:Filename. All variables within a user's home directory shall take precedence over those globally defined under Template:Filename. For instance, if two conflicting variables are specified within Template:Filename and Template:Filename, the one dictated by Template:Filename shall prevail.

Other options include 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

External resources