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

From ArchWiki
Jump to: navigation, search
(update templates, see Help:Style)
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}}
+
[[cs:Arch Boot Process]]
 
+
[[en:Arch Boot Process]]
 +
[[fr:Processus de boot]]
 +
[[it:Arch Boot Process]]
 +
[[ru:Arch Boot Process]]
 +
[[zh-CN:Arch Boot Process]]
 +
{{Temporary i18n}}
 
{{Article summary start}}
 
{{Article summary start}}
 
{{Article summary text|?}}
 
{{Article summary text|?}}

Revision as of 12:30, 13 June 2012

Template:Temporary i18n 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, 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 Adding Runlevels para poder agregar configuraciones parecidas a SysV en Arch. Ver Wikipedia:init para mas información en las diferencias entre los estilos SysV y BSD.

Antes de init

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

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).

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.

El kernel luego busca el programa init que reside en /sbin/init. init se basa en glibc, la biblioteca C GNU. Las bibliotecas son colecciones de rutinas de programa frecuentemente usadas y son ifentificables mediante la extension *.so. Estas son escenciales para la funcionalidad basica del sistema. Esta parte del proceso de arranque es llamada early userspace.

init: Los scripts de arranque de Arch

El principal proceso de arranque de Arch es iniciado por el programa init, que llama a todos los demás procesos. El propósito de 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. init lee el archivo /etc/inittab. Por defecto, /etc/inittab empieza con lo siguiente:

/etc/inittab
...
# Boot to console
id:3:initdefault:
# Boot to X11
#id:5:initdefault:

rc::sysinit:/etc/rc.sysinit
rs:S1:wait:/etc/rc.single
rm:2345:wait:/etc/rc.multi
rh:06:wait:/etc/rc.shutdown
su:S:wait:/sbin/sulogin
...

La primer linea no comentada define el nivel de ejecución del sistema por defecto (3). Cuando el kernel llama init:

  • Primero, el principal script de inicializacion es ejecutado, /etc/rc.sysinit (un script Bash).
  • Si se inicia en modo de usuario simple (nivel de ejecución 1 o S), el script /etc/rc.single sera ejecutado.
  • Si se inicia en cualquier otro nivel (2-5), se ejecuta en vez /etc/rc.multi.
  • El ultimo script ejecutado sera /etc/rc.local (mediante /etc/rc.multi), que esta vació por defecto.

/etc/rc.sysinit

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
http://www.archlinux.org
Copyright 2002-2007 Judd Vinet
Copyright 2007-2010 Aaron Griffin
Distributed under the GNU General Public License (GPL)

Una vision aproximada de sus tareas:

  • Toma el script /etc/rc.conf
  • Toma el script /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 /proc/sys/kernel/hotplug
  • Inicia udev y chequea eventos de udev
  • Inicia la interfaz loopback
  • Carga modulos del arreglo MODULES definido en rc.conf
  • Configura mapeo de sistemas de archivos RAID y encriptados
  • Ejecuta un chequeo forzado de particiones (fsck) en el archivo /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 rc.conf
  • Elimina varios archivos temporales, como /tmp/*
  • Configura el locale, la consola y el mapeo del teclado
  • Setea la fuente de consola
  • Escribe salida de dmseg a /var/log/dmesg.log

/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 /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.

/etc/rc.single

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.

/etc/rc.multi

/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 rc.sysinit to rc.multi as 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 /etc/sysctl.conf. Arch has very few of these by default; mainly networking settings.
  • Secondly, and most importantly, it starts daemons, as per the DAEMONS array in rc.conf.
  • Finally, it will run /etc/rc.local.

/etc/rc.local

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 rc.local is not already residing in /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:

/etc/rc.local
#!/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

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

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 /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 /etc/rc.d/functions.

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).

/etc/rc.d/functions.d/hd_settings
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 /etc/rc.d/rc.sysinit or /etc/rc.d/rc.single.

init: Login

By default, after the Arch boot scripts are completed, the /sbin/agetty program prompts users for a login name. After a login name is received, /sbin/agetty calls /bin/login to prompt for the login password.

Finally, with a successful login, the /bin/login program starts the user's default shell. The default shell and environment variables may be globally defined within /etc/profile. All variables within a user's home directory shall take precedence over those globally defined under /etc. For instance, if two conflicting variables are specified within /etc/profile and ~/.bashrc, the one dictated by ~/.bashrc 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