Capítulo 3. La inicialización del sistema

Tabla de contenidos

3.1. Un resumen del proceso de arranque
3.1.1. Fase 1: UEFI
3.1.2. Fase 2: el cargador de arranque
3.1.3. Fase 3: el sistema mini-Debian
3.1.4. Fase 4: el sistema normal Debian
3.2. Systemd
3.2.1. Arranque de systemd
3.2.2. Inicio de sesión en Systemd
3.3. Los mensajes del núcleo
3.4. El sistema de mensajes
3.5. Gestión del sistema
3.6. Otros monitores del sistema
3.7. Configuración del sistema
3.7.1. El nombre del equipo (hostname)
3.7.2. El sistema de archivos
3.7.3. Inicialización del interfaz de red
3.7.4. Inicialización del sistema en la nube
3.7.5. Ejemplo de personalización para ajustar el servicio sshd
3.8. El sistema udev
3.9. La inicialización del módulo del núcleo

Es inteligente por su parte como administrador de sistemas conocer profundamente como el sistema Debian comienza y se configura. Aunque los detalles concretos están en el código fuente de los paquetes instalados y su documentación, es un poco abrumador para la mayoría de nosotros.

Lo siguiente es una descripción general de los puntos principales de la inicialización de un sistema Debian. Dado que el sistema Debian evoluciona constantemente, debe consultar la documentación más reciente.

Un sistema informático pasa por diferentes fases en el proceso de arranque desde el encendido hasta que le ofrece al usuario la funcionalidad completa del sistema operativo (SO).

Por simplicidad, limité la discusión a la de una típica plataforma PC con la instalación por defecto.

El proceso normal de arranque es como un cohete de cuatro fases. Cada fase del cohete cede el control del sistema a la siguiente.

Desde luego, esto puede ser configurado de otra manera. Por ejemplo, si compila su propio núcleo, puede saltar el paso del sistema mini-Debian. Así que, por favor, no asuma cuál es el caso de su sistema hasta que no lo compruebe por si mismo.

La Interfaz del firmware extensible unificada (UEFI) define un administrador de arranque como parte de la especificación UEFI. Cuando se enciende un ordenador, el administrador de inicio es la primera etapa del proceso de inicio que verifica la configuración de inicio y, según su configuración, luego ejecuta el cargador de inicio del sistema operativo o el kernel del sistema operativo especificado (generalmente el cargador de inicio). La configuración de arranque está definida por variables almacenadas en la NVRAM, incluidas las variables que indican las rutas del sistema de archivos a los cargadores o kernels del sistema operativo.

Una partición de sistema EFI (ESP) es una partición de dispositivo de almacenamiento de datos que se usa en ordenadores que se adhieren a la especificación UEFI. Accedido por el firmware UEFI cuando se enciende un ordeandor, almacena aplicaciones UEFI y los archivos que estas aplicaciones necesitan para ejecutarse, incluidos los cargadores de arranque del sistema operativo. (En el sistema de PC heredado, se puede usar la BIOS almacenada en el MBR)

El cargador de arranque es la segunda fase del proceso de arranque que comienza con la UEFI. Carga la imagen del núcleo del sistema y la imagen de initrd en memoria y pasa el control a estos. La imagen de initrd es la imagen del sistema de archivos raíz y su compatibilidad depende del cargador usado.

El sistema Debian normalmente usa el kernel Linux como el kernel del sistema predeterminado. La imagen initrd para el kernel Linux 5.x actual es técnicamente la imagen initramfs (sistema de archivos RAM inicial).

Hay disponibles muchos cargadores de arranque y opciones de configuración.


[Aviso] Aviso

No pruebe cargadores de inicio sin tener un medio de inicio de rescate (USB, CD o disquete) creado de las imágenes del paquete grub-rescue-pc. Ello le permite iniciar su sistema incluso sin un cargador de inicio operativo en el disco duro.

Para el sistema UEFI, GRUB2 primero lee la partición ESP y usa el UUID especificado para search.fs_uuid en "/boot/efi/EFI/debian/grub.cfg" para determinar el partición del archivo de configuración del menú GRUB2 "/boot/grub/grub.cfg".

Las secciones clave del archivo de configuración del menú de GRUB2 se ven así:

menuentry 'Debian GNU/Linux' ... {
        load_video
        insmod gzio
        insmod part_gpt
        insmod ext2
        search --no-floppy --fs-uuid --set=root fe3e1db5-6454-46d6-a14c-071208ebe4b1
        echo    'Loading Linux 5.10.0-6-amd64 ...'
        linux   /boot/vmlinuz-5.10.0-6-amd64 root=UUID=fe3e1db5-6454-46d6-a14c-071208ebe4b1 ro quiet
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initrd.img-5.10.0-6-amd64
}

Para esta parte de /boot/grub/grub.cfg, esta entrada de menú significa lo siguiente.


[Sugerencia] Sugerencia

Puedes habilitar la visualización de los mensajes del registro de arranque del kernel eliminando quiet en "/boot/grub/grub.cfg". Para el cambio persistente, edita la línea "GRUB_CMDLINE_LINUX_DEFAULT="quiet"" en "/etc/default/grub".

[Sugerencia] Sugerencia

Puedes personalizar la imagen de presentación de GRUB configurando la variable GRUB_BACKGROUND en "/etc/default/grub" apuntando al archivo de imagen o colocando el archivo de imagen en "/ boot/grub/".

Consulte «info grub» y grub-install(8).

El sistema mini-Debian es la fase 3 del proceso de arranque que comienza con el cargador de arranque. Este ejecuta el núcleo del sistema con el sistema de archivos raíz en memoria. Esta es una fase preparatoria opcional del proceso de arranque.

[Nota] Nota

En este documento el término «el sistema mini-Debian« es como el autor describe la tercera fase del proceso de arranque. El sistema se conoce como initrd o sistema initramfs. El instalador de Debian usa un sistema parecido en memoria.

El primer programa que se ejecuta en el sistema de archivo raíz en memoria es /init». Es un programa que inicia el núcleo en el espacio de usuario y entrega el control para la próxima fase. Este sistema mini-Debian ofrece flexibilidad al módulo al proceso de arranque, como agregar módulos del núcleo antes de que el proceso principal de arranque o el montaje de un sistema de archivos raíz cifrado.

  • El programa /inites una secuencia de códigos si initramfs ha sido creado por initramfs-tools.

    • Puede interrumpir esta parte del proceso de arranque para obtener un intérprete de órdenes de supuerusuario dándole al arranque del núcleo el parámetro «break=init» etc. Consulte el archivo de órdenes /init» para conocer más formas de interacción. Este entorno del intérprete de órdenes es suficientemente complejo para realizar una reconocimiento avanzado del hardware de su equipo.

    • Las órdenes disponibles en este sistema mini-Debian son básicas y las funciones principales las aporta la herramienta GNU llamada busybox(1).

  • El programa /init es un programa binario systemd si initramfs fue creado por dracut.

    • Los comandos disponibles en este sistema mini-Debian son básicamente el ambiente systemd(1).

[Atención] Atención

Necesita utilizar el parámetro «-n» en la orden mount cuando interaccione con el sistema de solo lectura del sistema de archivos raíz.

El sistema normal Debian es la cuarta fase del proceso de arranque el cual comienza con el sistema mini-Debian. El núcleo del sistema para el sistema mini-Debian continua ejecutándose en este entorno. El sistema de archivos raíz cambio del que existe en memoria a uno real sobre el sistema de archivos en disco duro.

El programa init se ejecuta en primer lugar con el PID=1 preparando el proceso de arranque principal para el comienzo de muchos programas. La ruta de archivo por defecto para el programa init es «/usr/sbin/init» pero se puede modificar por un parámetro de arranque del núcleo como «init=/path/to/init_program».

"/usr/sbin/init" tiene un enlace simbólico a "/lib/systemd/systemd" después de Debian 8 Jessie (lanzado en 2015).

[Sugerencia] Sugerencia

Puede comprobar cual es el sistema init real que usa su equipo mediante la orden «ps --pid 1 -f».


[Sugerencia] Sugerencia

Ver la wiki de Debian : AcelerandoElProcesodeArranque para los consejos actualizados para mejorar la velocidad del proceso de arranque.

Cuando se inicia el sistema Debian, /usr/sbin/init enlazado a /usr/lib/systemd se inicia como el proceso init del sistema (PID=1) propiedad de root (UID=0). Ver systemd(1).

El proceso de inicio de systemd genera procesos en paralelo en función de los archivos de configuración de la unidad (ver systemd.unit(5)) que están escritos en estilo declarativo en lugar de un estilo de procedimiento similar a SysV .

Los procesos generados se colocan en grupos de control de Linux individuales con el nombre de la unidad a la que pertenecen en la jerarquía privada de systemd (ver cgroups y Sección 4.7.5, “Características de seguridad de Linux”).

Las unidades para el modo sistema se cargan desde la "Ruta de la búsqueda de las unidades del sistema" descrita en systemd.unit(5). Las principales por prioridad son las siguientes:

  • "/etc/systemd/system/*": Unidades del sistema creadas por el administrador

  • "/run/systemd/system/*": Unidades de tiempo de ejecución

  • "/lib/systemd/system/*": Unidades del sistema instaladas por el gestor de paquetes de la distribución

Las interdependencias se describen mediante directivas «Wants=», «Requires=», «Before=», «After=», … (ver "MAPPING OF UNIT PROPERTIES TO THEIR INVERSES" en systemd.unit(5)). El control de recursos también se define (ver systemd.resource-control(5)).

El sufijo del archivo de configuración de la unidad codifica sus tipos como:

  • *.service describe el proceso que está controlado y supervisado por systemd. Consulte systemd.service(5).

  • *.device describe el dispositivo utilizado por sysfs(5) como el árbol de dispositivos udev(7). Consulte systemd.device(5).

  • *.mount describe el punto de montaje del sistema de archivos que está controlado y supervisado por systemd. Consulte systemd.mount(5).

  • *.automount describe puntos de automontaje de sistemas de archivos que están controlados y supervisados por systemd. Consulte systemd.automount(5).

  • *.swap describe dispositivos o archivos de intercambio controlado y supervisado por systemd. Ver systemd.swap(5).

  • *.path describe rutas supervisadas por systemd para la activación basada en la ruta. Consulte systemd.path(5).

  • *.socket describe conexiones controladas y supervisadas por systemd para la activación basada en conexiones. Consulte systemd.socket(5).

  • *.timer describe el temporizador controlado y supervisado por systemd para la activación en función de temporizadores. Consulte systemd.timer(5).

  • *.slice gestiona recursos mediante cgroups(7). Consulte systemd.slice(5).

  • *.scope se crean de forma programada utilizando los interfaces del bus de systemd para gestionar un conjunto de procesos del sistema. Ver systemd.scope(5).

  • Los grupos *.target y otros archivos de configuración de unit se usan para crear puntos de sincronización durante el arranque. Consulte systemd.target(5).

Tras el arranque del sistema (esencialmente init), el proceso systemd intenta iniciar /lib/systemd/system/default.target (normalmente enlazado simbólicamente a "graphical.target". Primero, algunas unidades objetivo especiales (ver systemd.special(7) como "local-fs.target", "swap.target" y "cryptsetup.target" son llamadas a montar el sistema de archivos. Luego, otras unidades objetivo son llamadas por las dependencias de la unidad objetivo. Para más detalles, lea bootup(7).

Systemd ofrece características de compatibilidad con versiones anteriores. Los archivos de órdenes de inicio de estilo SysV en «/etc/init.d/rc[0123456S].d/[KS]< name» son también analizados y telinit(8) se traducen a peticiones de activación de systemd.

[Atención] Atención

Los niveles de inicio emulados del dos al cuatro son enlaces simbólicos al mismo «multi-user.target».

El mensaje de error que se muestra en la consola se determina mediante la configuración de su nivel de umbral.

# dmesg -n3

En systemd, se registran diariamente tanto los mensajes del núcleo como los del sistema por el servicio systemd-journald.service (también conocido como journald) ya sea en un archivo binario persistente debajo de "/var/log/journal" o en datos binarios volátiles debajo de "/run/log/journal/". Se accede a estos datos de registro binario mediante el comando journalctl(1). Por ejemplo, puede mostrar el registro desde el último arranque como:

$ journalctl -b

En systemd, la utilidad de registro del sistema rsyslogd(8) puede estar desinstalada. Si está instalada, cambia su comportamiento para leer los datos de registro binarios volátiles (en lugar del valor predeterminado anterior al sistema "/dev/log") y para crear datos de registro permanentes tradicionales del sistema ASCII. Esto se puede personalizar mediante "/etc/default/rsyslog" y "/etc/rsyslog.conf" tanto para el archivo de registro como para la visualización en pantalla. Ver rsyslogd(8) y rsyslog.conf(5). Ver también Sección 9.3.2, “Analizador de registros”.

systemd ofrece no solo init system sino también operaciones genéricas de administración del sistema con el comando systemctl(1).

Tabla 3.6. Lista de típicos snippets de comandos systemctl

Operación nombre de la orden,
Lista de todos los tipos de unidades disponibles "systemctl list-units --type=help"
Lista de todas las unidades de destino en memoria "systemctl list-units --type=target"
Lista de todas las unidades de servicio en memoria "systemctl list-units --type=service"
Listar todas las unidades de dispositivo en memoria "systemctl list-units --type=device"
Listar todas las unidades de montaje en memoria "systemctl list-units --type=mount"
Listar todas las unidades socket en memoria "systemctl list-sockets"
Listar todas las unidades de temporizador en memoria "systemctl list-timers"
Iniciar "$unit" "systemctl start $unit"
Detener "$unit" "systemctl stop $unit"
Recargar la configuración específica del servicio "systemctl reload $unit"
Parar y arrancar todo "$unit" "systemctl restart $unit"
Iniciar "$unit" y detener todas las demás "systemctl isolate $unit"
cambiar a "graphical" (sistema de interfaz gráfica) "systemctl isolate graphical"
Cambiar a "multiusuario" (sistema de línea de comandos) "systemctl isolate multi-user"
Cambiar a "rescate" (sistema CLI de usuario único) "systemctl isolate rescue"
Enviar kill a "$unit" "systemctl kill $unit"
Ver si el servicio "$unit" está activado "systemctl is-active $unit"
Ver si el servicio "$unit" ha fallado "systemctl is-failed $unit"
Comprobar el estado de "$unit|$PID|device" "systemctl status $unit|$PID|$device"
Mostrar las propiedades de"$unit|$job" "systemctl show $unit|$job"
Fallo en el reset "$unit" "systemctl reset-failed $unit"
Listar la dependencia de todos los servicios de la unidad "systemctl list-dependencies --all"
Lista de archivos de unidad instalados en el sistema "systemctl list-unit-files"
Habilitar "$unit" (añadir symlink) "systemctl enable $unit"
Desactivar "$unit" (eliminar enlace simbólico) "systemctl disable $unit"
desbloquear "$unit" (eliminar el enlace simbólico a "/dev/null") "systemctl unmask $unit"
Máscara "$unidad" (enlace simbólico agregado a "/dev/null") "systemctl mask $unit"
Obtener la configuración del destino predeterminado "systemctl get-default"
Establece el objetivo predeterminado en "graphical" (sistema gráfico) "systemctl set-default graphical"
Establece el objetivo predeterminado en "multiusuario" (sistema CLI) "systemctl set-default multi-user"
Mostrar el entorno de trabajo "systemctl show-environment"
Establecer entorno de trabajo "variable" a "value" "systemctl set-environment variable=value"
Entorno de trabajo no fijado en"variable" "systemctl unset-environment variable"
Recargar todos los archivos de unidades y demonios "systemctl daemon-reload"
Apagar el sistema "systemctl poweroff"
Apagar y reinicio del sistema "systemctl reboot"
Suspender el sistema "systemctl suspend"
Hibernar el sistema "systemctl hibernate"

Aquí, "$unit" en los ejemplos anteriores puede que sea solo nombre de unidad (los sufijos como .service y .target son opcionales) o , en muchos casos, especificaciones de unidades múltiples (shell-style globs "*", "?", "[]" usando fnmatch(3) que se comparará con los nombres principales de todas las unidades actualmente en memoria).

Los comandos de cambio de estado del sistema en los ejemplos anteriores suelen estar precedidos por "sudo" para tener el privilegio administrativo necesario.

La salida de "systemctl status $unit|$PID|$device" usa puntos de colores ("●") para resumir el estado de la unidad de un vistazo.

  • Un "●" blanco indica un estado "inactivo" o en estado de "desactivación".

  • Un "●" rojo indica un estado de "fallo" o "error".

  • Un "●" verde indica el estado "Activo", "Recargando" o "Activando".

Aquí hay una lista de otros comandos de monitoreo impares bajo systemd. Lee las páginas más relevantes, incluidas cgroups(7).


Las opciones de montaje de discos normales y de sistemas de archivos en red se configuran en «/etc/fstab». Ver fstab(5) y Sección 9.6.7, “Optimización de los sistemas de archivos a través de las opciones de montaje”.

Los sistemas de archivos cifrados se configuran en «/etc/crypttab». Ver crypttab(5)

La configuración de RAID mediante software con mdadm(8) está en «/etc/mdadm/mdadm.conf». Ver mdadm.conf(5).

[Aviso] Aviso

Una vez montados todos los sistemas de archivos , los archivos temporales en «/tmp», «/var/lock» y «/var/run» se borran en cada inicio.

La instancia del sistema en la nube puede lanzarse como un clon de "Imágenes oficiales de la nube de Debian" o imágenes similares. Para dicha instancia del sistema, personalidades como el nombre de host, el sistema de archivos, la red, la configuración regional, las claves SSH, los usuarios y los grupos pueden configurarse utilizando funcionalidades proporcionadas por los paquetes cloud-init y netplan.io con múltiples fuentes de datos como archivos colocados en la imagen original del sistema y datos externos proporcionados durante su lanzamiento. Estos paquetes permiten la configuración declarativa del sistema utilizando datos YAML.

Más información en "Computación en nube con Debian y sus descendientes", "Documentación de Cloud-init" y Sección 5.4, “La moderna configuración de la red para la nube”.

Con la instalación predeterminada, muchos servicios de red (ver Capítulo 6, Aplicaciones de red) se inician como procesos demonios después de network.target en el arranque por systemd. No es una excepción "sshd". Cambiemos esto a inicio bajo demanda de "sshd" como ejemplo de personalización.

Primero, deshabilite la unidad de servicio instalada en el sistema.

 $ sudo systemctl stop sshd.service
 $ sudo systemctl mask sshd.service

El sistema de activación de sockets bajo demanda de los clásicos servicios de Unix era a través del superservidor inetd (o xinetd). Bajo systemd, se puede habilitar el equivalente añadiendo *.socket y *.service archivos de configuración de la unidad.

sshd.socket para especificar un socket de escucha

[Unit]
Description=SSH Socket for Per-Connection Servers

[Socket]
ListenStream=22
Accept=yes

[Install]
WantedBy=sockets.target

sshd@.service como el archivo de servicio de sshd.socket

[Unit]
Description=SSH Per-Connection Server

[Service]
ExecStart=-/usr/sbin/sshd -i
StandardInput=socket

Entonces, vuelve a cargar.

 $ sudo systemctl daemon-reload

Desde el núcleo de Linux 2.6 en adelante, udev system > aporta mecanismos automáticos de descubrimiento e inicialización (ver udev(7)). Después del descubrimiento de cada dispositivo por parte del núcleo, el sistema udev comienza un proceso de usuario el cual usa la información del sistema de archivos sysfs filesystem (ver Sección 1.2.12, “procfs y sysfs”), carga los módulos necesarios para el núcleo mediante el programa modprobe(8) (ver Sección 3.9, “La inicialización del módulo del núcleo”) y crea los nodos de dispositivo correspondientes.

[Sugerencia] Sugerencia

Si por cualquier motivo «/lib/modules/núcleo-version/modules.dep» no fue generado correctamente por depmod(8) , los módulos no pueden ser cargados por el sistema udev como se debería. Para solucionarlo ejecute «depmod -a».

Para las reglas de montaje de «/etc/fstab», los nodos de dispositivos no necesitan nombres estáticos. Se puede usar UUID para los dispositivos montados en lugar de los nombres de los dispositivos como «/dev/sda». Ver Sección 9.6.3, “Acceso al particionado utilizando UUID”.

Ya que udev es un sistema en evolución, dejaré los detalles para otra documentación y se describirá de forma mínima aquí.

[Aviso] Aviso

No intente ejecutar programas de larga duración como el script de copia de seguridad con RUN en las reglas udev como se menciona en udev(7). Por favor, cree un archivo systemd.service(5) apropiado y actívelo en su lugar. Ver Sección 10.2.3.2, “Montar la copia de seguridad activada por el acto”.

El programa modprobe(8) nos permite configurar el núcleo de Linux en ejecución desde el proceso de usuario añadiendo o eliminando módulos al núcleo. El sistema udev (ver Sección 3.8, “El sistema udev”) automatiza su llamada para ayudar a la inicialización de módulos en el núcleo.

No existen módulos que no correspondan a hardware ni módulos controladores de hardware especiales como los que necesitan ser precargados al estar enumerados en el archivo «/etc/modules» (ver modules(5)).

Los archivos de configuración del programa modprobe(8) están ubicados en el árbol bajo el directorio «/etc/modprobes.d/» como se detalla en modprobe.conf(5). (Si quiere evitar que algunos módulos del núcleo se carguen de forma automática, inclúyalos en la lista negra que es el archivo «/etc/modprobes.d/blacklist».)

El archivo «/lib/modules/version/modules.dep» creado por el programa depmod(8) describe las dependencias de los módulos usados por el programa modprobe(8).

[Nota] Nota

Si tiene problemas en la carga de módulos cuando se inicia su carga de módulos o con modprobe(8), «depmod -a» puede solucionarlo reconstruyendo «modules.dep».

El programa modinfo(8) muestra información acerca de los módulos del núcleo de Linux.

El programa lsmod(8) da formato al contenido de «/proc/modules», mostrando los módulos del núcleo que están cargados en este momento.

[Sugerencia] Sugerencia

Puede determinar cual es el hardware de su sistema. Ver Sección 9.5.3, “Identificación del hardware”.

Puede configurar su hardware en tiempo de arranque y activar las funcionalidades del hardware conocidas. Ver Sección 9.5.4, “Configuración del hardware”.

Seguramente pueda añadir soporte a sus dispositivos especiales recompilando el núcleo. Ver Sección 9.10, “El núcleo”.