1.2. Vista detallada del proceso de arranque

El inicio del proceso de arranque varía dependiendo de la plataforma de hardware usada. Sin embargo, una vez que se encuentra el kernel y se carga por el gestor de arranque, el proceso de arranque por defecto es idéntico a través de todas las arquitecturas. Este capítulo se basa principalmente en la arquitectura x86.

1.2.1. La BIOS

Cuando un ordenador x86 se carga, el procesador busca al final de la memoria del sistema por Basic Input/Output System o el programa BIOS y lo ejecuta. La BIOS controla no sólo el primer paso del proceso de arranque, sino que también proporciona una interfaz de bajo nivel para dispositivos periféricos. Por este motivo se escribe tan sólo en modo lectura, memoria permanente y está siempre disponible para el uso.

Otras plataformas usan programas diferentes para ejecutar tareas a bajo nivel equivalentes a aquellas de la BIOS en el sistema x86. Por ejemplo, los ordenadores basados en Itanium usan el Shell Interfaz de Firmware extendible (Extensible Firmware Interface, EFI).

Una vez que se haya cargado, la BIOS chequea los periféricos y localiza un dispositivo con el que arrancar el sistema. Habitualmente, en primer lugar comprueba cualquier disquete y unidades de CD-ROM presente por los medios de arranque, y a continuación si esto falla, echa un vistazo a las unidades de disco duro del sistema. En la mayoría de los casos, el orden de búsqueda de las unidades para arrancar es controlado por una configuración de la BIOS y busca por el dispositivo maestro IDE en el bus IDE primario. La BIOS carga en memoria cualquier programa que resida en el primer sector de este dispositivo, llamado Registro de arranque principal o Master Boot Record (MBR). La MBR sólo tiene 512 bytes de tamaño y contiene las instrucciones de código de máquina para el arranque del equipo, llamado un gestor de arranque, así como también la tabla de particiones. Una vez que la BIOS haya encontrado y cargado el gestor de arranque en memoria, le deja el control del proceso de arranque a éste.

1.2.2. El gestor de arranque

Esta sección revisa los gestores de arranque para la plataforma x86, GRUB. Dependiendo de la arquitectura del sistema, el proceso de arranque diferirá ligeramente. Consulte la Sección 1.2.2.1 para una breve descripción de los gestores de arranque que no están basados en x86. Para más información sobre la configuración y uso de GRUB, consulte el Capítulo 2.

Un gestor de arranque para la plataforma x86 se divide en al menos dos etapas. La primera es un código binario de máquina pequeña en el MBR. Su única función es la de localizar el gestor de arranque de la segunda etapa y cargar la primera parte de éste en memoria.

GRUB tiene la ventaja de ser capaz de leer particiones ext2 y ext3 [1] y cargar su archivo de configuración — /boot/grub/grub.conf — al momento de arranque. Consulte la Sección 2.7 para detalles sobre cómo modificar este archivo.

SugerenciaSugerencia
 

Si está actualizando el kernel mediante el uso del Agente de actualización de Red Hat, el archivo de configuración del gestor de arranque es actualizado automáticamente. Se puede encontrar más información sobre Red Hat Network en el siguiente URL: https://rhn.redhat.com.

Una vez que la segunda etapa del gestor de arranque está en memoria, presenta al usuario con una pantalla gráfica mostrando los diferentes sistemas operativos o kernels que para los que ha sido configurado para arrancar. En esta pantalla el usuario puede usar las flechas direccionales para escoger el sistema operativo o kernel con el que desea arrancar y presione la tecla [Intro]. Si no se presiona ninguna tecla, el gestor de arranque carga la selección predeterminada luego de un período de tiempo de espera (también configurable).

NotaNota
 

Si ha instalado el soporte para el kernel Symmetric Multi-Processor (SMP), verá más de una opción la primera vez que arranque el sistema. En esta situación, GRUB mostrará Red Hat Enterprise Linux (<kernel-version>-smp), el cual es el kernel SMP y Red Hat Enterprise Linux (<kernel-version>), la cual es para procesadores únicos.

Si surge cualquier problema con el kernel SMP, trate de seleccionar un kernel que no sea SMP antes de rearrancar.

Una vez que el gestor de arranque de la segunda etapa haya determinado qué kernel arrancar, localizará el binario del kernel correspondiente en el directorio /boot/. El kernel binario es llamado usando el siguiente formato — /boot/vmlinuz-<kernel-version> (donde <kernel-version> corresponde a la versión del kernel especificada en las configuraciones del gestor de arranque).

Para instrucciones sobre el uso del gestor de arranque para suministrar argumentos de línea de comandos al kernel, consulte el Capítulo 2. Para información sobre el cambio del nivel de ejecución en la línea de comandos del gestor de arranque, vea la Sección 2.8.

El gestor de arranque luego coloca una o más de las imágenes apropiadas de initramfs en la memoria. Luego, el kernel descomprime estas imágenes desde la memoria a /boot/, un sistema de archivos virtual basado en RAM, a través de cpio. El initrd es usado por el kernel para cargar controladores y módulos necesarios para arrancar el sistema. Esto es muy importante si posee unidades de disco duro SCSI o si está el sistema utiliza el sistema de archivos ext3.

Una vez que el kernel y la imagen initramfs se cargan en memoria, el gestor de arranque pasa el control del proceso de arranque al kernel.

Para una descripción más detallada sobre el gestor de arranque GRUB, consulte el Capítulo 2.

1.2.2.1. Gestores de arranque para otras arquitecturas

Una vez que se carga el kernel y pasa el proceso de arranque al comando init, los mismos acontecimientos suceden en cada arquitectura. La única diferencia entre el proceso de arranque de cada arquitectura está en la aplicación que se usa para encontrar y cargar el kernel.

Por ejemplo, la arquitectura Itanium utiliza el gestor de arranque ELILO, las arquitecturas eServer pSeries de IBM utilizan YABOOT y los sistemas IBM eServer zSeries e IBM S/390 usan el gestor de arranque z/IPL.

Consulte el Manual de instalación de Red Hat Enterprise Linux específico para estas plataformas para obtener información sobre la configuración de sus gestores de arranque.

1.2.3. El kernel

Cuando se carga el kernel, éste inicializa y configura la memoria del ordenador y los diferentes hardware conectado al sistema, incluyendo todos los procesadores, subsistemas de entrada/salida y dispositivos de almacenamiento. A continuación buscará la imagen comprimida de initramfs en una ubicación predeterminada en memoria, la descomprimirá directamente a /sysroot/ y cargará todos los controladores necesarios. A continuación inicializa los dispositivos virtuales relacionados con el sistema de ficheros, tal como LVM o software RAID antes de completar los procesos initramfs y de liberar toda la memoria que la imagen del disco ocupó anteriormente.

El kernel luego crea un dispositivo root, monta la partición root como sólo lectura y libera cualquier memoria no utilizada.

Llegados a este punto, el kernel está cargado en memoria y operativo. Sin embargo, como no hay aplicaciones de usuario que permitan la entrada significativa de datos al sistema, no se puede hacer mucho más.

Para configurar el entorno de usuario, el kernel inicia el programa /sbin/init.

1.2.4. Programa /sbin/init

El programa /sbin/init (también llamado init) coordina el resto del proceso de arranque y configura el ambiente del usuario.

Cuando el comando init arranca, se vuelve el padre o abuelo de todos los procesos que comienzan automáticamente en el sistema. Primero, ejecuta el script /etc/rc.d/rc.sysinit, que establece la ruta del entorno, activa el swap, verifica los sistemas de archivos y se encarga de todo lo que el sistema necesita tener hecho al momento de la inicialización. Por ejemplo, la mayoría de los sistemas usan un reloj, por lo tanto, el rc.sysinit lee el archivo de configuración para iniciar el hardware del reloj. Otro ejemplo es si hay procesos especiales en los puertos seriales que deben ser inicializados, rc.sysinit ejecutará el archivo /etc/rc.serial.

El comando init luego ejecuta el script /etc/inittab, el cual describe cómo se debería configurar el sistema en cada nivel de ejecución SysV init. Los niveles de ejecución son un estado, o modo, definido por los servicios listados en el SysV directorio /etc/rc.d/rc<x>.d/, donde <x> es el número de nivel de ejecución. Para más información sobre los niveles de ejecución SysV init, consulte la Sección 1.4.

A continuación, el comando init configura la biblioteca de funciones fuente, /etc/rc.d/init.d/functions, para el sistema, que establece el modo en cómo iniciar o matar un programa y cómo determinar el PID del programa.

El programa init inicia todos los procesos de fondo buscando en el directorio apropiado rc para el nivel de ejecución especificado por defecto en /etc/inittab. Los directorios rc están numerados para corresponder al nivel de ejecución que representan. Por ejemplo, /etc/rc.d/rc5.d/ es el directorio para el nivel de ejecución 5.

Cuando se arranca el nivel de ejecución 5, el programa init consulta el directorio /etc/rc.d/rc5.d/ para determinar qué procesos iniciar o parar.

A continuación un ejemplo de listado del directorio /etc/rc.d/rc5.d/:

K05innd -> ../init.d/innd
K05saslauthd -> ../init.d/saslauthd
K10dc_server -> ../init.d/dc_server
K10psacct -> ../init.d/psacct
K10radiusd -> ../init.d/radiusd
K12dc_client -> ../init.d/dc_client
K12FreeWnn -> ../init.d/FreeWnn
K12mailman -> ../init.d/mailman
K12mysqld -> ../init.d/mysqld
K15httpd -> ../init.d/httpd
K20netdump-server -> ../init.d/netdump-server
K20rstatd -> ../init.d/rstatd
K20rusersd -> ../init.d/rusersd
K20rwhod -> ../init.d/rwhod
K24irda -> ../init.d/irda
K25squid -> ../init.d/squid
K28amd -> ../init.d/amd
K30spamassassin -> ../init.d/spamassassin
K34dhcrelay -> ../init.d/dhcrelay
K34yppasswdd -> ../init.d/yppasswdd
K35dhcpd -> ../init.d/dhcpd
K35smb -> ../init.d/smb
K35vncserver -> ../init.d/vncserver
K36lisa -> ../init.d/lisa
K45arpwatch -> ../init.d/arpwatch
K45named -> ../init.d/named
K46radvd -> ../init.d/radvd
K50netdump -> ../init.d/netdump
K50snmpd -> ../init.d/snmpd
K50snmptrapd -> ../init.d/snmptrapd
K50tux -> ../init.d/tux
K50vsftpd -> ../init.d/vsftpd
K54dovecot -> ../init.d/dovecot
K61ldap -> ../init.d/ldap
K65kadmin -> ../init.d/kadmin
K65kprop -> ../init.d/kprop
K65krb524 -> ../init.d/krb524
K65krb5kdc -> ../init.d/krb5kdc
K70aep1000 -> ../init.d/aep1000
K70bcm5820 -> ../init.d/bcm5820
K74ypserv -> ../init.d/ypserv
K74ypxfrd -> ../init.d/ypxfrd
K85mdmpd -> ../init.d/mdmpd
K89netplugd -> ../init.d/netplugd
K99microcode_ctl -> ../init.d/microcode_ctl
S04readahead_early -> ../init.d/readahead_early
S05kudzu -> ../init.d/kudzu
S06cpuspeed -> ../init.d/cpuspeed
S08ip6tables -> ../init.d/ip6tables
S08iptables -> ../init.d/iptables
S09isdn -> ../init.d/isdn
S10network -> ../init.d/network
S12syslog -> ../init.d/syslog
S13irqbalance -> ../init.d/irqbalance
S13portmap -> ../init.d/portmap
S15mdmonitor -> ../init.d/mdmonitor
S15zebra -> ../init.d/zebra
S16bgpd -> ../init.d/bgpd
S16ospf6d -> ../init.d/ospf6d
S16ospfd -> ../init.d/ospfd
S16ripd -> ../init.d/ripd
S16ripngd -> ../init.d/ripngd
S20random -> ../init.d/random
S24pcmcia -> ../init.d/pcmcia
S25netfs -> ../init.d/netfs
S26apmd -> ../init.d/apmd
S27ypbind -> ../init.d/ypbind
S28autofs -> ../init.d/autofs
S40smartd -> ../init.d/smartd
S44acpid -> ../init.d/acpid
S54hpoj -> ../init.d/hpoj
S55cups -> ../init.d/cups
S55sshd -> ../init.d/sshd
S56rawdevices -> ../init.d/rawdevices
S56xinetd -> ../init.d/xinetd
S58ntpd -> ../init.d/ntpd
S75postgresql -> ../init.d/postgresql
S80sendmail -> ../init.d/sendmail
S85gpm -> ../init.d/gpm
S87iiim -> ../init.d/iiim
S90canna -> ../init.d/canna
S90crond -> ../init.d/crond
S90xfs -> ../init.d/xfs
S95atd -> ../init.d/atd
S96readahead -> ../init.d/readahead
S97messagebus -> ../init.d/messagebus
S97rhnsd -> ../init.d/rhnsd
S99local -> ../rc.local

Como puede ver, ninguno de los scripts que inician y cierran los servicios están localizados en el directorio /etc/rc.d/rc5.d/. Casi todos los ficheros en /etc/rc.d/rc5.d/ son enlaces simbólicos apuntando a los scripts localizados en el directorio /etc/rc.d/init.d/. Los enlaces simbólicos se usan en cada uno de los directorios rc de manera que los niveles de ejecución puedan ser reconfigurados al crear, modificar y eliminar los enlaces simbólicos sin que afecte a los scripts actuales a los que se refiere.

El nombre de cada enlace simbólico comienza con K o S. Los enlaces K son procesos eliminados en ese nivel de ejecución, mientras que aquellos que inician por S son procesos a iniciar.

El comando init en primer lugar detiene todos los enlaces simbólicos de K en el directorio mediante la ejecución del comando /etc/rc.d/init.d/<command> stop, en el que <command> es el proceso a matar. A continuación inicia todos los enlaces simbólicos S al ejecutar /etc/rc.d/init.d/<command>. start.

SugerenciaSugerencia
 

Una vez que el sistema haya acabado el arranque podrá registrarse como root y ejecutar los mismos scripts para iniciar y detener los servicios. Por ejemplo, el comando /etc/rc.d/init.d/httpd stop paralizará el Servidor Apache HTTP.

Cada uno de los enlaces simbólicos se numera para dictaminar el orden de inicio. Usted puede cambiar el orden en el que los servicios inician o paran al cambiar este número. Mientras más bajo es el número, más rápido se arrancará. Los enlaces simbólicos con el mismo número se inician de modo alfabético.

NotaNota
 

Una de las últimas cosas que el programa init ejecuta es el archivo /etc/rc.d/rc.local. Este archivo es útil para la personalización del sistema. Consulte la Sección 1.3 para más información sobre el uso del archivo rc.local.

Después que el comando init ha progresado a través del directorio adecuado rc para el nivel de ejecución, el script /etc/inittab bifurca un proceso /sbin/mingetty para cada consola virtual (prompt de inicio de sesión) del nivel de ejecución. Los niveles de ejecución del 2 al 5 tienen seis consolas virtuales, mientras que el nivel de ejecución 1 (modo usuario único) tiene tan sólo uno y lo niveles de ejecución del 0 al 6 no tienen ninguno. El proceso /sbin/mingetty abre las rutas de la comunicación para los dispositivostty[2], establece sus modos, imprime el indicador de inicio de sesión, toma el nombre y contraseña del usuario, e inicia el proceso de inicio de sesión.

En el nivel de ejecución 5, /etc/inittab ejecuta un script llamado /etc/X11/prefdm. El script prefdm ejecuta su gestor de pantalla de X preferido[3]gdm, kdm, o xdm, dependiendo de los contenidos del archivo /etc/sysconfig/desktop.

Una vez que haya terminado, el sistema operará en el nivel de ejecución 5 y mostrará la pantalla de inicio de sesión.

Notas

[1]

GRUB lee sistemas de archivos ext3 como ext2, sin importar el archivo de diario o journal. Consulte el capítulo titulado El sistema de archivos ext3 en el Manual de administración del sistema de Red Hat Enterprise Linux para más información sobre el sistema de archivos ext3.

[2]

Consulte la Sección 5.3.11 para más información sobre dispositivos tty.

[3]

Consulte Sección 7.5.2 para más información sobre los gestores de pantallas.